DHealth

Security & privacy

Principles we can show you, not certifications we cannot.

This page describes how DHealth is built. It does not claim a certification, an accreditation, or a regulatory status, because DHealth holds none.

Architectural principles

  • Authenticated staff access

    Every staff surface requires an authenticated session against an identity provider. There is no anonymous staff access and no shared open door.

  • Organization-scoped permissions

    A person acts within an organization they belong to. Changing which organization they are working in changes what they can see, and the server decides that — the screen layout is a convenience, not the control.

  • Explicit roles

    Entering a result and releasing it are separate authorities. So are ordering and reviewing. Roles are granted deliberately rather than implied by being logged in.

  • Auditability

    The network records what happened, in sequence, under whose authority. Releases are bound to immutable versions, and corrections create new versions rather than overwriting the record a clinician acted on.

  • Order-scoped patient access

    A patient link authorizes exactly one order. It is not an account, it does not accumulate a history, and the issuing clinic can revoke it.

  • A deliberately limited data boundary

    A laboratory receives the patient detail the work requires, not a general record. DHealth is a diagnostic network and is not intended to become an unrestricted longitudinal medical record merely because diagnostics pass through it.

  • No patient data to third-party AI services

    Patient data is never sent to a third-party AI or machine-learning service. This is a standing product rule, not a configuration option.

  1. Staff sign in to an organization

    An account belongs to a facility and to a role within it.

  2. A clinic sees the orders it created

    Its own work, and the results released back against it.

  3. A laboratory sees the work sent to it

    What it was authorized to receive. Not a clinic's wider records.

  4. A patient sees one order

    From a link issued for that order, scoped to it and nothing else.

Routing diagnostics between organizations is not a reason to build an unrestricted record of everybody. Participating in the network does not make one facility's patients visible to another.

What we do not claim

DHealth is not certified, accredited, or approved under any regulatory scheme, and this page should not be read as asserting compliance with one. Where recognised standards inform the design, that is a design input — it is not a certification, and we will not describe it as one.

  • No regulatory certification or accreditation is claimed.
  • No compliance attestation is claimed.
  • No government approval is claimed.
  • Mentioning a standard is never a claim to be certified against it.

Before real patient care

Security review, privacy review, clinical governance and operational qualification remain required before DHealth is used in a real patient care environment. That is a statement of where the work is, made plainly so that no facility mistakes a working system for a qualified one.

Reporting a security concern

If you believe you have found a security problem, write to us through the partner form and say so in the message — we will reply with a direct channel. Please do not include patient or clinical information.

Contact us