How Clinical Data Actually Flows Under ABDM: A Guide for Health IT Teams

Editorial Disclosure: CaladriusHealth.AI builds technology for India’s ABDM and NHCX ecosystem, including tools for ABDM-compliant health data exchange. This article is part of an independent educational series on India’s digital health infrastructure. All content is sourced from public government documentation, standards body publications, and labelled industry/open-source references. It does not draw on client data or proprietary implementation details. All factual claims are independently cited and publicly verifiable. This article does not constitute legal advice; organisations should seek qualified legal counsel for compliance determinations specific to their operations.

TL;DR

ABDM’s HIE-CM layer governs clinical record exchange, separate from NHCX, which handles insurance claims. Different FHIR profiles, different teams, different certification track.
Every data transfer requires a patient-issued consent artefact. No consent, no data — this is architectural, not policy preference.
The specification, sandbox, and reference implementations are mature and well-documented. This guide walks through the architecture and flags a few practical things worth planning for ahead of M3.

The Record Is There. Can It Move?

India’s ABDM network crossed 100 crore ABHA-linked health records in May 2026. The adoption numbers, state-level breakdown, and what they mean for multi-state deployment are covered in detail in Article 2 of this series: Understanding ABHA — India’s Health ID Layer. [1]

For Health IT teams inside hospitals, the more consequential question is operational: once a patient’s record exists inside your Hospital Information System (HIS), your Laboratory Information System (LIS), or your Radiology and PACS environment, how does it leave your system, travel to a requesting care facility, and arrive in a form that clinical staff can actually use?

The answer is the Health Information Exchange and Consent Manager, referred to throughout the ABDM ecosystem as HIE-CM, the consent-governed, data-movement backbone of the Ayushman Bharat Digital Mission (ABDM). Unlike NHCX, which Article 3 of this series covered from an insurance-claims perspective, HIE-CM governs clinical records: outpatient consultation notes, discharge summaries, diagnostic reports, immunisation records, and more.

The document types differ. The FHIR profiles differ. Critically, the implementation teams differ. This article is written for the people actually building and certifying those integrations.

What HIE-CM Is, and What It Is Not

ABDM is built on a federated health data architecture [2]. This is a stated design principle, “Privacy by Design” not merely an administrative choice. As confirmed in a written reply by the Minister of State for Health, Prataprao Jadhav, in the Lok Sabha on 29 November 2024, no centralised repository of health records is maintained at the national level; clinical records remain securely stored within individual federated host nodes and are shared only in transit, after explicit patient consent [3].

Records remain in source systems, hospital servers, laboratory databases, PACS installations, and are transmitted on demand when a patient grants consent through an authorised Personal Health Record (PHR) application. The ABDM gateway routes consent signals and orchestrates data transfers; it does not function as a central repository of clinical records. Implementers should note that audit trail metadata and transient message states are logged within individual nodes for reliability and compliance purposes, consistent with ABDM’s accountability requirements.

The HIE-CM performs two distinct functions within this architecture [4]:

Health Information Exchange (HIE): The protocol layer that governs how records are requested, located, encrypted, and delivered between systems.

Consent Manager (CM): The governance layer that controls whether a data transfer is authorised at all. No record moves without a valid, patient-issued consent artefact.

Two roles define every participant on the network [5]:

Health Information Provider (HIP): Any system that holds clinical records — a hospital’s HIS, a diagnostic lab’s LIMS, a pharmacy’s dispensing system. The HIP generates records and responds to data requests.
Health Information User (HIU): Any system that needs to consume clinical records — a specialist’s EMR requesting prior consultation history, an emergency department pulling discharge summaries from another facility.

A single hospital is typically both: a HIP for the records it generates, and an HIU when its clinical staff request records from another facility.

The Three-Stage Data Flow

Every clinical record exchange under ABDM passes through three discrete stages [6] [7]. Understanding this sequence precisely is prerequisite to any implementation.

An HIU, for example, a cardiologist’s system at a tertiary centre, initiates a consent request through the ABDM gateway, directed at the Consent Manager. The request specifies the patient’s ABHA ID, the date range of records required, the stated purpose of access (treatment, emergency, research, or self-request), and the categories of data being requested.

The Consent Manager routes this to the patient via their registered PHR application. The patient reviews the request, which records, from which facility, shared with whom, for how long, and chooses to grant or deny. If denied, the HIU receives a denial notification and no data is accessible.

If the patient grants consent, the Consent Manager generates one consent artefact per HIP involved [7]. Each artefact is scoped per source system, carrying a unique consent ID, the defined data scope, a purpose code, and an expiry timestamp, enabling granular audit and accountability at the level of individual data holders. If records from three HIPs are needed, three distinct artefacts are issued.

The HIU receives the artefact IDs. The relevant HIPs are simultaneously notified that a consent grant exists for a specific incoming data request.

Stage 3 — Data Request and Transfer

The HIU sends a formal data request to the relevant HIP through the Consent Manager gateway [6]. This request embeds three elements: the consent ID matching the issued artefact, the HIU’s encryption public key and a fresh nonce, and a callback URL (the “data push URL”) where the HIP should deliver the records.

The HIP validates the consent artefact, checking scope, purpose, and expiry, assembles the requested records as FHIR R4 bundles conforming to NRCeS profiles, encrypts them using Fidelius, and pushes the encrypted payload to the provided callback URL [8]. The HIP then notifies the Consent Manager that the data was transmitted. The HIU’s system confirms receipt and decrypts the payload using its own private key. The transaction is audit-logged at each node.

Three-stage ABDM data flow: HIU sends a consent request through the Consent Manager to the patient (Stage 1); the Consent Manager issues consent artefacts and notifies the HIP (Stage 2); the HIU requests data and the HIP validates, encrypts, and transmits the FHIR bundle (Stage 3)

A Note on Fidelius and Two Things to Get Right

Fidelius is ABDM’s end-to-end encryption protocol for health data in transit, developed by Hitachi MGRM Net and referenced in NHA’s sandbox documentation [8]. Its cryptographic construction combines:

ECDH key exchange on Curve25519 — both HIU and HIP generate a fresh, ephemeral key pair plus a 32-byte random nonce for every transaction; the shared secret is derived from this exchange and never reused across sessions
Nonce-based salt and IV derivation — the two parties’ nonces are combined to derive the salt and initialisation vector used in key derivation and encryption
HKDF + AES-256-GCM — the ECDH shared secret, combined with the derived salt, is processed through HKDF to produce a session-specific AES-GCM encryption key, which encrypts the FHIR bundle [8]

Fidelius encryption pipeline: ECDH key exchange on Curve25519, nonce-based salt and IV derivation, HKDF key derivation, and AES-256-GCM encryption between HIP and HIU

This construction provides perfect forward secrecy: even if a system’s long-term key material were later compromised, previously exchanged session data remains inaccessible because each session’s encryption key is derived independently and discarded [8].

Two implementation practices are worth flagging explicitly:

Use the reference implementation, not a generic ECDH library. Teams that implement ECDH from general-purpose cryptography libraries using default Curve25519/X25519 parameters have reported handshake failures with errors resembling “encoded key spec not recognized” against the ABDM gateway. The reliable approach is to base your implementation directly on the official Fidelius CLI reference implementation’s parameters and key generation routines, rather than reimplementing from a generic ECDH library [8].

The non-standard nonce size. ABDM’s protocol specifies a 32-byte nonce per party. Many widely-used high-level cryptography libraries (Libsodium/NaCl-based wrappers, in particular) hardcode an expectation of a 24-byte nonce and will reject or silently mishandle a 32-byte value. Implementation teams should verify nonce length handling explicitly during unit testing rather than assuming a high-level library “just works.”

The practical recommendation: rather than reimplementing Fidelius from cryptographic primitives, use the official open-source reference implementation (fidelius-cli) as the basis, and validate against NHA sandbox test cases before production deployment. NHA may update test vectors over time, so implementers should follow the current sandbox test matrix at the time of submission.

The FHIR Layer: Clinical Profiles Are Not Claims Profiles

ABDM mandates HL7 FHIR Release 4 (FHIR R4) as the standard for all health information exchange [9]. The FHIR used in HIE-CM for clinical records is structurally different from the FHIR used in NHCX for insurance claims — different resource types, different Composition profiles, different coding requirements.

India’s clinical FHIR profiles are maintained by the National Resource Centre for EHR Standards (NRCeS), operating under C-DAC, Pune. These are published through the official ABDM FHIR Implementation Guide, current version 6.5.0 as of June 2026 [10].

How a Clinical Document Is Structured

Every structured clinical document under ABDM is a FHIR Bundle of type document [10]. The Bundle’s first entry is always a Composition resource, the document’s header, carrying its type classification, authorship references, date, and the ordered set of clinical sections. All clinical content, observations, medications, procedures, diagnostic findings, and immunisation records are included as additional entries in the same Bundle, referenced from sections within the Composition.

DocumentReference is a separate resource used for referencing or attaching external documents (such as scanned records, legacy PDFs, or imaging study pointers), rather than defining the primary structure of a clinical document Bundle [11]. Both appear in ABDM implementations, but at different points in the workflow and for different purposes.

The Six Primary Clinical Document Types

NRCeS defines the following clinical document profiles, each a constrained specialisation of the FHIR Composition resource [10]. These are the primary profiles for clinical care exchange; NRCeS also defines WellnessRecord and InvoiceRecord profiles for wellness and billing contexts, which fall outside this article’s clinical-exchange scope.

OPConsultRecord — The outpatient consultation note. Captures examination findings, diagnosis, medications prescribed, investigation advice, and follow-up instructions from a single outpatient visit [12]. For facilities with significant OPD volume, this is typically the highest-frequency document type produced.

DischargeSummaryRecord — The inpatient discharge summary. Provides a structured synopsis of the patient’s admission: presenting complaint, course of treatment, procedures performed, discharge medications, and follow-up plan [13]. For surgical and tertiary facilities, this is the most clinically dense document category.

DiagnosticReportRecord — Covers both laboratory and radiology reports [14]. Supports structured observation data using LOINC codes for test identification and SNOMED CT for qualitative result interpretation. Plain diagnostic PDFs embedded in FHIR document references are technically valid under the specification, but structured data exchange is the preferred implementation target.

ImmunizationRecord — Structured immunisation history, relevant for facilities integrated with CoWIN data flows and government immunisation programmes [10].

HealthDocumentRecord — A general-purpose container for health records that do not conform to the structured categories above, including scanned historical records [10].

PrescriptionRecord — Standalone prescription documents capturing medication details in coded form [10].

Each profile specifies which FHIR elements are mandatory (SHALL), which are recommended (SHOULD), and which code systems are required at the element level. Bundles that do not conform to the relevant NRCeS profile will fail sandbox validation.

Coding Standards: Mandated and Recommended

The NRCeS Implementation Guide specifies coding system requirements at the element level [15]. In practice:

SNOMED CT — mandated for clinical findings, diagnoses, procedures, and body site references where applicable; used in Condition, Procedure, and Observation resources
LOINC — mandated for laboratory test identification in DiagnosticReport and Observation resources
ICD-10 — recommended for diagnosis classification; frequently used alongside SNOMED CT in Condition resources
DICOM — referenced for imaging study metadata in ImagingStudy resources

The practical implication: a facility’s internal coding — local LIS test identifiers, facility-specific diagnosis shortcodes, must be mapped to these international terminologies before a conformant bundle can be produced. This mapping work is consistently identified by implementers as the longest lead-time component of M3 integration [16] (industry/implementation source).

The Four Milestones: Engineering Realities at Each Stage

NHA structures ABDM integration into four progressive milestones [17] [18]. Each carries its own engineering profile.

ABDM's four integration milestones: M1 patient identity, M2 registry and care-context linking, M3 live data exchange, M4 per-facility deployment

Milestone 1 (M1) — Patient Identity, and an Asynchronous Surprise

M1 establishes the patient identity layer through ABHA creation, verification, and registration. The headline requirement looks deceptively simple: verify an ABHA ID, but the underlying API pattern is asynchronous rather than synchronous [6]. When a clinical application calls an ABHA verification or mode-discovery endpoint, the gateway typically returns an immediate empty acknowledgement; the actual verification result is delivered later to a callback URL pre-registered by the hospital [6].

This has a direct security implication: that callback endpoint is exposed to the public internet, and is in scope for the Web Application Security Audit (WASA) “safe-to-host” certification that ABDM-integrated systems undergo. At minimum, implementation teams should plan for signature validation on incoming callback payloads, IP-based restriction of inbound traffic to known ABDM gateway ranges, and rate limiting on the callback endpoint to guard against abuse [6]. Teams that treat M1 as “just an identity lookup” frequently underbuild this exposed surface.

Milestone 2 (M2) — Registry Participation and Care Context Linking

M2 requires registering the facility in the Health Facility Registry (HFR) and the ability to create and link care contexts, pointers to specific patient encounters, on the ABDM network. A patient’s care contexts at your facility become visible on their PHR application once linked. For a full treatment of HFR and HPR — what they are, what they require, and how they fit into the broader ABDM infrastructure — see Article 3 of this series: India’s Health Registries — HFR and HPR Explained.

Mapping local relational schemas (a typical HIS runs on MySQL or PostgreSQL) to FHIR Bundles is most maintainably done through a templating layer that decouples the clinical database from FHIR serialisation logic, so schema changes in the source system don’t require redeploying integration code. On terminology: a centralised terminology lookup service is recommended over mappings embedded inside individual pipelines; this avoids “code drift,” where the same local code gets mapped inconsistently across modules over time.

Milestone 3 (M3) — Live Data Exchange, and the Lossy Mapping Problem

M3 is full bidirectional HIE-CM implementation: HIP capability (assembling and transmitting encrypted FHIR bundles) and HIU capability (requesting, receiving, and decrypting bundles from other facilities), with active consent management throughout [17].

A structural challenge that becomes visible at this stage is what implementers sometimes call lossy data transfer. Hospital clinical databases typically store deeply nested, locally structured records. FHIR, like most interoperability standards, follows what’s informally known as the “80/20 rule”: the standard profiles capture the ~80% of clinical information that is common across systems well, but the remaining facility-specific or highly granular detail may not have a direct home in the standard profile. When a record is mapped from a local database to FHIR, transmitted, and mapped back into a receiving system’s database, that residual detail can be lost in translation, not through any error, but because the standard format simply doesn’t carry it.

The architectural mitigation worth planning for: treat FHIR as the transport and exchange format, not as your system of record. Maintain your full-fidelity clinical data in your native database or a dedicated Clinical Data Repository (CDR), openEHR-based or otherwise, and generate FHIR bundles from that source for exchange, rather than attempting round-trip FHIR storage as your primary clinical data model. This keeps your internal clinical record complete while still meeting ABDM’s exchange requirements.

The sandbox exit process at M3 involves NHA validation of FHIR bundle conformance, Fidelius encryption correctness, consent flow completeness, and callback handling, all tested in NHA’s sandbox environment before production credentials are issued [18]. NHA may update its test cases and checklist over time; implementers should refer to the current sandbox test matrix at the time of submission. Certification is per-software, not per-facility.

Milestone 4 (M4) — Per-Facility Deployment

Once software achieves M3 certification, M4 is the operationalisation phase: each physical facility registers independently in HFR, configures its production bridge URL, and seeds patient data into the live network [17]. For a multi-facility hospital group, M4 is repeated for every branch. The software is certified once; the deployment is per-site. This distinction matters for project planning; M3 timelines are engineering-driven, while M4 timelines are operations- and change-management-driven.

Implementer Quick Checklist

For teams entering or reviewing their M3 implementation:

[ ] FHIR profile conformance: Validate all generated bundles against NRCeS v6.5.0 profiles using a FHIR validator before sandbox submission
[ ] Terminology coverage: Confirm LOINC mappings for all LIS test codes and SNOMED CT mappings for clinical findings before M3 testing begins
[ ] Fidelius implementation: Build from the official reference implementation rather than generic ECDH libraries; explicitly test 32-byte nonce handling; validate against current NHA sandbox test vectors
[ ] M1 callback security: Implement signature validation, IP allow-listing, and rate limiting on publicly exposed callback endpoints ahead of WASA review
[ ] Consent artefact handling: Implement and test consent grant, denial, expiry, and revocation flows, not only the happy path
[ ] Data architecture: Decide whether FHIR is your transport format or your storage format before building; retrofitting a CDR layer later is significantly more expensive
[ ] Audit trail: Verify that each data transmission and consent event is logged with a timestamp and transaction ID at every node

HIE-CM and NHCX: A Structural Comparison

For organisations working across both integration tracks, the two are related but structurally distinct [19]. Both reference HL7 FHIR R4 and run on the ABDM gateway, but they serve different workflows, use different base resources, and are typically built by separate teams.

Structural comparison between HIE-CM clinical exchange and NHCX insurance claims, covering FHIR bundle types, base resources, and encryption models

	HIE-CM (Clinical Exchange)	NHCX (Insurance Claims)
Standards version	NRCeS ABDM IG v6.5.0 (Release)	NRCeS NHCX IG v7.0.0 (Active)
FHIR Bundle type	`document`	`collection`
Core base resource	Composition (anchors clinical sections)	Claim (defines financial requests)
Primary profiles	OPConsultRecord, DischargeSummaryRecord, DiagnosticReportRecord, PrescriptionRecord, ImmunizationRecord	ClaimBundle, ClaimResponseBundle, CoverageEligibilityRequestBundle, CoverageEligibilityResponseBundle
Coding vocabularies	SNOMED CT, LOINC, ICD-10, DICOM	ABDM-specific Billing, Form, and Reason code systems
Security model	Fidelius end-to-end encryption (ECDH on Curve25519)	JWE payload encryption (RSA-OAEP-256 + AES-256-GCM)
Workflow pattern	Asynchronous, consent-gated	Asynchronous — submission returns an immediate acknowledgement with a correlation ID; the response arrives later via a callback

[19]

The operational consequence: a hospital pursuing both clinical (HIE-CM) and financial (NHCX) integration should staff them as parallel workstreams. Shared FHIR tooling and infrastructure can be reused where genuine overlap exists (resource validation pipelines, gateway authentication), but the resource models, terminologies, and certification paths are distinct enough that a single integration team attempting both simultaneously typically underestimates one or the other.

Conclusion

The HIE-CM layer is where ABDM’s infrastructure potential becomes a live clinical capability. With 100 crore records now linked to ABHA IDs, the identity and registry foundations are in place at a significant scale. For details on how that milestone was reached and what it means regionally, see Article 2 of this series. The consent architecture, HIP/HIU role model, and NRCeS clinical FHIR profiles are well-specified and publicly documented.

For Health IT teams, the path to a certified, production-grade M3 integration requires sustained work across data mapping, terminology infrastructure, encryption, and asynchronous workflow design, and a handful of practical implementation details (building Fidelius from the official reference implementation rather than generic libraries, the 32-byte nonce requirement, M1 callback exposure, and lossy FHIR mapping) are worth planning for from day one rather than discovering during sandbox testing. The specification is clear, the sandbox environment is available, and the implementation guidance is public. The main variables are time and method, not ambiguity about what is required.

Next in this series: Article 5 examines the consent governance philosophy behind HIE-CM, the policy and regulatory frameworks that govern what patients can control, what operators must preserve, and how the Digital Personal Data Protection Act 2023 shapes the design of ABDM’s consent artefact model. Note: DPDP Act provisions and their operational implications are complex and context-specific. Article 5 will frame these as policy and design considerations; organisations should seek qualified legal review for DPDP-specific compliance determinations.

CaladriusHealth.AI covers India’s health technology landscape with a focus on ABDM, NHCX, medical billing, and AI in healthcare. This article is part of a series on India’s digital health infrastructure.

Sources

Primary government and standards body sources are marked (Primary — Govt/Standards). Open-source/Digital Public Good and industry/implementation sources are marked accordingly and used only for practical implementation context.

[1] Press Information Bureau, Ministry of Health and Family Welfare / National Health Authority — “100 Crore Health Records Linked with ABHA under ABDM, Marking Major Leap in Digital Healthcare,” 22 May 2026. Includes state-level linking statistics and gateway integration counts. (Primary — Govt) https://www.pib.gov.in/PressReleasePage.aspx?PRID=2264241&reg=3&lang=1

[2] DPI.Global / ABDM Programme Documentation — “Ayushman Bharat Digital Mission — Federated health data architecture and building blocks.” (Primary — Govt ecosystem) https://www.dpi.global/globaldpi/abdm

[3] National Herald India — Report on written reply by Minister of State for Health Prataprao Jadhav, Lok Sabha, 29 November 2024, citing official government statement on ABDM’s “Privacy by Design” architecture and absence of a centralised health records repository. (News report of parliamentary record) https://www.nationalheraldindia.com/national/do-you-know-what-data-you-give-to-private-govt-entities-via-ayushman-bharat

[4] PMC / National Library of Medicine — Mishra, Yadav, Joe. “The Ayushman Bharat Digital Mission (ABDM): making of India’s Digital Health Story,” PMC10064942, 2023. (Peer-reviewed) https://pmc.ncbi.nlm.nih.gov/articles/PMC10064942/

[5] PSMRI / AMRIT-Docs — “ABDM FHIR Developer Introduction: HIP, HIU, HIE-CM role definitions.” Developed by Piramal Swasthya Management and Research Institute; open-source Digital Public Good, ABDM-integrated. (Open-source DPG — public repository) https://github.com/PSMRI/AMRIT-Docs/blob/main/architecture/integrations/abdm-fhir-developer-intro/README.md

[6] CoronaSafe Network / ABDM Documentation — “Building HIU: Consent request creation flow, three-stage data transfer, and M1 asynchronous callback pattern.” (Open-source — ABDM-affiliated implementer documentation) https://docs.coronasafe.network/abdm-documentation/implementers-guide/building-hiu

[7] CoronaSafe Network / ABDM Documentation — “Building HIP: Consent artefact notification and data transmission stages.” (Open-source — ABDM-affiliated implementer documentation) https://docs.coronasafe.network/abdm-documentation/implementers-guide/building-hip

[8] mgrmtech / fidelius-cli — “Encryption and Decryption Implementation Guidelines for FHIR data in ABDM” — full cryptographic specification including ECDH key exchange on Curve25519, nonce-based salt/IV derivation, HKDF key derivation, AES-256-GCM encryption, and perfect forward secrecy design. Developed by Hitachi MGRM Net; referenced in NHA sandbox documentation. (NHA-endorsed open-source reference — public repository) https://github.com/mgrmtech/fidelius-cli/blob/main/abdm/Encryption%20and%20Decryption%20Implementation%20Guidelines%20for%20FHIR%20data%20in%20ABDM.md

[9] Adrine.in — “ABDM FHIR Integration Guide 2026: How to Make Your HMS ABDM Compliant,” February 2026. (Industry/Implementation) https://www.adrine.in/blog/abdm-fhir-integration-guide-2026

[10] NRCeS — National Resource Centre for EHR Standards, C-DAC — “FHIR Implementation Guide for ABDM, v6.5.0” (current published release as of June 2026). (Primary — Govt/Standards) https://nrces.in/ndhm/fhir/r4/

[11] NRCeS — “DocumentReference Profile — FHIR Implementation Guide for ABDM v6.5.0.” (Primary — Govt/Standards) https://nrces.in/ndhm/fhir/r4/StructureDefinition-DocumentReference.html

[12] NRCeS — “OPConsultRecord Profile — FHIR Implementation Guide for ABDM v6.5.0.” (Primary — Govt/Standards) https://www.nrces.in/ndhm/fhir/r4/StructureDefinition-OPConsultRecord.html

[13] NRCeS — “DischargeSummaryRecord Profile — FHIR Implementation Guide for ABDM v6.5.0.” (Primary — Govt/Standards) https://nrces.in/ndhm/fhir/r4/StructureDefinition-DischargeSummaryRecord.html

[14] NRCeS — “DiagnosticReportRecord Profile — FHIR Implementation Guide for ABDM v6.5.0.” (Primary — Govt/Standards) https://nrces.in/ndhm/fhir/r4/StructureDefinition-DiagnosticReportRecord.html

[15] NRCeS / C-DAC — “Implementation Guide for Adoption of FHIR in ABDM and NHCX” (PDF) — mandatory and recommended coding systems by element and resource type. (Primary — Govt/Standards) https://www.nrces.in/download/files/pdf/Implementation_Guide_for_Adoption_of_FHIR_in_ABDM_and_NHCX.pdf

[16] Medblocks — “Implementing ABDM for the AP Government: An Honest Review,” February 2026. Production implementation case study covering SNOMED CT and LOINC mapping from a Government of Andhra Pradesh deployment. (Industry/Implementation) https://medblocks.com/blog/abdm-for-the-ap-government-a-honest-review

[17] Dreamsoft4u — “ABDM Integration Guide for Hospitals: M1, M2, M3 Modules Explained,” April 2026. (Industry/Implementation) https://www.dreamsoft4u.com/abdm-integration-guide-hospitals-m1-m2-m3

[18] CoronaSafe Network / ABDM Documentation — “ABDM Sandbox Integration and Exit Process: M2 and M3 milestone requirements and sandbox certification steps.” (Open-source — ABDM-affiliated implementer documentation) https://docs.coronasafe.network/abdm-documentation/implementers-guide/abdm-sandbox-integration-and-exit-process

[19] NRCeS — “NHCX Profiles — FHIR Implementation Guide for ABDM v7.0.0 (Active).” NHCX claims profiles use distinct resource types from clinical HIE-CM profiles. (Primary — Govt/Standards) https://www.nrces.in/preview/ndhm/fhir/r4/hcx-profile.html