Solution

Planned

A record built to be shared, once the certification is in hand.

ABHA identity, care contexts, consent artefacts and FHIR record bundles. Built to Milestones 1 to 4, verified in the sandbox, and not certified.

All solutions

An electronic health record is designed to travel between providers with the patient’s consent, rather than staying inside one clinic. In India that means ABDM: an ABHA number as the identity, registries for facilities and professionals, and consent artefacts that govern every exchange.

What is built

More of ABDM than most vendors describe, and every line of it is uncertified. Both halves of that sentence matter.

  • ABHA verification and creation at registration (Milestone 1)(planned)
  • Health Information Provider: care contexts and FHIR record bundles (Milestone 2)(planned)
  • Health Information User: requesting records from other facilities with consent (Milestone 3)(planned)
  • Health Facility Registry and Healthcare Professionals Registry enrollment (Milestone 4)(planned)
  • Consent status visible at the front desk without exposing any record(planned)

How consent is treated

Consent is re-checked at the moment of sending, not at the moment of asking. Records received from another facility are held on loan and built to be deleted when consent expires. The front desk can see whether anything has been requested, and deliberately cannot see source facility names, record counts, or any clinical content, because a source name like “oncology center” is a diagnosis by implication.

How it runs

  1. 01

    Identity

    A patient’s ABHA number is verified or created at registration, linking their record to the national identity.

  2. 02

    Publish

    Care contexts are published so the patient’s app knows this facility holds records for them.

  3. 03

    Consent

    A request carries a named clinician’s registration number to the patient, who grants or declines it in their own app.

  4. 04

    Exchange

    On consent, records move as encrypted FHIR bundles, checked again at the moment of sending and never before.

What this does not do

Nothing here is certified, and no health record has been exchanged with ABDM in production, in either direction, in any environment. Going live requires functional testing with the National Health Authority, a security audit certificate, and Health Tech Committee approval. Until all three exist, the honest description is “built and sandbox-verified”, which is why every capability above is marked planned rather than built. The code exists; the entitlement to use it does not.

Questions we are asked

Are you ABDM certified?

No. We have built Milestones 1 to 4 and verified them in the NHA sandbox. Certification requires functional testing, a security audit certificate and committee approval, none of which we hold. We will say the same thing on a call.

Can we use ABDM features today?

Not in production. That is why every ABDM line on this page is marked planned even though the code exists. Availability here means you can use it, not that we wrote it.

Does the front desk see records from other hospitals?

No, and that is deliberate. The desk sees whether anything has been requested and what its consent status is, but no records, no source facility names and no counts. Asking is a doctor’s act, because the request carries a named clinician’s registration number.

What happens to records we receive from another facility?

They are held on loan under the consent that brought them, and the system is built to delete them when that consent ends.

See it running with your own workflows.

Book a walkthrough and we will map your clinic or hospital onto the platform, module by module.