ABDM integration for hospital groups, HMIS and EMR vendors, labs and health apps. We build ABHA (M1), HIP (M2) and HIU (M3) into the software you already run, map your records to NRCES FHIR profiles and take you through WASA, the NHA demo and sandbox exit.
Connect the patient’s health account to your local record.
Make reports and care summaries available through consent-based sharing.
Request available records from other providers with the patient’s consent.
Illustrative journey across participating ABDM systems.
The short answer
Nirmitee is an ABDM integration service provider for Indian hospitals, HMIS and EMR vendors, labs, diagnostics companies and health apps. We build ABHA creation and verification (M1), health information provider flows (M2) and health information user flows (M3) inside the software you already run, map your records to the NRCES FHIR profiles, handle Fidelius encryption and the ABDM V3 gateway callbacks, and take the product through functional testing, the WASA security audit and the NHA demo to sandbox exit. NHCX claims integration runs as a separate track.
ABDM milestones
ABDM sandbox certification has three milestones. NHA's current sandbox exit criteria require at least two of them, so an M1-only integration does not exit the sandbox. NHCX is a separate claims track that some teams call M4.
| Milestone | Your role | What your software must do | Records and registries |
|---|---|---|---|
| M1: ABHA | Identity | Create ABHA with Aadhaar or mobile OTP, verify an existing ABHA, create an ABHA address, show the ABHA card, link ABHA to your patient record and support Scan and Share at registration | Health Facility Registry (HFR) ID for each facility |
| M2: HIP | Health Information Provider | Create care contexts after each visit, answer discovery and link requests (including patient-initiated discovery), receive consent notifications, then build, encrypt and push FHIR bundles | NRCES profiles: OPConsultRecord, PrescriptionRecord, DiagnosticReportRecord, DischargeSummaryRecord, ImmunizationRecord, HealthDocumentRecord, WellnessRecord |
| M3: HIU | Health Information User | Raise consent requests, track consent status, fetch approved records, decrypt them and display them to authorized staff | Consent artefacts with purpose, date range, record types and expiry |
| NHCX (separate track) | Claims participant | Coverage eligibility, pre-authorization and claims with insurers and TPAs through the National Health Claims Exchange | NHCX participant onboarding; HFR and Healthcare Professionals Registry (HPR) IDs |
Certification is per software product. Each facility that uses the certified product then registers in HFR, and its doctors in HPR.
Choose the milestone scope around the workflows your product needs to support. NHCX is a separate claims workstream, not a fourth ABDM milestone.
Identity, created or verified at your registration desk and tied to your own record.
Reports and summaries released to whoever the patient consents to share them with.
A patient's prior records pulled in from other providers, with their consent.
Eligibility, pre-authorisation and claims exchange with participating payers.
Registry onboarding and NHCX requirements are scoped separately. Production access follows NHA review, functional testing, WASA and the sandbox exit application. Explore the official ABDM sandbox ↗
FHIR is the exchange format. Mapping your existing records and making received information usable inside your product is custom integration work.
Map your source fields into the applicable ABDM FHIR profiles, assemble document bundles and validate the records you intend to share.
Mappings, validated example bundles and tested sharing flows for the agreed record types.
Handle consent and record requests, receive and interpret FHIR documents, and present available information in the relevant patient workflow.
A tested record-access journey with agreed display, storage and failure-handling behaviour.
Your data model, record types, missing fields, coding systems, existing APIs, tenant setup and UI requirements. We agree these before estimating, because every product needs its own mapping.
ABDM FHIR Implementation Guide ↗ABDM means something different depending on what you sell and who you answer to. Pick the one that sounds like you: the trigger, what it unlocks and what we hand over.
ABDM arrives through empanelment paperwork, a scheme requirement, or patients who expect their ABHA to mean something at your desk.
Empanelment and scheme paperwork that asks for ABDM participation, a group-level digital mandate, or a corporate customer who wants records to move between your units.
Your HIS talking to ABDM, the NHA test evidence for each certified milestone, staff-facing screens that don't add clicks, and a runbook your IT team can actually operate.
You don't run hospitals, you sell to them. ABDM is now a qualifying question in your sales cycle, and you have an install base, not one deployment.
"Is your product ABDM-certified?" appearing in RFPs and renewals. Or one large customer setting a date, and you realising the answer has to work for all the others too.
ABDM built into your codebase and your release process, not a side application. Plus the certification evidence, an onboarding checklist per facility, and handover to your engineers.
Digital-first, no legacy to protect. For you ABDM is identity and trust: proving the patient is who they say they are, and pulling a history worth acting on.
An enterprise or government customer asking for it, a partnership that needs verified patient identity, or a product bet on records portability being the differentiator.
Working ABHA and consent flows in your product, the consent artefacts stored the way an auditor expects, and the certified milestones behind them.
Maternal health, screening, immunisation, field-worker apps. Different constraints: offline villages, many languages, several schemes at once, a state portal to align with.
A state directive with a date on it, or a department that now runs several applications and doesn't want to certify each one separately.
A central ABDM gateway your schemes share, the FHIR mapping for each programme's clinical data, and the certification evidence, plus the NHA correspondence, handled by us.
Your problem isn't records. It's the days money sits in transit. NHCX puts eligibility, pre-auth and claims on the rails ABDM already gave you.
Pre-authorisation still moving by email and portal. A finance team measuring claim cycle time in weeks. Or an insurer partner who has already onboarded and wants you on the exchange.
The claim lifecycle wired into your existing billing, insurer responses handled reliably even when they come back hours later, and support through NHCX participant onboarding.
Planning figures from our own delivery. Yours is scoped on the first call.
Two questions: who writes the code, and how many applications need to end up certified. The comparison table below sets out all four options.
You keep the keyboard. Our consultants sit with your developers and stay on it until you're certified.
Engineers who have shipped ABDM before write it inside your product. No separate system, no handover gap.
One central layer with shared mapping and consent screens. Plan approval and onboarding requirements for each application before rollout.
Fixed price agreed before we start, or a dedicated team by the month. Source code included, engineers with you until go-live, and no per-transaction fees.
What we build
ABDM added beside your existing software, with every flow tested against the NHA test cases.
Aadhaar and mobile OTP creation, ABHA verification, ABHA address, the ABHA card and Scan and Share QR registration, linked to your own patient record.
ABHA number · ABHA address · OTP · QR
ABDM milestones M1 to M4 guide →Care contexts, discovery, link and confirm, consent notify and the health information request that builds, encrypts and pushes records to the requester.
Care contexts · discovery · consent notify
Building an ABDM HIP (M2) →Consent requests, status tracking, record fetch, decryption, patient matching and display of external records inside your clinical screens.
Consent init · status · fetch · decrypt
Building an ABDM HIU (M3) →Your records mapped to the NRCES FHIR R4 document profiles, coded in SNOMED CT and LOINC where the source allows, and validated before any demo.
FHIR R4 · NRCES profiles · SNOMED CT · LOINC
ABDM FHIR bundles across the patient journey →ABDM V3 APIs, bridge URL registration, asynchronous callbacks that survive proxies and firewalls, and Fidelius-compatible ECDH encryption on Curve25519.
ABDM V3 · bridge URL · Fidelius
Debugging ABDM callbacks →Functional testing and WASA coordination, audit fixes, internal rehearsals, the NHA demo, production credentials and facility onboarding.
Functional test · WASA · NHA demo · HFR
ABDM sandbox to production guide →Buyer decisions
Two questions decide the approach: who writes the code, and how many applications need ABDM.
| Approach | Best fit | What you own | Trade-off |
|---|---|---|---|
| Build in-house from NHA documentation | Teams with spare engineers and a flexible date | All code and all review preparation | V3 callbacks, encryption and FHIR mapping are where most teams stall |
| Our SDK with our consultants | Your developers code; we guide them through testing and the NHA demo | All code, written by your team | Your team's capacity sets the pace |
| Our engineers inside your codebase | HMIS and EMR vendors with a contract deadline | All source code, handed over with documentation | Needs access to your repository and release process |
| ABDM connector on Interoply | Hospital groups, state programs and vendors running several applications or many tenants | Per-facility configuration on one shared gateway | A shared service to operate, with one consent experience and FHIR mapper |
Every approach needs product-specific FHIR mapping. An SDK or connector removes repeated plumbing, not your data model.
Integration boundaries
ABDM involves NHA, empanelled agencies and your facilities. We coordinate all of them.
Issues sandbox and production credentials, runs the review demos and approves sandbox exit. We prepare the demo, present with you and close every finding.
Functional testing and the WASA security audit are done by empanelled third-party agencies you engage. We coordinate them and fix what they find.
Keeps its clinical data and screens. We add ABDM flows and map your records without replacing your HIS or HMIS.
Each facility registers in HFR and its doctors in HPR. We give you the onboarding checklist and support the first facilities.
Scoped as its own track with NHCX participant onboarding, after or alongside the ABDM milestones.
Deliverables
What you hold at the end, ready for the next audit or tender.
Milestones and FHIR record types agreed with NHA before the build starts.
Working flows with consent screens, callbacks and encryption, in your repository.
Field-level mappings and validated example bundles for each approved record type.
Functional test support, the WASA remediation log and recordings of every consent path.
Scripted demo flows, rehearsal notes and the review-finding log.
Production configuration, facility onboarding checklist and engineering handover.
Delivery phases
Most products reach sandbox exit in 12 to 20 weeks. Agency queues and NHA review slots move the date more than the build does, so we book them early.
Weeks 1 to 2
Milestone and record-type scope, sandbox credentials, bridge URL and HFR setup
Weeks 2 to 10
Working flows and FHIR bundles, proven in internal demos
Weeks 8 to 16
Test reports, audit fixes, NHA review and milestone approval
Weeks 14 to 20
Exit application, production credentials, facility onboarding and handover
Our delivery sequence includes two internal demos, formal testing, the NHA review and feedback handling before production. Open a stage to see what to expect.
Confirm milestone scope, set up access and implement the agreed ABHA, HIP and HIU workflows against your existing product.
A scope checklist, integration build and mapped test scenarios.
Your application APIs, data model, sandbox credentials and technical owner.
Walk through the implemented patient journeys with your team. Check happy paths, exceptions and the fit with your operational workflows.
A demonstrated build and an agreed list of fixes before formal testing.
Product and operational feedback on the demonstrated flows.
Coordinate applicable functional testing and Web Application Security Assessment with the required assessment agencies. Resolve findings and support retesting.
Test reports, assessment evidence and a tracked remediation log.
A stable test environment, assessor coordination and agreed audit scope and fees.
Demonstrate the corrected build again after testing. Review evidence, unresolved items and the scenarios to be presented externally.
A reviewed demo build and a consolidated submission checklist.
Your sign-off on the corrected workflows and outstanding dependencies.
Support the scheduled NHA review, present the applicable workflows and evidence, and respond to questions or requested changes.
A review-action log, responses and any follow-up demonstrations required.
Stakeholder availability and timely decisions on review feedback.
Plan for the website-listing and feedback stage in our delivery sequence. Monitor comments and address any issues raised before moving forward.
Tracked feedback, responses and any changes required for closure.
Allow for the 15-day window and follow-up work. The applicable listing duration and requirements are confirmed with the ABDM team.
After applicable approvals and production access, configure the live environment, onboard facilities and validate the agreed production workflows.
A rollout checklist, operational runbook and engineering handover.
Production owners, infrastructure readiness and an agreed rollout window.
Review findings can call for another demo or a retest, so the plan keeps room for one remediation cycle before the NHA committee. ABDM FAQs ↗
Cost drivers
You get a fixed scope and price after one scoping call. These factors move it.
M1 with M2 is the common minimum for sandbox exit. Adding M3 adds consent requests and record display.
Each FHIR record type (OP consult, prescription, diagnostic report, discharge summary and others) is its own mapping and test set.
Coded data maps quickly. Free-text reports and missing fields need extra mapping and review.
One product, several products, or a multi-tenant HMIS with many facilities.
Functional testing and WASA are paid to empanelled agencies, separately from engineering.
Claims integration is a separate track; ABDM API changes need monitoring and updates after go-live.
Proof
Client names are withheld. The case study and repositories linked here are public.
A foundation-run primary-care screening platform with an Android app and a web app. We built the M2, M3, FHIR and encryption layers, extended M1, fixed functional-test and WASA findings and supported every NHA demo. NHA approved the M1, M2 and M3 implementation in 2026.
Read the ABDM sandbox exit case study →Interoply, our integration platform, includes ABDM and NHCX connectors so several applications share one gateway, one consent experience and one FHIR mapper.
See Interoply →Our TypeScript SDK for the ABDM V3 APIs: ABHA, HIP, HIU, consent and health information exchange.
View the SDK on GitHub →Example FHIR R4 bundles for the ABDM record types, published alongside our V3 error catalog and Postman collection.
View the bundle examples on GitHub →We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.
FAQ
An ABDM integration service provider adds Ayushman Bharat Digital Mission flows to your existing software: ABHA creation and linking (M1), sharing records as a Health Information Provider (M2) and requesting records as a Health Information User (M3). The work includes FHIR mapping, encryption, gateway callbacks, functional testing and WASA support, the NHA demo and production rollout.
M1 is identity: create, verify and link ABHA at registration. M2 makes your software a Health Information Provider that shares FHIR records on consent. M3 makes it a Health Information User that requests and displays records from other providers. Each milestone is demonstrated to NHA before sandbox exit.
No. NHA's current sandbox exit criteria require at least two milestones, so an M1-only integration does not receive production credentials. Most teams pair M1 with M2; products that mainly consume records pair M1 with M3.
M4 is an informal label some teams use for claims integration through the National Health Claims Exchange (NHCX). NHCX runs on the same national digital health rails but is a separate track with its own participant onboarding, FHIR claim profiles and insurer testing. We scope it separately from M1 to M3.
No. ABDM is added beside your existing software: new registration, consent and record-sharing flows inside your application and a small number of new screens. Your clinical modules stay as they are.
An ABDM connector is a shared service that handles the ABDM gateway, callbacks, encryption, consent and FHIR mapping for one or more applications. Hospital groups, state programs and multi-product vendors use one connector so each application does not rebuild the same plumbing. Interoply includes an ABDM connector.
ABDM uses the NRCES FHIR R4 profiles: OPConsultRecord, PrescriptionRecord, DiagnosticReportRecord, DischargeSummaryRecord, ImmunizationRecord, HealthDocumentRecord, WellnessRecord and InvoiceRecord. You agree with NHA which record types your product shares, based on the services it provides.
WASA is the Web Application Security Assessment, a security audit by a CERT-In empanelled auditor. Functional testing of the milestones is done by an independent empanelled testing agency. Both reports go to NHA before the review demo and sandbox exit. We coordinate both and fix the findings.
Most products reach sandbox exit in 12 to 20 weeks. The build usually takes 6 to 10 weeks; agency testing, audit fixes and NHA review slots take the rest. Multi-tenant products then onboard each facility through HFR.
Cost depends on the milestones and record types in scope, the quality of your source data, the number of applications or tenants, and whether NHCX is included. Testing and audit agency fees are paid separately to those agencies. We give a fixed engineering price after one scoping call.
Sandbox credentials and a reachable bridge URL, HFR registration, the milestones and record types agreed with NHA, ABHA flows at registration, FHIR mappings for each record type, Fidelius encryption, every consent path rehearsed, functional test and WASA reports, the NHA demo and the exit application listing every milestone.
They need it when their customers, government schemes or tenders ask for ABHA linking and consent-based record sharing. Labs and diagnostics platforms usually share diagnostic reports as a HIP (M2); telemedicine apps often add HIU (M3) to see prior records. We confirm the right milestones for your product on the first call.
Next step
Tell us your product, stack, milestones and target date. We reply with the record types to take through review, the timeline to sandbox exit and a fixed scope.
Bring your current stack, milestone status and target date. We’ll review your scope, identify dependencies and recommend the next engineering step.
Baner, Pune,
Maharashtra 411045
Iselin,
NJ 08830
An engineer who has actually shipped ABDM will reach out within one business day.
