ABDM M1 Implementation Guide- Unified ABHA and Aadhaar Workflow

India’s Ayushman Bharat Digital Mission (ABDM) and the ABHA (formerly Ayushman Bharat Health Account) are reshaping digital healthcare in the country. For telemedicine platforms, completing the ABDM M1 milestone (ABHA generation & Aadhaar verification flows) is foundational. Yet existing NHA/ABDM guidance is fragmented and sometimes dated, leaving implementers to stitch together multiple documents and videos.

At Prologic Technologies, we’ve implemented secure, large-scale HealthTech solutions for US and EU clients for over a decade- HIPAA and GDPR compliant- and we recently consolidated M1 use cases into a single, practical infographic for Vedic Connect (an Ayurveda-focused telemedicine app we’re building with Ayurverse Integrative Solutions LLP).

This ABDM M1 Implementation Guide walks you through the unified M1 workflow, practical implementation tips, edge cases, and recommended APIs, helping other companies deliver ABDM-enabled telemedicine products faster and with fewer compliance gaps.

Why M1 Matters for Telemedicine?

• ABHA / ABDM M1 integration is the gateway for all downstream ABDM milestones (M2–M4).
• Correctly handling Aadhaar/other verification paths avoids user friction and regulatory rework.
• Unified, production-ready flows reduce development time, minimize QA churn, and improve patient trust.

The Unified Snapshot We Built

We produced a comprehensive ABDM M1 Implementation Guide that captures every major verification method and the alternate paths implementers must support for M1. The diagram unifies:

• New ABHA creation (enter Aadhaar -> send Aadhaar OTP -> consent -> fetch ABHA)
• Existing ABHA retrieval paths (via ABHA number, mobile number, or ABHA address)
• Alternate verification methods (Aadhaar-linked mobile OTP, communication mobile OTP, ABHA address verification)
• ABHA address selection or creation and download of ABHA card
• Error and retry flows, timeouts, and suggested UX states for OTP expiry/resend
• API call mapping (GET/POST) to NHA endpoints for each stage

Core M1 use cases and flows, and how we handled them

• New user with Aadhaar and linked mobile:
  • Flow: Aadhaar entry → Aadhaar OTP → Consent → Fetch ABHA details → Create ABHA.
  • Recommendation: Pre-validate Aadhaar format, show clear consent language referencing NHA’s purpose, and surface ABHA address suggestions from NHA before allowing free-text creation.
• New user with Aadhaar but different communication mobile:

• • Flow: Aadhaar OTP checks Aadhaar-linked mobile; if mismatch, request communication mobile OTP; verify; link to ABHA creation.

• • • • Recommendation: Add UX clarity when mobile differs, avoid auto-assuming linkage; log both numbers’ verification attempts for audit.

• • Existing ABHA holder trying to re-register:

    • • Flow: Enter ABHA number or ABHA address → fetch ABHA details → allow user to download ABHA card.

    • • Recommendation: Offer “I already have ABHA” quick path to reduce friction. Provide clear recovery/merge paths if users have multiple ABHAs.

• • Users without Aadhaar or unwilling to use Aadhaar:

    • • Flow: Support ABHA creation via alternate verified identifiers and ABHA address verification per NHA guidelines.

    • • Recommendation: Ensure fallbacks (mobile verification, profile-based verification) are obvious and clearly described in-app to reduce drop-offs.

• • ABHA address creation and selection:

    • • Flow: After verification, show suggested ABHA addresses returned by ABDM address suggestions API; allow user to choose or create a new ABHA address (3–30 characters).

    • • Recommendation: Enforce address rules client-side to reduce server-side validation errors; provide inline help text.

Technical checklist – APIs, security, and logging

• • API mapping: Maintain a clear map of which ABDM/NHA endpoints are called for each step (e.g., POST sendAadhaarOTP, POST verifyAadhaarOTP, GET abhaProfile, GET abhaCard, GET addressSuggestions).

• • OTP handling: Implement strict expiry (ABDM recommends 45 seconds in our infographic notes), resend limits, and server-side rate limiting to prevent abuse.

• • Consent capture: Store user consent text and timestamped acceptance for auditability and compliance. Link consent to the exact purpose (“Creation of ABHA number”).

• • Logging & telemetry: Log each step with correlation IDs to troubleshoot failed verification flows (Aadhaar OTP failed, ABHA fetch returned zero results, etc.).

• • Security: Ensure all ABDM traffic happens over TLS 1.2+; use secure storage for tokens and keys; rotate credentials; follow least-privilege for API access.

• • Privacy & compliance: Retain minimal PII, encrypt data at rest and in transit. For EU/US-facing parts of your platform, maintain GDPR and HIPAA controls (DSRs, access logging, data processing agreements).

     

UX patterns to reduce friction

• • Show a compact “how ABHA helps you” blurb before asking for Aadhaar.

• • Use progressive disclosure: ask for Aadhaar only when absolutely needed.

• • Give real-time feedback during OTP entry: masked mobile number, countdown timer, clear errors for incorrect OTP, and contextual help when OTP expires.

• • Offer a “Help me verify” flow with screenshots for older phones or carriers that block OTP messages.

• • For Ayurveda patients (Vedic Connect use case): let users attach practitioner codes, preferred clinic addresses or specialty tags to their ABHA profile after M1 to streamline future consults.

Testing, and QA Cases (must-have cases)

• • Happy path: new Aadhaar + linked mobile → ABHA created.

• • Mobile mismatch: Aadhaar-linked mobile != communication mobile → communication mobile OTP flow.

• • Existing ABHA: user re-enters ABHA/ABHA address → fetch and display ABHA card.

• • OTP expiry: OTP expires at 45s → resend branch and retry limit enforcement.

• • API error codes: simulate 4xx/5xx responses from NHA endpoints and verify user-facing messaging and retry behavior.

• • Rate limiting: simulate repeated OTP requests to ensure throttling and error handling.

Operational considerations and rollout plan

• • Staged rollout: internal QA → pilot with 5–10% of users → full rollout. Use pilot to monitor OTP success rates, ABHA suggestion accuracy, and drop-offs.

• • Partner channels: coordinate with NHA/ABDM onboarding, and ensure your production IPs and certificates are registered and allowed.

• • Monitoring & SLOs: measure OTP deliverability, verification success, ABHA creation rate, and ABHA fetch latency. Set SLOs for each.

• • Support preparedness: train support staff with common ABDM error codes, retry instructions, and user-facing scripts.

Why Prologic Technologies is your right HealthTech partner?

• • Proven HealthTech track record: 10+ years delivering HIPAA and GDPR-compliant telemedicine and SaaS platforms for US and EU clients.

• • ABDM experience: Hands-on working knowledge of ABDM milestones and practical implementation nuances across M1–M4.

• • End-to-end capability: From UX to backend integrations, security, compliance, and monitoring, we help you deliver ABDM-enabled telemedicine faster and more reliably.

We encourage implementers to view our consolidated ABHA – Aadhaar Verification Flow infographic (as above) – it’s a practical single-view reference for ABDM M1 Implementation Guide which maps user screens to API calls, shows alternate flows, and clarifies verification methods. Use it as a spec companion for development and QA.

We also provide turnkey ABDM integrations for Web and Mobile Applications. If your team is implementing ABDM milestones and you’d like our M1 infographic in high-resolution PNG/SVG or a tailored implementation review (API mapping, UX flows, and security audit), contact Prologic Technologies  or  book a technical review