What does M1 ABDM certification require for hospital management software in 2026?

M1 is the foundation milestone — ABHA creation + verification at patient registration. Your HMS must: (1) Register on NHA's ABDM sandbox at sandbox.abdm.gov.in (2-4 weeks approval); (2) Implement ABHA Number creation API (Aadhaar OTP, mobile OTP, email OTP, fallback workflows); (3) Implement ABHA Address creation; (4) Implement ABHA verification API (verify existing ABHA against NHA central database); (5) Store ABHA-patient linkage in your local database with audit trail; (6) Implement ABHA QR code scanning (patients show QR for verification); (7) Pass NHA's standardized M1 functional testing scenarios. Timeline: 2-4 weeks for experienced team, 6-10 weeks for first-time vendors. Once approved, you can accept ABHA-linked patients but cannot yet share records (that's M2).

Why is M2 (HIP - Health Information Provider) the hardest ABDM milestone?

M2 requires converting all your hospital's patient records into FHIR R4 format (international healthcare data standard with hundreds of resource types — Patient, Observation, MedicationRequest, DiagnosticReport, AllergyIntolerance, etc.) AND implementing the full HIP workflow: care context creation, patient discovery, consent verification via HIE-CM, secure encrypted record transfer, audit logging. Why it's hardest: (1) FHIR R4 mapping — your existing data schema must map to FHIR resources, complex for hospitals with legacy data; (2) Encryption + key management — public/private key infrastructure for record transfer; (3) Consent flow integration with HIE-CM is async + requires patient app interaction; (4) FHIR validation strict — NHA sandbox rejects malformed FHIR; (5) Many edge cases — partial consent, expired tokens, retries, error handling. Timeline: 4-12 weeks depending on data maturity. Most M2 delays come from FHIR R4 conversion of legacy data, not API integration itself.

What does M3 (HIU - Health Information User) certification add over M2?

M3 flips your HMS's role from serving records to consuming records. After M2 your HMS shares records when asked; after M3 it can request records from other HIPs in the ABDM network. Implementation: (1) Consent request API — your HMS triggers consent request to patient via their ABHA app; (2) Patient approves on ABHA app; (3) HIE-CM issues consent token; (4) Your HMS uses token to request records from source HIPs; (5) Process FHIR R4 response — parse + display in doctor's UI. Timeline: 2-4 weeks (shares infrastructure with M2). Why it's easier than M2: most of the technical complexity (FHIR R4 parsing, encryption, consent flow) was solved during M2; M3 is mostly UI integration for displaying imported records to doctors. Real-world impact after M3: your doctors can pull patient's history from previous hospitals (with consent), enabling better clinical decisions + fewer duplicate tests.

What is Safe-to-Host certificate and why is it mandatory for ABDM production access?

Safe-to-Host is the mandatory web application security audit certificate required before NHA grants ABDM production access. Conducted by STQC (Standardisation Testing and Quality Certification) or CERT-IN (Indian Computer Emergency Response Team) empanelled security testing agencies. Audit scope: OWASP-10 web application vulnerabilities (SQL injection, XSS, CSRF, broken authentication, etc.), authentication + session management, input validation, encryption (TLS in-transit + AES-256 at-rest), API security, audit logging, DPDP Act 2023 compliance. Process: hospital + HMS vendor engages CERT-IN empanelled agency, undergoes black-box + grey-box testing (2-4 weeks), receives Safe-to-Host certificate (valid 1-2 years, renewable). Cost: ₹50K-₹2L depending on application size + auditor. List of CERT-IN empanelled agencies: cert-in.org.in. Without Safe-to-Host, NHA denies production access regardless of M1/M2/M3 certification — non-negotiable.

How long does the complete ABDM M1+M2+M3 certification process take in India 2026?

Realistic timelines for hospital with existing digital HMS. NHA sandbox registration: 2-4 weeks (approval + sandbox access). M1 implementation + testing: 2-4 weeks. M2 implementation (most technical): 4-12 weeks. M3 implementation: 2-4 weeks (parallel to/after M2). Safe-to-Host security audit: 2-4 weeks (can run parallel to M3). NHA final approval submission + production access grant: 2-3 weeks. Total: 16-31 weeks (4-7 months) for hospital with existing infrastructure. For hospital running paper/Excel needing full HMS + ABDM build: 8-12 months. Implementation rollout (data migration, staff training, parallel run): adds 4-12 weeks. Most common delay: M2 FHIR R4 data mapping if legacy data is messy. Vendors with pre-built ABDM modules (Codingclave's bolt-on template) compress this to 8-12 weeks.

What's the difference between ABDM sandbox and production environment?

Sandbox (sandbox.abdm.gov.in) is the testing environment where vendors develop + test ABDM integration before going live. Production (abdm.gov.in) is the live environment where real ABHA IDs, real patient records flow. Sandbox: (1) Free access after NHA approval; (2) Mock ABHA IDs for testing; (3) Fake/test patient records; (4) Standardized test scenarios for M1/M2/M3 functional testing; (5) Used for security testing too. Production: (1) Granted only after NHA approves M1/M2/M3 certification + Safe-to-Host certificate; (2) Real ABHA + real patient data; (3) Subject to DPDP Act 2023 obligations; (4) Production access can be revoked for violations. Vendors must complete full certification in sandbox before any production access. Most rejections happen at sandbox exit stage due to missing documentation (Safe-to-Host, WASA report, deployment details) or failed M2 FHIR validation.

What documents do I need to submit to NHA for ABDM production access?

Sandbox exit / NHA final approval bundle: (1) M1 milestone approval letter from NHA; (2) M2 milestone approval letter; (3) M3 milestone approval letter; (4) Safe-to-Host certificate from CERT-IN empanelled agency; (5) WASA (Web Application Security Assessment) final report; (6) Deployment architecture document (production infrastructure details, hosting region, security architecture); (7) Data flow diagram showing ABDM-related data paths; (8) DPDP Act compliance attestation; (9) HFR registration (hospital registered on Health Facility Registry); (10) HPR registration evidence (sample doctors registered on Healthcare Professional Registry); (11) Privacy policy + terms of service documents; (12) Vendor agreement / system integration agreement with hospital. Submit bundle via NHA portal; review takes 2-3 weeks. Common rejection causes: incomplete documents, security audit findings not remediated, deployment architecture concerns. Re-submission after fixes adds 2-4 weeks.

Can a hospital reuse another hospital's ABDM-certified HMS or does each hospital need its own certification?

Per-software certification, NOT per-facility. Once a HMS vendor's software is M1/M2/M3 + Safe-to-Host certified by NHA, ANY hospital deploying that software inherits the certification. Hospital only needs to: (1) Register on HFR (Health Facility Registry — free, hospital-level registration); (2) Get HPR for each doctor; (3) Configure their instance with their HFR + HPR IDs; (4) Submit deployment confirmation to NHA. This is why pre-built ABDM-compliant SaaS (Medixcel, MocDoc, Adrine) deploys faster — vendor already cleared certification, hospital just configures. Custom HMS path: your custom HMS must clear certification first (3-6 months), then hospital deploys (additional 2-4 weeks for HFR/HPR/configuration). Both vendor (HMS company) AND hospital (deploying entity) named in NHA's certified facilities list.

ABDM M1/M2/M3 Certification Guide India 2026: NHA Sandbox to Production

If you're a hospital decision-maker or HMS vendor needing to understand the exact technical path to ABDM-certified production access — M1 → M2 → M3 + Safe-to-Host security audit + NHA final approval — this is the deep-dive guide.

I'm Ashish Sharma, founder of Codingclave. We've shipped 6 ABDM-integrated hospital management software builds since 2024, including 2 that cleared NHA M3 production approval. This guide is the actual playbook + timelines + costs based on real certifications.

For broader ABDM context, start with our pillar guide: ABDM Compliance Hospital India 2026.

WhatsApp me for ABDM certification help →

TL;DR — Complete Certification Path

Stage	Duration	What Happens
Sandbox Registration	2-4 weeks	NHA approval for ABDM sandbox access (sandbox.abdm.gov.in)
M1: ABHA Foundation	2-4 weeks	Build + test ABHA creation/verification, pass M1 functional tests
M2: HIP Functionality	4-12 weeks	Build FHIR R4 record sharing + consent management, pass M2 tests
M3: HIU Functionality	2-4 weeks	Build record-request capability, pass M3 tests
Safe-to-Host Audit	2-4 weeks	CERT-IN/STQC empanelled agency conducts OWASP audit
NHA Final Approval	2-3 weeks	Submit bundle (milestones + Safe-to-Host + deployment docs), production access granted
Production Deployment	4-12 weeks	Data migration, staff training, parallel run, cutover
Total	20-43 weeks (5-10 months)	From kickoff to live ABDM-compliant production

Stage 1: NHA Sandbox Registration

Where: sandbox.abdm.gov.in

What you submit:

Hospital details (or HMS vendor company details)
Type of integration (HIP, HIU, both)
Technical contact person
Proposed integration scope (M1/M2/M3)
Hospital's intent (PM-JAY empanelment, state scheme, etc.)

What you get after approval:

Sandbox API credentials
Test ABHA IDs for development
Access to NHA's documentation portal
Sandbox subdomain for your integration testing

Timeline: 2-4 weeks for approval (was longer in 2023-2024, faster now)

Common rejection causes:

Incomplete company / hospital documents
Unclear integration scope
Missing technical contact

Cost: Free

Stage 2: M1 — ABHA Foundation (2-4 weeks)

Technical Requirements

Your HMS must implement these ABHA APIs:

API	Purpose	NHA Endpoint
ABHA Number Creation (Aadhaar OTP)	Create new ABHA via Aadhaar verification	`/v3/profile/account/abha/registration/aadhaar`
ABHA Number Creation (Mobile OTP)	Create new ABHA via mobile OTP	`/v3/profile/account/abha/registration/mobile`
ABHA Address Creation	Create human-readable address (e.g., username@abdm)	`/v3/profile/account/abha-address`
ABHA Verification	Verify existing ABHA against NHA database	`/v3/profile/account/login`
ABHA QR Generation	Generate patient's ABHA QR code	`/v3/profile/account/qrCode`
ABHA Profile Fetch	Retrieve patient's profile data	`/v3/profile/account`

M1 Functional Test Scenarios

NHA tests your HMS against standardized scenarios:

Patient walks in with Aadhaar — create ABHA via Aadhaar OTP
Patient walks in without Aadhaar — create ABHA via mobile OTP
Patient has existing ABHA — verify via OTP
Patient shows ABHA QR — scan + verify
OTP timeout — handle gracefully
Network failure mid-creation — handle retry
Patient cancels mid-flow — handle correctly
Already-registered phone — fetch existing ABHA

M1 Pass Criteria

All 8+ standardized scenarios pass
ABHA-patient linkage stored locally with audit trail
Error handling per NHA specification
Documentation submitted

M1 Common Failures

Missing fallback workflows (Aadhaar fails → no mobile fallback)
Improper consent capture during ABHA creation
Audit trail incomplete
ABHA QR scanning not implemented

What M1 Gets You

Your hospital can accept ABHA-linked patients + start building ABHA database. Cannot share records yet (M2).

Stage 3: M2 — HIP (Health Information Provider) — The Hard One

Why it's the most technically demanding milestone: You're building a fully-fledged FHIR R4 record-sharing system with patient consent, encryption, and audit logging.

Technical Architecture for M2

Core components your HMS must build:

FHIR R4 Resource Mapping Layer
- Map your existing patient data schema to FHIR R4 resources
- Common resources needed: Patient, Practitioner, Organization, Encounter, Observation (lab results, vitals), Condition (diagnoses), MedicationRequest (prescriptions), DiagnosticReport, DocumentReference, AllergyIntolerance, Procedure
- Strict FHIR R4 validation required by NHA sandbox
Care Context Creation
- Every patient interaction at your hospital becomes a "care context"
- Care context linked to patient's ABHA
- Linked records become discoverable via ABDM
Patient Discovery
- When other systems search for a patient's records, your HMS must respond
- Discovery via ABHA address or mobile/Aadhaar (with consent)
HIE-CM Consent Integration
- Receive consent request notifications from HIE-CM
- Validate consent token before sharing any record
- Honor consent scope (only share what consent allows)
- Honor consent expiry
Encrypted Record Transfer
- Asymmetric encryption: HIU's public key encrypts records, only HIU's private key decrypts
- Records sent via secure data push to HIE-CM, then forwarded to HIU
- TLS 1.3 transport encryption
Audit Logging
- Every record share logged: who requested, when, what records, consent details
- Logs retained 5+ years per DPDP Act
- Logs available for NHA inspection

M2 Functional Test Scenarios

HIU requests patient records — your HMS receives notification, requests consent
Patient grants consent on their ABHA app
Your HMS encrypts requested records in FHIR R4, sends to HIE-CM
HIU receives + decrypts records
Audit log entries verified
Patient revokes consent — your HMS stops sharing immediately
Expired consent token — your HMS rejects record request
FHIR R4 validation — all resources pass strict validation

M2 Pass Criteria

Full FHIR R4 record sharing working end-to-end
HIE-CM consent integration functional
Encryption + audit logging implemented
All standardized test scenarios pass

M2 Common Failures

FHIR R4 validation errors (most common — partial implementation, missing required fields)
Consent token validation gaps (HMS accepts expired or invalid tokens)
Audit logging incomplete (missing required fields per NHA spec)
Performance issues (sharing 100+ records takes too long; NHA tests timeouts)
Encryption errors (improper key management, wrong cipher modes)

M2 Real-World Timeline

Hospital with clean structured data + experienced team: 4-6 weeks
Hospital with messy legacy data: 8-12 weeks (FHIR conversion is the bottleneck)
First-time vendor: 10-16 weeks (learning curve on FHIR R4 + ABDM flows)

What M2 Gets You

Your hospital is now a fully ABDM-compliant HIP. Patient records are shareable across the ABDM network with consent. PM-JAY empanelment now feasible (state schemes increasingly require M2-certified vendors).

Stage 4: M3 — HIU (Health Information User) — The Easy Win

M3 is essentially M2's mirror image. After serving records (M2), you can now request records.

Technical Components

Consent Request UI
- Doctor's screen has "Pull Patient History" button
- Triggers consent request via your HMS → HIE-CM → patient's ABHA app
- Patient receives notification, grants consent
Health Information Request
- Once consent granted, your HMS requests records from source HIPs
- Receives encrypted FHIR R4 bundle
Record Display in Doctor UI
- Parse imported records, display in patient's chart
- Categorize by type (lab reports, prescriptions, discharge summaries)
- Maintain audit trail (which records came from where)

M3 Functional Tests

Doctor requests patient history — consent request goes to patient
Patient approves on ABHA app
Your HMS receives + displays records
Audit log entries verified
Patient denies consent — your HMS handles gracefully

M3 Real-World Timeline

2-4 weeks (shares infrastructure with M2)
Most effort is UI work to display imported records well to doctors

What M3 Gets You

Doctors can pull patient's full medical history from any ABDM-network hospital. Massive clinical value — fewer duplicate tests, better diagnoses, no missing critical information.

Stage 5: Safe-to-Host Security Audit (Mandatory)

What It Is

Web application security audit by CERT-IN or STQC empanelled agency. Required before NHA grants production access.

Audit Scope

OWASP Top 10 vulnerabilities — SQL injection, XSS, CSRF, broken auth, sensitive data exposure, XML external entities, broken access control, security misconfiguration, vulnerable components, insufficient logging
Authentication + session management — login security, session timeout, MFA where required
Input validation — all user inputs sanitized
Encryption — TLS 1.3 in-transit, AES-256 at-rest
API security — rate limiting, authentication, input validation
Audit logging — comprehensive logs for security events
DPDP Act 2023 compliance — patient data protection measures

Process

Choose CERT-IN empanelled agency (list at cert-in.org.in)
Provide application access (test environment) + documentation
Agency conducts black-box + grey-box testing (1-3 weeks)
Agency issues vulnerability report
You remediate findings (1-2 weeks)
Re-test
Agency issues Safe-to-Host certificate (valid 1-2 years)

Cost

₹50K-₹2L depending on application size + auditor
Larger apps + premium auditors charge more

Common Failures

Found vulnerabilities not remediated in time
Audit logs insufficient
Encryption not properly implemented (using deprecated TLS versions)
Authentication weak (no MFA for admin accounts)

Stage 6: NHA Final Approval — Production Access

Document Bundle to Submit

M1 milestone approval letter (from NHA)
M2 milestone approval letter
M3 milestone approval letter
Safe-to-Host certificate from CERT-IN agency
WASA (Web Application Security Assessment) final report
Deployment architecture document
Data flow diagram
DPDP Act 2023 compliance attestation
HFR registration certificate (hospital)
HPR registration evidence (sample doctors)
Privacy policy + terms of service
Vendor agreement / system integration agreement

Process

Submit bundle via NHA portal
NHA review (2-3 weeks)
Possible questions / clarifications
Final approval → production credentials issued
Production deployment begins

Common Rejection Reasons

Incomplete documentation (missing one of the 12 documents)
Security audit findings not remediated
Deployment architecture concerns (e.g., hosting outside India for sensitive data)
DPDP Act compliance gaps

Re-submission after fixes adds 2-4 weeks.

Cost Breakdown: Full M1/M2/M3 Certification

For a hospital working with a vendor on full certification:

Component	Cost
NHA Sandbox Registration	Free
M1 Implementation (vendor cost)	₹1.5L-₹3L
M2 Implementation (vendor cost — most expensive)	₹3L-₹7L
M3 Implementation (vendor cost)	₹1.5L-₹3L
Safe-to-Host Audit (CERT-IN agency)	₹50K-₹2L
NHA Application Fees	Free / Nominal
HFR + HPR Registration	Free
Total Certification Cost	₹6.5L-₹15L

Additional costs:

Hospital staff training: ₹50K-₹2L
Data migration: ₹50K-₹3L
Ongoing maintenance (yearly): ₹50K-₹3L

How Codingclave Handles ABDM Certification

We've cleared M1/M2/M3 + Safe-to-Host for 2 hospital deployments since 2024, with 4 more in progress. Our standard delivery:

Scope	Timeline	Cost
M1 only (basic ABHA verification)	4-6 weeks	₹2L-₹4L
M1 + M2 (HIP-ready, can share records)	12-18 weeks	₹5L-₹10L
M1 + M2 + M3 (full HIP + HIU certified)	16-24 weeks	₹6.5L-₹13L
Full certification + Safe-to-Host coordination	18-26 weeks	₹7L-₹15L
Hospital training + go-live support	+2-4 weeks	+₹1L-₹3L

Every certification project includes: NHA sandbox setup, FHIR R4 implementation, HIE-CM consent integration, encryption + audit logging, Safe-to-Host audit coordination with CERT-IN partners, document bundle preparation for NHA, post-certification support.

Get ABDM Certified Faster

If you're starting from scratch, expect 5-10 months. If you have an existing custom HMS, we can typically cut that to 4-7 months via our pre-built ABDM modules. If you're stuck mid-certification (failed M2, security audit issues, NHA rejection), we can step in and complete.

WhatsApp Ashish for ABDM certification help →

Or schedule a 30-minute call →

About the Author

Ashish Sharma is the founder of Codingclave, a Top Rated Upwork agency that has shipped 6 ABDM-integrated hospital management software builds since 2024 — including 2 with NHA M3 production approval. Reach him on LinkedIn or WhatsApp.

Related reading: