ABDM Sandbox to Production: Milestones M1, M2 and M3

Register your organisation and product on the ABDM sandbox portal. On approval you receive a client ID and secret for the sandbox, and you register your bridge: the callback URL where the gateway will send responses. You will also need test facilities in the sandbox Health Facility Registry.

Decide which milestones you need. A hospital system usually builds all three; a lab system may need M1 and M2; an insurer or a teleconsultation tool may focus on M1 and M3.

Build an internal test harness early. Clicking through the PHR app by hand for every test does not scale.

When the build is complete you apply for functional testing. An agency empanelled by NHA runs your product against the test cases for each milestone, usually over screen-share on the sandbox. Expect them to check mandatory flows, error handling and that the user interface shows what the specifications require, such as consent details.

You then need a web application security assessment, commonly called WASA, by a CERT-In empanelled auditor, resulting in a safe-to-host certificate. The auditor tests the application and its ABDM flows against common vulnerability classes. Findings must be fixed and retested before the certificate is issued, so budget time for at least one round of remediation.

With functional test approval and the security certificate, you submit the sandbox exit application with the required documents. After review, production credentials are issued. You then register real facilities with their HFR IDs, switch endpoints and run a controlled go-live at one facility before rolling out.

For a team that already has a working hospital or lab system, the build for all three milestones commonly takes two to four months, with testing, audit and exit adding roughly six to ten weeks. Delays usually come from waiting for test slots, audit remediation, and FHIR mapping that was left late. Starting the audit engagement before development finishes shortens the tail.