Scope ABDM integration around consent and supported record exchange
For CIO/CTO / digital programme owner · Plan implementation
TL;DR — what you’ll learn
- Choose one exchange use case and identify the provider's role before estimating the project.
- Separate ABHA-related identity work from permission to exchange health records.
- Pin the applicable profiles, interface versions and onboarding requirements.
- Test changed permissions, failed callbacks and duplicate messages before seeking production approval.
A provider asks for “ABDM integration”. One proposal demonstrates an identity-related flow, another produces a FHIR document and a third describes record exchange. Their estimates look comparable, but they cover different work.
Scope ABDM integration around one verified exchange workflow. Define the actor, records, authorisation checks, supported interfaces and operational owner. A valid document format is one component of the project; it does not by itself establish permission, successful exchange or production readiness.
Identify the role and the record
The NRCeS ABDM implementation guide distinguishes a health information provider, which creates information for sharing, from a health information user seeking records with informed consent. State which role the proposed system will perform and which existing system holds the authoritative record.
Scope the first evaluation around one synthetic diagnostic-report exchange and an explicitly agreed actor role. Ask the ABDM and privacy specialists to supply the applicable identity, authorisation and permission-change requirements. This article does not prescribe a consent sequence or treat an ABHA-related identity flow as approval for record sharing.
Record the partner-approved version baseline
Record the profile and interface versions required by the actual integration and onboarding partners, together with the official source and date checked. Do not select a production baseline merely because a guide displays a particular version or a development preview. This article makes no claim about a currently approved production version.
The NRCeS adoption guide, published in September 2024, explains FHIR resources, profiles and validation. Use current partner requirements to decide the production baseline; a guide's example or a development build is not an onboarding approval.
Scroll horizontally to see all columns.
| Scope item | Evidence required before commitment |
|---|---|
| Actor and use case | Agreed role and supported exchange pathway |
| Record type | Applicable profile, required fields and approved source |
| Identity mapping | Supported identifiers and reviewed relationship to the local record |
| Authorisation | Current policy and interface requirements for this exchange |
| Connectivity | Documented onboarding, access and environment requirements |
| Operations | Named owner for failures, corrections and reconciliation |
Handle permission changes as a designed case
Consider a synthetic request queued while the relevant permission is valid. Before the worker processes it, the permission changes. The integration must follow the applicable specification and policy for that state; it cannot assume that an earlier queue entry authorises unconditional sharing.
Use the following as an evaluation checklist for a specialist-designed exchange. Its decision points are questions to resolve against the actual specification and policy, not an asserted API sequence. The specialist must establish check timing and the treatment of changed permissions and already-transferred data.
Worked workflow
Original illustrative workflow. Follow the labelled transitions, including the exception paths.
- A · StepReceive supported exchange request
- B · StepResolve role record and applicable authority
- C · DecisionScope and current checks permit exchange
- D · StepStop transfer and route authorised review
- E · StepValidate required profile and source version
- F · DecisionValidation complete
- G · StepOwned correction task
- H · StepTransmit through supported interface
- I · StepReconcile acknowledgement and final outcome
Scroll horizontally to see all columns.
| From | Condition | Next |
|---|---|---|
| A: Receive supported exchange request | Continue | B: Resolve role record and applicable authority |
| B: Resolve role record and applicable authority | Continue | C: Scope and current checks permit exchange |
| C: Scope and current checks permit exchange | No or uncertain | D: Stop transfer and route authorised review |
| C: Scope and current checks permit exchange | Yes | E: Validate required profile and source version |
| E: Validate required profile and source version | Continue | F: Validation complete |
| F: Validation complete | No | G: Owned correction task |
| F: Validation complete | Yes | H: Transmit through supported interface |
| H: Transmit through supported interface | Continue | I: Reconcile acknowledgement and final outcome |
The evaluation keeps source-report release separate from payload validation. Ask the laboratory or clinical informatics owner to supply the approved source-version and mapping assumptions. A successful technical validation is not evidence of a clinical approval or permission to exchange the record.
Define what the pilot can and cannot change
Begin in the appropriate test environment with synthetic records. The integration may transform an approved record into the agreed exchange representation and handle supported messages. It must not invent missing clinical values, expand the requested data scope or silently link uncertain identities.
Have clinical informatics owners approve field and terminology mappings. Have security and privacy owners approve access, credentials, audit information and data minimisation. Do not retain complete sensitive payloads in general-purpose logs merely to simplify debugging. Retention and incident obligations require current applicable review.
Test denied or changed permissions, missing required fields, incorrect identity mapping, a corrected report, duplicate callbacks and a lost response. Preserve stable correlation references. If the outcome is uncertain, use the supported reconciliation procedure before retrying a transfer. A paused pilot should stop new transfers and preserve the minimum authorised evidence needed to resolve pending cases.
Separate technical completion from operational approval
Acceptance requires no out-of-scope data shared in the agreed challenge set, traceable source and exchanged versions, and explained outcomes for failures and retries. Record unresolved cases and recovery effort. A sandbox pass is evidence about those tests, not a claim of production authorisation, universal interoperability or legal compliance.
Require an evidence pack for the selected exchange
Ask the proposed implementation team for a version manifest, field-mapping record, synthetic payload set, authority-check design and reconciliation log. The manifest should identify the source software, relevant interface and profile baseline actually used. A successful payload from a different version should remain background evidence until its applicability is established.
Scroll horizontally to see all columns.
| Synthetic case | Evidence to inspect |
|---|---|
| Requested scope excludes part of the source record | Transmitted content stays within the reviewed scope |
| Required source value is absent | Validation fails or routes review; no plausible clinical value is invented |
| Permission changes while work is queued | Outcome follows the specialist-approved policy and interface sequence |
| Callback is repeated or arrives late | One reconciled exchange outcome with retained correlation history |
| A corrected report replaces an earlier source version | Approved version relationships remain traceable through the exchange |
The permission-change row is deliberately a review requirement: the current policy and partner specifications must determine what the implementation does and when. Do not turn the proposed diagram into an asserted legal rule.
Clinical informatics should approve mappings and source-release assumptions; the ABDM specialist should approve the selected exchange interpretation; the integration owner should establish recovery behaviour. A combined sign-off must distinguish the synthetic test result from outstanding onboarding or production conditions. This keeps the project deliverable concrete while leaving unverified authority and connectivity claims outside the accepted scope.
Next actions
- Agree one actor role and record-exchange use case with the provider and ABDM specialist.
- Verify current onboarding, profile and authorisation requirements against primary material.
- Approve the synthetic challenge set and operational recovery plan before production consideration.
Discuss this workflow
Discuss a scoped ABDM integration assessment for one verified role and record exchange, subject to specialist policy and onboarding review.
Describe the operation using business information only. Please leave out patient details.
Applying this guide
The scenarios and numbers are illustrative. Confirm these provider-specific inputs before implementation:
- ABDM specialist and Indian privacy/legal adviser: Establish the current authorisation and permission-change requirements from official policy and supported partner interfaces before designing the exchange.
- ABDM implementation specialist and NHA/partner onboarding owner: Confirm the actual partner-approved profile/interface baseline, onboarding requirements and production permissions; the article specifies no current approved version.
- Clinical informatics, laboratory owner where applicable, security and privacy/legal: Approved source-release procedure, profile/mapping review, data-flow and logging/retention design; no invented missing clinical values.
References
- NRCeS FHIR Implementation Guide for ABDM — Official actor/profile reference. Production baseline and authorisation must be established for the actual exchange; no current-release claim is made.
- NRCeS guide to FHIR adoption in ABDM and NHCX — Technical explanation and guidance date; not current production onboarding approval.
Topics: abdm integration · ABDM software integration · ABHA HIS integration · FHIR health record exchange India