How to Build an ABDM-Compliant Healthcare App in India

E: Engine (UHI and API Architecture)

Register your application on UHI per the BECKN protocol specification. Implement the BECKN-compliant ABDM API contract for your service type. Use a dedicated ABDM integration microservice to isolate compliance logic from your core business logic. This isolation means NHA specification updates do not require changes to your core product codebase. See how Ailoitte structures this in our AI Velocity Pods delivery model.

A: Access Control and Consent Management

The most complex pillar to build correctly. ABDM consent management operates at artefact-level granularity across four states: grant, revoke, pause, and expire. Your app must implement both HIU and HIP roles if it both generates and consumes health records. Build a consent event ledger from day one: an append-only log of all consent state changes indexed by consent artefact ID. Consent is event-sourced, not a status column in a database table.

L: Linked Registries (HPR and HFR)

Link provider profiles to HPR (Healthcare Professionals Registry) entries and facility profiles to HFR (Health Facility Registry) entries. This enables in-app credential verification, satisfies ABDM’s identity requirements for telemedicine, and makes your platform eligible for government-empanelled service listings. HPR and HFR linking are mandatory for any app where a healthcare professional delivers a service or where a facility is the point of care.

T: Telemedicine and FHIR R4 Enablement

Your teleconsultation module must generate encounter records in HL7 FHIR R4 format. This means FHIR R4-compliant consultation notes, e-prescriptions in the ABDM-defined format, and push to the patient’s Health Locker. For AI-assisted clinical documentation (LLM-assisted transcription, SOAP note generation, clinical coding), this pillar is where GenAI capabilities connect to the ABDM data layer. For a full technical implementation guide, see Ailoitte’s FHIR R4 integration guide.

H: Health Locker and Data Security

Allow patients to store PHR documents (labs, discharge summaries, prescriptions, vaccines) in a Health Locker implementation. All stored records must be in FHIR R4 format. NHA security requirements: AES-256 at rest, TLS 1.2+ for all API calls, OAuth 2.0 or OTP auth for ABHA ID access, full audit logging, and DISHA-forward architecture. Ailoitte’s ISO 27001 and SOC 2 Type II certified infrastructure provides the security baseline for this pillar from day one.

ABDM Compliance Readiness Checklist

Run this checklist before NHA onboarding submission. All Essential and Security items must pass. Test at sandbox.abdm.gov.in before applying for production credentials.

Step-by-Step: NHA Onboarding for ABDM Compliance

NHA onboarding follows a seven-step process from sandbox registration to production credentials. Understanding each step and its documentation requirements before you begin compresses the total timeline significantly.

1. Register on the ABDM Sandbox (sandbox.abdm.gov.in). Create an account and receive sandbox API credentials. Select your app category (telemedicine, EHR, e-pharmacy, diagnostic, or PHR app) during registration, as this determines which API surfaces NHA evaluates.
2. Implement required ABDM APIs in sandbox using NHA’s Integration Specification as your contract. Each app category has defined mandatory and optional API surfaces. Implement all mandatory surfaces before proceeding to testing.
3. Run the full integration test suite against NHA’s defined test scenarios: full ABHA ID creation (Aadhaar OTP and mobile OTP paths), consent grant and revoke cycle, HIP data push, HIU data fetch with consent, and Health Locker read and write. Document all test results with API call logs.
4. Submit your Integration Test Report to NHA via the Health Facility Registration portal (facility.abdm.gov.in). The report must include API call logs, consent flow documentation, and a self-certification checklist signed by your technical lead.
5. NHA technical review typically takes two to four weeks. The three most common rejection reasons: ABHA ID not a first-class schema field, consent revoke events not propagating in real time to all HIPs, and FHIR R4 records not conforming to NHA’s India profile extensions.
6. Receive production credentials after review approval. NHA issues live API keys, confirms your facility or app registration, and adds your platform to the ABDM participant registry.
7. Live monitoring period: NHA requires a 30-day live monitoring window before full certification is confirmed. Maintain audit logs and the consent event ledger with timestamps throughout this period.

ABDM-Compliant vs Non-Compliant: What It Means for Your Business

The competitive advantage of ABDM compliance is concrete across eight business dimensions. Non-compliant apps can still operate, but they are building on infrastructure that is structurally shrinking relative to the ABDM network.

Recommended Tech Stack for ABDM Integration

ABDM integration has no single mandated technology stack, but certain choices reduce integration complexity and NHA onboarding friction. This is the stack Ailoitte uses across our ABDM projects as of 2026.

DISHA and ABDM: The Regulatory Pair You Need to Know

ABDM compliance covers your technical integration with NHA’s infrastructure. DISHA (Digital Information Security in Healthcare Act) governs how digital health data is collected, stored, processed, and shared under Indian law. Building ABDM-compliant without a DISHA-forward architecture is an incomplete compliance posture.

DISHA, currently in parliamentary consideration as of June 2026, establishes four obligations directly relevant to ABDM-compliant app developers:

• Data localisation: Health data of Indian citizens must be stored on servers located within India. US or EU-based cloud regions do not satisfy this requirement. AWS Mumbai (ap-south-1), Azure India Central, and Google Cloud Mumbai all comply.
• Explicit consent architecture: DISHA requires granular, purpose-bound, time-limited consent for health data access. A correctly implemented ABDM consent event ledger satisfies most DISHA consent obligations.
• Breach notification: DISHA mandates notification to the relevant authority within 72 hours of a data breach involving personal health information. Build breach detection and notification workflows into your incident response plan from day one.
• Right of access and correction: Patients have the right to access all health records held about them and request corrections. Your patient-facing interface must expose these controls, which ABHA’s Health Locker implementation largely enables when implemented correctly.

DISHA’s penalty structure mirrors GDPR in its tiered approach, with higher penalties for intentional or negligent breaches. Ailoitte’s ISO 27001 and SOC 2 Type II certified infrastructure provides the security baseline that positions clients for DISHA compliance from day one. Ailoitte recommends a DISHA-readiness review as a standard deliverable alongside the NHA onboarding submission.

Real-World ABDM-Compliant App Examples

The strongest proof that ABDM compliance delivers measurable ROI is the product outcomes already live in the Indian market. Several of the following were built by Ailoitte’s healthtech practice.

EHR platform: iPatientCare

Ailoitte delivered a FHIR R4-aligned EHR platform for iPatientCare with role-based access control and real-time consent management. The platform reduced clinical documentation time by 40% within six months of deployment and now serves thousands of practitioners across India. Dr. Rahul Gupta, CMO of iPatientCare: “Ailoitte delivered a user-friendly, secure, and scalable EHR platform that improved our workflows and helped us deliver better care.”

Mental health platform: Mindfully

The Mindfully case study demonstrates how ABHA-linked records give therapists pre-session clinical context without requiring patients to manually share their history. The consent architecture, patient-controlled and scoped to the artefact level, protects sensitive psychological records from broader EHR access while satisfying ABDM consent requirements. ABHA integration reduced patient onboarding time from 12 minutes to under 3 minutes.

E-pharmacy: prescription verification benchmark

An e-pharmacy platform Ailoitte worked with reduced prescription verification time from 4 to 6 minutes per prescription to under 30 seconds after integrating the ABDM e-prescription standard. This cut manual verification labour costs by approximately 70% within six months of going live, while simultaneously eliminating prescription forgery risk through NHA-verified digital prescriptions. The integration was completed within 10 weeks using the HEALTH Framework H and A pillars.

Challenges When Building on ABDM and How to Solve Them

Consent state complexity

ABDM consent management has more edge cases than most teams anticipate at scoping. Each state change (grant, revoke, pause, expire) must propagate in real time across all HIPs that accessed data under that consent artefact. Build the consent event ledger as an append-only log indexed by consent artefact ID, with every HIP subscribed to revocation events for artefacts they have accessed. Treat consent as event-sourced, not as a status column. Every race condition in consent propagation surfaces during NHA sandbox review.

FHIR R4 data migration for legacy systems

Migrating to FHIR R4 requires clinical informatics expertise to map legacy schemas correctly. Numeric diagnosis codes, drug codes, and encounter types all require mapping to NHA’s India profile extensions. Ailoitte’s legacy modernisation service has pre-built mappings for Indian clinical data patterns including CGHS diagnostic codes, AYUSH prescription formats, and NHA encounter types, reducing FHIR R4 migration timelines by approximately 35% compared to mapping from scratch.

Regional language and accessibility requirements

ABDM’s population-wide mandate means your app must work for non-English-literate patients on entry-level devices in low-connectivity environments. WCAG 2.1 AA is the baseline, not the ceiling. Plan internationalisation at the schema level from sprint one. Ailoitte’s mobile development practice builds i18n-first architectures as a default for all Indian market products. Retrofitting i18n into an existing codebase is three to four times more expensive than building it in from sprint one.

Challenges When Building on ABDM and How to Solve Them

Consent state complexity

ABDM consent management has more edge cases than most teams anticipate at scoping. Each state change (grant, revoke, pause, expire) must propagate in real time across all HIPs that accessed data under that consent artefact. Build the consent event ledger as an append-only log indexed by consent artefact ID, with every HIP subscribed to revocation events for artefacts they have accessed. Treat consent as event-sourced, not as a status column. Every race condition in consent propagation surfaces during NHA sandbox review.

FHIR R4 data migration for legacy systems

Migrating to FHIR R4 requires clinical informatics expertise to map legacy schemas correctly. Numeric diagnosis codes, drug codes, and encounter types all require mapping to NHA’s India profile extensions. Ailoitte’s legacy modernisation service has pre-built mappings for Indian clinical data patterns including CGHS diagnostic codes, AYUSH prescription formats, and NHA encounter types, reducing FHIR R4 migration timelines by approximately 35% compared to mapping from scratch.

Regional language and accessibility requirements

ABDM’s population-wide mandate means your app must work for non-English-literate patients on entry-level devices in low-connectivity environments. WCAG 2.1 AA is the baseline, not the ceiling. Plan internationalisation at the schema level from sprint one. Ailoitte’s mobile development practice builds i18n-first architectures as a default for all Indian market products. Retrofitting i18n into an existing codebase is three to four times more expensive than building it in from sprint one.

Cost and Timeline: What to Budget for ABDM Integration

ABDM compliance cost and timeline depend on your starting point (greenfield or existing product), your app category, and how many ABDM API surfaces your service type requires. The following benchmarks are drawn from Ailoitte’s HEALTH Framework delivery data.

Timelines include sandbox testing and NHA onboarding submission but not the NHA review period (two to four weeks) or the 30-day live monitoring window. Teams starting ABDM-compliant from day one spend significantly less than those retrofitting compliance at Series A, where a full compliance audit and codebase migration typically adds three to six months to the delivery roadmap. For healthtech startups building at MVP stage, starting ABDM-first is the single highest-leverage architectural decision you will make.

Why ABDM Compliance Is a Competitive Moat, Not a Cost

ABDM-compliant apps gain access to infrastructure that would cost hundreds of crores and years to replicate independently: 900 million+ ABHA IDs, a national healthcare professionals registry, a national health facility registry, and the UHI network. Ailoitte’s AI Velocity Pods delivery model makes ABDM compliance an engineered output, not an open-ended integration project, with fixed-price delivery and defined acceptance criteria at every HEALTH Framework pillar.

The second moat is patient retention. Once a patient links their ABHA ID to your platform and stores records in your Health Locker implementation, the structural cost of switching to a non-compliant competitor rises significantly. A competitor without ABDM cannot offer to migrate those linked records. ABDM compliance, done correctly, is the most defensible retention mechanism in Indian healthtech.

The most valuable digital health products emerging in India in 2026, covering AI-powered clinical documentation, agentic diagnostic support, and AI-native care coordination, are all built on a compliant ABDM layer. Contact Ailoitte’s healthcare engineering team to identify which HEALTH pillars apply to your use case and get a delivery timeline scoped to your product.