ABDM Sandbox Exit Case Study: AffEx Health Platform Through M1, M2 and M3

Summary

This ABDM sandbox exit case study follows AffEx Health Platform, an initiative of the Anjani Mashelkar Foundation (AMF), a Maharashtra-based foundation that runs a screening platform for primary healthcare. Health workers take readings from medical devices at community screening sites and record each visit in an Android app and a web application. The foundation wanted those records to follow the patient: linked to the patient's ABHA (Ayushman Bharat Health Account) and shared only with the patient's consent through the Ayushman Bharat Digital Mission (ABDM).

Nirmitee built most of the platform's ABDM layer, working with the foundation's in-house technical lead, and then took the platform through the National Health Authority (NHA) review with the foundation. NHA approved the M1, M2 and M3 implementation in May 2026. An independent agency completed functional testing, the security audit findings were fixed, and NHA's committee demo took place in July 2026. Production ABDM settings were deployed in August 2026.

At a glance

• Client: AffEx Health Platform, an initiative of the Anjani Mashelkar Foundation (Maharashtra), running a point-of-care screening platform
• Scope: ABDM M1 (ABHA creation and verification), M2 (sharing records as a health information provider) and M3 (requesting records as a health information user)
• Health record types: Health Document Record, Wellness Record (including women's health observations), OP Consult Record and Prescription Record
• Stack: NestJS and PostgreSQL backend, Next.js web application, Android app
• Nirmitee's role: built the M2, M3, FHIR and encryption layers and extended the ABHA flows; fixed functional-test and security-audit findings; supported the foundation through every NHA demo
• Period: March to August 2026
• Status: NHA review completed and production settings deployed in August 2026. The foundation's production facility registration was still being completed when this was written, so this page makes no claim about live record volumes.

Who this is for

This case study is for three kinds of reader. The first is a founder or CTO of an HMIS, EMR, lab or health-app company whose customers now ask for ABDM. The second is an IT head at a hospital or clinic chain whose software vendor has built ABDM APIs but has not yet cleared NHA review. The third is a public-health or CSR programme that records patient data in the field and wants those records to count in the national health record system. All three are the buyers of Nirmitee's ABDM integration services.

What was at stake

Getting ABDM API calls to work in the sandbox is the easier part. The hard part is what comes after: NHA has to approve the implementation, an outside agency has to test every milestone, a security audit has to pass, and the team has to show the flows live to NHA reviewers before production access is granted. Each step can send the work back.

Our custom healthcare software development team builds and extends platforms like this one.

For a screening programme, the payoff is continuity. A reading taken at a rural screening site is only useful later if a doctor elsewhere can see it. With ABDM, the record is linked to the patient's ABHA and can be pulled by another provider once the patient gives consent. Without it, the record stays inside one programme's database. For what hospitals themselves are expected to show, see our ABDM compliance guide for hospitals.

What Nirmitee did

1. Agreed the record scope with NHA first. A screening platform does not produce discharge summaries or immunization records. The foundation asked NHA to approve four record types that match the service, and NHA approved that scope. When NHA later asked for women's health observations under the Wellness Record, the team added them to the FHIR bundle two days later.
2. Extended ABHA creation and verification (M1). The foundation's technical lead started the ABHA work. Nirmitee extended it: Aadhaar OTP and mobile OTP flows, ABHA address, the ABHA card, and linking the ABHA to the patient at registration.
3. Built the provider side (M2). Care-context discovery, including discovery started by the patient from a health app, link and confirm, consent notifications, and the health-information request that builds, encrypts and sends the records.
4. Built the requester side (M3). Consent requests, consent status, fetching approved records, and receiving and decrypting them for display to authorised staff.
5. Took the platform through NHA review with the foundation, one stage at a time (see the table below).
6. Moved the platform to production settings in August 2026, including the production gateway configuration and token handling.

The milestone boundaries follow our ABDM M1 to M4 milestones guide. For the general steps behind each stage, see our ABDM certification process guide.

Explore our healthcare interoperability solutions for consent-based health data exchange.

The review path, stage by stage

Stage	When	What happened
Scope and approval request	April 2026	The foundation told NHA that M1, M2 and M3 were built and asked for approval of four record types. NHA required a review demo first.
NHA review demo	April to May 2026	After a review demo and a follow-up video, NHA approved the M1, M2 and M3 implementation and asked the team to proceed to functional testing and the security audit.
Functional testing and security audit	June 2026	An independent testing agency tested all three milestones. Nirmitee fixed the security audit findings and the defects found in testing. The functional test report went to NHA on 2 July.
NHA internal demo	July 2026	NHA confirmed M1 and M2 worked "as per ABDM standards" with no changes needed. Two M3 consent flows failed during the demo. The team fixed them and sent videos the next day, and NHA approved M3.
Mock drill and sandbox exit	July 2026	A mock drill with NHA, a signed undertaking from the foundation, and the sandbox exit application.
Committee demo	July 2026	The final demo to NHA's committee. The foundation reported that it "went well".
Production	August 2026	Production settings deployed. A later demo found some flows still pointing at sandbox settings, and they were moved to NHA's production test facility the next day. Facility registration for day-to-day use was still in progress at the time of writing.

What went wrong, and what changed

Several things went wrong along the way, and each changed how the team worked.

• Two consent flows failed in front of NHA. In the July internal demo, fetching records after a consent was granted, and after a consent was edited, both failed. The team fixed both and sent recorded proof the next day. The lesson: rehearse every consent path end to end before a demo, not only the common ones.
• Duplicate patient records broke discovery. When a patient started discovery from a health app, patients registered twice with the same ABHA details caused the match to fail. The fix made discovery handle duplicate ABHA details correctly, and the verification and linking flows now stop duplicate profiles from being created, so each ABHA points to one patient record.
• An ABDM update reached field users without release notes. In June a change went out without advance notice, and the foundation asked the team to go back to sharing release notes before each update. The team agreed. ABDM changes touch the registration screens health workers use every day, so they need warning.
• The exit application showed only M1. NHA's portal listed only one milestone on the exit application, so a support ticket had to be raised to add M2 and M3.
• Production settings were incomplete at first. In late August a demo showed the ABHA flows still pointing at sandbox settings. The settings were moved to NHA's production test facility the next day, pending the foundation's own facility registration.

What the client got

• ABHA creation and verification inside the registration flow the health workers already use
• Screening, consultation and prescription records that a patient can share with another provider, and that the platform can request from others, all under the patient's consent
• FHIR records built on India's national (NRCES) profiles and encrypted the way the ABDM gateway expects
• NHA approval of all three milestones, a completed committee demo, and production settings in place
• A record of each review stage, which the foundation can reuse for later ABDM work

When this applies to you

• Your ABDM APIs work in the sandbox, but you have not yet booked functional testing or the security audit.
• Your product is not a hospital system (a screening, diagnostics, wellness or field-health platform) and you are unsure which record types to take through review.
• NHA has asked for a demo and you are not sure every consent path will hold up live.
• You have left the sandbox but production access, facility registration or bridge settings are not finished.

For a larger hospital suite, see our multi-module HIMS ABDM case study.

For your engineering team

• Services: separate ABHA, care-context, linking, HIP data, HIU, scan-and-share, gateway and crypto modules in a NestJS backend.
• M2 callbacks: discovery (including patient-initiated discovery, which is asynchronous in the V3 APIs), link init and confirm, token callbacks, consent notify and the health-information request.
• M3: consent init, status, fetch and notify, then the health-information request and the encrypted push back to the platform.
• FHIR: document bundles on the NRCES profiles for the four approved record types, including the women's health observation profile. See ABDM FHIR bundles across the patient journey.
• Encryption: Fidelius-compatible key exchange on Curve25519, producing the key material and nonce the gateway expects.
• Lessons: keep callback payloads from being stripped by response filters, and handle duplicate ABHA details before discovery rather than after. For the HIU side in depth, read building an ABDM HIU from scratch.

Book an ABDM readiness review

If your product is in the ABDM sandbox, or stuck between sandbox and production, Nirmitee can review where it stands against NHA's review stages: record-type scope, each consent path, functional-test readiness, security audit exposure and production settings. You get a written list of what will fail review and what to fix first. Nirmitee is ISO 27001:2022 certified. Request an ABDM readiness review.

Prefer to talk first? Talk to our team.