The software you already use
The system your staff already work in.
DHealth Connect
In designDHealth Connect is the integration path for clinics, hospitals and laboratories that already run their own clinical or laboratory software.
Can we connect your system today? Honestly: not yet, and not blindly. Connect is in design. What a connector can do depends on the interfaces your software actually exposes, which is what technical discovery establishes before anything is promised.
The software you already use
The system your staff already work in.
DHealth Connect
In designTranslates its interfaces into the network contract.
DHealth Exchange
Where work goes, where it stands, which result answers which order, release, and a record of every step.
Other participants
The clinics and laboratories you are authorized to exchange with.
A production workflow should never require your staff to maintain the same diagnostic transaction twice — once in the system they already use, and once by hand in DHealth. If joining a network costs a facility double entry, the network has taken more than it gave.
A connector is a translator with a memory. It sits between one facility's software and the network contract.
Turns the messages and endpoints your system speaks into the DHealth contract, and back.
Your order numbers and record identifiers stay yours and stay attached, so a transaction on the network can always be reconciled with the one in your system.
A result that returns is matched to the order it belongs to, rather than to a best guess.
A dropped connection must not produce a duplicate order or a lost result. Safe retry is a correctness requirement, not a nicety.
The point of the whole exercise: staff keep working where they already work.
Your technician enters the order
In the software your staff already work in.
The same order typed again
Into a second system, by hand, to reach anyone outside the building.
no longer needed
DHealth Connect
In design
Translates your system's interfaces into the network contract.
The network has it
The participants you are authorized to exchange with, and nobody else.
Connector availability depends on the specific software and interfaces a facility uses. Technical discovery and qualification are required before any production integration.
Integration discovery
No credible integration begins with a promise. It begins with finding out what your system can do.
The software, the version, who maintains it, and who may authorize changes.
We look at what your system actually exposes, and what it would take to reach it.
Where orders originate, where results are authorized, and who is accountable at each step.
Scoped to what discovery found, not to a generic template.
End to end, with invented patients. Never with real ones.
Agree in writing what works, what does not, and what the failure behaviour is.
Only after all of the above.
These are the kinds of interface we look for. Naming them here is not a claim that DHealth supports each one today — it is a description of what discovery examines.
Which of these a given facility can actually use, and whether a connector for it exists, is determined by discovery and qualification — not by this list.
That we can connect any system instantly. That DHealth works with every piece of clinical software there is. That joining is one click away, today. None of that is true, and anyone who tells you otherwise before looking at your software is guessing with your operation.
Connector availability depends on the specific software and interfaces used by each facility. Technical discovery and qualification are required before production integration.
Tell us what you run. We will tell you what we can see, and what we cannot.
DHealth is in active development. No facility is live on the network, and nothing here has been used in real patient care.