For laboratories
The distinction between a result that exists and a result a clinician may act on is the centre of how DHealth models laboratory work — not a setting, and not something a rushed afternoon can skip past.
Orders arrive from clinics authorized to route to you, with the patient detail the work requires.
Take the work on, or decline it with a reason. Either way the clinic knows.
Record that the sample was collected, as its own explicit milestone.
Record that analysis is under way, so the ordering clinic is not left guessing.
Structured entry, including several observations under one ordered service where that is what the work returns.
A value corrected before release supersedes the earlier one without destroying it. The history stays legible.
A person holding release authority releases explicitly. The released version is fixed to exactly the results it contained.
A correction after release is a new version, prepared and released deliberately, and it obliges a fresh clinician review.
Sample received
The laboratory accepts the work it has been sent.
Result entered
Typed in by a technician. It has left nobody's building yet.
Released
An authorized person releases it. This is a deliberate act, not a save.
The ordering clinician has it
It reaches the clinician who asked for it, attached to their order.
Entered is not released. Until someone authorized releases it, the ordering clinic sees that the work is in progress — never a half-finished value. A correction is issued as a new released version, and the earlier one is superseded rather than overwritten.
Entering a result and authorizing its release are separate permissions, because in a real laboratory they are frequently separate people. A technician with entry rights cannot release; someone with release authority sees a release queue rather than an entry form. The network enforces that separation on the server, not merely in the screen layout.
A superseded value is never silently replaced. Before release it is superseded in a chain that remains inspectable; after release it becomes an amendment, which produces a new version manifest and requires the ordering clinician to review again. A clinician who acted on the earlier version can always see what they actually saw.
Most established laboratories do, and typing the same thing into a second system is not a way of working — it is a mistake waiting to happen. DHealth Connect is the path being designed for laboratories that already have their own software: connect the system you run, rather than keeping two sets of records in step by hand.
In design Connect is in design. Whether your software can be connected, and how, depends on what it is able to send and receive, and is established during technical discovery.
If you run a clinic, a hospital, a laboratory, or the software one of them depends on, we would like to talk. Early participants shape what this network becomes.
DHealth is in active development. No facility is live on the network, and nothing here has been used in real patient care.