Does Complyo Clinic directly connect to the NHA ABDM Gateway?

No. Complyo Clinic provides an informational preparation walkthrough, API documentation, and sandbox test guides. It does not submit live clinical records, collect Aadhaar data, or issue official government certifications.

What is the difference between HIP and HIU in ABDM?

A Health Information Provider (HIP) shares patient health records into the ABDM network upon receiving verified patient consent. A Health Information User (HIU) requests and receives health records from other network providers with patient consent.

Clinic Compliance & ABDM Readiness Guide

Navigate ABDM readiness for your clinic.

Q: What does ABDM integration mean for a clinic?

ABDM integration means connecting a clinic's software systems to the Ayushman Bharat Digital Mission network. This enables patient ABHA identity verification, linking facility records via HFR/HPR, and sharing standardized FHIR R4 medical records with patient consent through the ABDM Gateway.

Clinics planning to participate in India's digital health ecosystem need to understand the relevant registries, integration milestones, consent requirements, and technical readiness. Applicable requirements depend on your facility, state, and intended ABDM workflows.

Direct Answer & Core Fact

What is Complyo Clinic?

Complyo Clinic is an informational ABDM readiness platform that guides Indian healthcare clinics through Ayushman Bharat Digital Mission compliance. It provides structured roadmaps for Health Facility Registry (HFR) setup, Healthcare Professional Registry (HPR) verification, DPDP Act 2023 patient consent protocols, and HL7 FHIR R4 clinical data exchange with National Health Authority sandbox APIs.

State-specific requirements

Clinical Establishments Act (CEA)

Where the CEA or a corresponding state law applies, facilities may need registration. Confirm current requirements with the relevant state authority.

Check applicable rules: Requirements and consequences depend on state law and facility type.
Align facility records: Keep official facility and registration details accurate and up to date.

NHA Ecosystem

ABDM, IRDAI & NHCX Integration

ABDM participation and eligibility for related services depend on facility enrolment, the selected workflows, and the applicable program criteria.

Check eligibility: Confirm current HFR, NHCX, and insurer criteria with the relevant program.
Incentive schemes: Eligibility and rates depend on current scheme rules and verified transactions.

Patient Data

DPDP Act 2023 & ABHA Standards

Use clear notices, the consent steps required for each workflow, and safeguards appropriate to the personal data being handled.

Minimize sensitive data: Use authorized flows and avoid retaining Aadhaar data beyond what is permitted.
Respect consent: Follow the applicable notice and consent steps for the requested workflow.

ABDM interoperability

FHIR R4 & Record Exchange

Depending on the intended workflows, integration may involve FHIR data, a HIP for sharing records, and an HIU for requesting records with consent.

Map clinical data: Confirm applicable FHIR profiles and terminology requirements for your workflow.
Test before go-live: Use current sandbox test cases and applicable production approvals.

A practical path to ABDM integration

The clinic registry and practitioner steps in the walkthrough are only part of an integration. A real implementation also needs a technical plan, testing, and production readiness.

Assess readiness

Review your clinic's software, existing HFR/HPR status, available APIs, data flows, and the workflows you want to support.

Choose an approach

Assess a pre-built connector against your system and support needs, or scope custom integration and data mapping with your software provider.

Prepare the sandbox

Arrange the applicable NHA sandbox onboarding, credentials, service/provider configuration, and secure HTTPS callback handling.

Build and test

Implement only the required ABHA, HIP/HIU, consent, and FHIR workflows; run the current applicable test cases and resolve failures.

Plan production

Complete applicable approvals and production setup, then plan monitoring, security ownership, incident response, and ongoing support.

Connector vs integration services: A connector is a pre-built integration product; custom integration is project work tailored to a particular system and workflow. They may be offered by the same provider, but they are different delivery models—not separate ABDM milestones. Requirements and sequence can vary; confirm them against current NHA guidance and your software provider.

ABDM questions clinics often ask

Plain-language answers to help scope a clinic's next steps. This information is general guidance, not legal advice or an assurance of NHA approval.

What does ABDM integration mean for a clinic?

It means connecting the clinic's software and workflows to relevant parts of the Ayushman Bharat Digital Mission ecosystem. Depending on scope, this may involve ABHA identity workflows, HFR/HPR records, HIP/HIU exchange, patient consent, and FHIR data through the ABDM gateway.

Is this walkthrough connected to ABDM or the NHA sandbox?

No. This page is an informational, front-end walkthrough. It does not contact ABDM, submit HFR/HPR applications, store form entries, run gateway tests, create a production connection, or issue an official certificate. Any sample results shown in the demo are illustrative only.

What should I prepare before starting an integration?

Identify your clinic software and vendor, the workflows you need, your current HFR/HPR status, and whether the system provides supported APIs. Your implementation team may also need sandbox onboarding, credentials, service configuration, a secure callback endpoint, consent and privacy procedures, and test data. Never share production secrets in this page or with unauthorized parties.

Should we use a connector or custom ABDM integration?

A connector offers pre-built capabilities that may reduce custom development when your existing system is supported. Custom integration is tailored to your software, data mapping, and workflows. Compare compatibility, milestone coverage, security responsibilities, support, ownership, and total cost. Complyo Clinic does not sell either option or quote vendor pricing.

What do M1, M2, and M3 mean?

In commonly used integration shorthand, M1 refers to ABHA creation or verification workflows; M2 to HIP workflows for linking and sharing records with consent; and M3 to HIU workflows for requesting and receiving records with consent. Your actual scope and test requirements depend on the current NHA program and should be confirmed before implementation.

What is the difference between HIP and HIU?

A Health Information Provider (HIP) makes a patient's digital health records available for sharing through applicable ABDM workflows and patient consent. A Health Information User (HIU) requests and receives records through the applicable consent and exchange process. A clinic may need one role, both roles, or neither, depending on its use case.

How long does integration take, and what does it cost?

There is no single timeline or price for every clinic. It depends on existing software and APIs, required workflows, vendor readiness, onboarding, testing, approvals, deployment, and support. Ask providers for a scoped quote and milestones; this guide does not promise a delivery time or price.

Is ABDM participation mandatory for every clinic?

Do not assume one rule applies to every clinic. ABDM participation, state clinical-establishment registration, and obligations under a specific government or payer program are distinct questions. Check current NHA guidance, applicable state rules, and the terms of any program your clinic joins.

How should a clinic handle patient consent and health information?

Explain the purpose and workflow to patients, obtain and record consent as required for the specific ABDM transaction, and follow the applicable privacy and security requirements. Limit data collection and access, protect credentials, and do not retain Aadhaar data unless an authorized workflow and applicable rules explicitly permit it.

Readiness Step 1

Clinic Profile & Software Readiness

Collect the facility and system details your implementation team will need. Requirements depend on your clinic and intended workflows.

Clinic Commercial Name

System of Medicine *

Clinic address

State / UT

District / PIN Code

Type of Establishment

Current clinic software

Integration approach to assess

Target workflow scope

Readiness Step 2

Health Facility Registry (HFR) Readiness

Review whether your facility details and applicable registrations are ready to be checked through the current official HFR process.

Facility / HFR ID (if already issued)

Applicable state registration details

Facility evidence to review

Review facility records and any evidence requested by the official process

This demo does not upload or store files

External checks to completeNOT CHECKED HERE

Facility entry

Verify in official HFR

Application status

Check through official process

ABDM sandbox

Not connected to this demo

Readiness Step 3

Healthcare Professional Registry (HPR)

Review practitioner registration details and confirm any HPR requirements through current official guidance. This page cannot search or bind a practitioner.

Practitioner name

Registration details to verify

Registering Medical Council *

HPR ID (if already issued)

Illustrative Demo No gateway connection

Example ABHA, consent & FHIR workflow

Explore the kinds of steps an implementation may include. The animation below is local only; it does not authenticate a patient, create an ABHA, validate a FHIR bundle, or contact the ABDM gateway.

Patient identity & consent

A real implementation should explain the intended workflow, obtain and record the consent required for that transaction, use an authorized ABHA flow, and handle identity data according to applicable requirements. Do not enter real patient or Aadhaar information in this demo.

Example clinical data (optional)

Example diagnosis text

Example medicine text

> Local demo only — no API requests are sent.

> Example flow: identity → consent → care context

> Example flow: prepare FHIR data → test in sandbox

> Use official onboarding and credentials for real tests.

Illustrative preview only

Not verified

No transaction ID or patient record was created.
No endpoint was called and no incentive was calculated.

Digital Health Incentive Scheme

Eligibility and amounts depend on current scheme rules and verified transactions.

—

Readiness summary — not a certificate

This walkthrough has not checked official records or completed an ABDM test. Use this list to plan the real work with your clinic software provider and the relevant official services.

Clinic software and APIsReview with software provider

HFR facility detailsVerify through official HFR service

Practitioner / HPR detailsVerify through official HPR service

Integration approach and scopeAgree connector or custom approach

Sandbox tests and approvalsNot performed by this demo

Production setup and supportPlan with your implementation team

ABDM API Reference

All endpoints sourced from the official NHA-ABDM/ABDM-wrapper GitHub repository and the ABDM Community sandbox documentation. Use the ABDM Sandbox environment (X-CM-ID: sbx) during development; switch to abdm for production.

Gateway Base URLhttps://dev.abdm.gov.in/gateway

ABHA / Health ID Basehttps://healthidsbx.abdm.gov.in/api

Dev Services Basehttps://dev.abdm.gov.in/devservice

Sandbox CM IDsbx

Source Repositorygithub.com/NHA-ABDM/ABDM-wrapper

API Spec (Swagger)sandbox.abdm.gov.in/swagger/

1 — Gateway Authentication

POST /v0.5/sessions Get access token (v0.5)

Host: https://dev.abdm.gov.in/gateway · Auth: None (credentials in body) · Headers: Content-Type: application/json

Request Body

// clientId and clientSecret issued after sandbox approval
{
  "clientId": "YOUR_CLIENT_ID",
  "clientSecret": "YOUR_CLIENT_SECRET",
  "grantType": "client_credentials"
}

Response (200)

{
  "accessToken": "eyJhbGci...",
  "tokenType": "bearer",
  "expiresIn": 1800
}

NHA-ABDM/ABDM-wrapper README

POST /api/hiecm/gateway/v3/sessions Get access token (v3)

Host: https://dev.abdm.gov.in · Required Headers: REQUEST-ID, TIMESTAMP, X-CM-ID: sbx

Request Body

{
  "clientId": "YOUR_CLIENT_ID",
  "clientSecret": "YOUR_CLIENT_SECRET",
  "grantType": "client_credentials"
}

Notes

// v3 is the latest (2024). Use v0.5 for
// legacy HIP/HIU flows. TIMESTAMP format:
// ISO-8601: 2026-10-15T08:57:00.000Z
// REQUEST-ID: any UUID v4

NHA-ABDM/ABDM-wrapper README (v3 section)

2 — Bridge & HIP Registration

PATCH /devservice/v1/bridges Register callback URL

Host: https://dev.abdm.gov.in · Auth: Bearer <accessToken> · Sandbox only (set via HFR in production)

Request Body

{
  "url": "https://your-clinic-emr.in"
}

Purpose

// Registers the callback URL for async responses
// from the ABDM Gateway. One Client ID = one URL.
// Gateway will POST callbacks here for all
// discovery, linking, consent and data flows.

ABDM Community Docs — Working with APIs

PUT /devservice/v1/bridges/addUpdateServices Register HIP / HIU ID

Host: https://dev.abdm.gov.in · Auth: Bearer <accessToken>

Request Body

[{
  "id": "YOUR_HIP_ID",
  "name": "DEMO_CLINIC_NAME",
  "type": "HIP",
  "active": true,
  "alias": ["YOUR_HIP_ID"]
}]

Response (200)

// HTTP 200 = accepted
// Check via GET /v1/bridges/getServices
// type: "HIP" | "HIU" | "HRP"

NHA-ABDM/ABDM-wrapper README

GET /api/hiecm/gateway/v3/bridge-services Check bridge config & facilities

Host: https://dev.abdm.gov.in · Auth: Bearer · Headers: REQUEST-ID, TIMESTAMP, X-CM-ID: sbx

Response

{
  "bridge": {
    "id": "YOUR_BRIDGE_ID",
    "url": "https://your-clinic-emr.in"
  },
  "services": [{
    "id": "YOUR_HIP_ID",
    "type": "HIP",
    "active": true
  }]
}

Use case

// Verify your callback URL and HIP/HIU IDs
// are correctly registered before testing
// async discovery and consent flows.

NHA-ABDM/ABDM-wrapper README (v3)

3 — ABHA Number & Health ID (Milestone 1)

POST /v1/registration/aadhaar/generateOtp Generate Aadhaar OTP

Host: https://healthidsbx.abdm.gov.in/api · Auth: Bearer · DPDP: Consent checkbox must be checked before calling

Request Body

{
  "aadhaar": "<RSA-encrypted 12-digit number>"
  // Encrypt with NHA public key before sending
  // NEVER send plain Aadhaar. See RSA encryption docs.
}

Response (200)

{
  "txnId": "a825f76b-0696-40f3-864c-5a3a5b389a83",
  "mobileNumber": "******9201"
  // OTP sent to Aadhaar-linked mobile
}

ABDM Docs — ABHA via Aadhaar OTP

POST /v1/registration/aadhaar/verifyOTP Verify Aadhaar OTP

Host: https://healthidsbx.abdm.gov.in/api · Auth: Bearer

Request Body

{
  "otp": "<RSA-encrypted 6-digit OTP>",
  "txnId": "a825f76b-0696-40f3-..."
}

Response (200)

{
  "txnId": "a825f76b-...",
  "userToken": "...",
  "healthIdNumber": "YOUR_ABHA_NUMBER",
  "healthId": "YOUR_ABHA_ADDRESS"
}

ABDM Docs — ABHA via Aadhaar OTP

POST /v2/registration/aadhaar/checkAndGenerateMobileOTP Mobile OTP (if mobile ≠ Aadhaar)

Host: https://healthidsbx.abdm.gov.in/api · Auth: Bearer · Required when patient's mobile differs from Aadhaar-linked mobile

Request Body

{
  "mobile": "TEST_MOBILE_NUMBER",
  "txnId": "a825f76b-..."
}

Response (200)

{
  "txnId": "a825f76b-...",
  "mobileLinked": false
  // OTP sent to provided mobile number
}

ABDM Dev Forum — ABHA API sequence

POST /v2/registration/aadhaar/createHealthIdByAdhaar Create ABHA number

Host: https://healthidsbx.abdm.gov.in/api · Auth: Bearer · Prerequisite: OTP verified in same txnId

Request Body

{
  "txnId": "a825f76b-...",
  "consent": {
    "code": "abha-enrollment",
    "version": "1.4"
  }
}

Response (200)

{
  "healthIdNumber": "YOUR_ABHA_NUMBER",
  "healthId": "patient.demo@abdm",
  "token": "...",
  "name": "DEMO_PATIENT_NAME"
}

ABDM Swagger — ABHA Number V1/V2

4 — Healthcare Professional Registry (HPR)

POST /v1/hpr/search-by-registration Verify practitioner by council reg.

Host: https://dev.abdm.gov.in/gateway · Auth: Bearer · X-HIP-ID required

Request Body

{
  "stateCode": "MH",
  "councilName": "MMC",
  "registrationNumber": "YOUR_REGISTRATION_NUMBER",
  "name": "DEMO_PRACTITIONER_NAME"
}

Response (200)

{
  "hprId": "YOUR_HPR_ID",
  "name": "DEMO_PRACTITIONER_NAME",
  "qualification": "MBBS",
  "registrationNumber": "YOUR_REGISTRATION_NUMBER"
}

ABDM Docs — Health Professional Registry

5 — HIP Care Context Linking (Milestone 2)

POST /v0.5/links/link/add-contexts HIP-initiated care context link

Host: https://dev.abdm.gov.in/gateway · Auth: Bearer · Headers: X-HIP-ID, X-CM-ID: sbx

Request Body

{
  "requestId": "<UUID>",
  "timestamp": "2026-10-15T08:57:00.000Z",
  "link": {
    "accessToken": "<ABHA link token>",
    "patient": {
      "referenceNumber": "PAT-20261015",
      "display": "Rajesh Kumar OPD 15-Oct-2026",
      "careContexts": [{
        "referenceNumber": "CC-RX-20261015-001",
        "display": "OPD Prescription 15-Oct-2026"
      }]
    }
  }
}

Async Callback (on-add-contexts)

// Gateway calls back to your registered URL:
// POST /v0.5/links/link/on-add-contexts
{
  "acknowledgement": {
    "status": "SUCCESS"
  }
}

ABDM Docs — HIP Initiated Linking

POST /v0.5/care-contexts/discover Gateway-initiated patient discovery (callback)

Incoming callback at your registered URL · Headers: X-HIP-ID

Payload received

{
  "patient": {
    "id": "YOUR_ABHA_ADDRESS",
    "verifiedIdentifiers": [{
      "type": "MOBILE",
      "value": "TEST_MOBILE_NUMBER"
    }]
  }
}

Your response back

// POST /v0.5/care-contexts/on-discover back to gateway
{
  "patient": {
    "referenceNumber": "PAT-20261015",
    "display": "Rajesh Kumar",
    "careContexts": [...]
  }
}

ABDM Docs — Discovery & Link

6 — Consent Management (Milestone 2 / 3)

POST /v0.5/consent-requests/init Initiate consent request

Host: https://dev.abdm.gov.in/gateway · Auth: Bearer · X-CM-ID: sbx

Request Body

{
  "requestId": "<UUID>",
  "timestamp": "2026-10-15T08:57:00.000Z",
  "consent": {
    "purpose": { "code": "CAREMGT" },
    "patient": { "id": "YOUR_ABHA_ADDRESS" },
    "hiu": { "id": "YOUR_HIU_ID" },
    "hiTypes": ["OPConsultation", "Prescription"],
    "permission": {
      "accessMode": "VIEW",
      "dateRange": {
        "from": "2026-01-01T00:00:00Z",
        "to": "2026-12-31T23:59:59Z"
      },
      "dataEraseAt": "2027-10-15T00:00:00Z",
      "frequency": { "unit": "HOUR", "value": 1, "repeats": 0 }
    }
  }
}

Async callback

// Gateway posts to your callback URL:
// POST /v0.5/consent-requests/on-init
{
  "consentRequest": { "id": "<consent-request-id>" }
}

ABDM Docs — Understanding Consents

7 — Health Information Transfer (FHIR R4)

POST /v0.5/health-information/notify Notify data transfer (HIP → Gateway)

Host: https://dev.abdm.gov.in/gateway · Auth: Bearer · X-HIP-ID, X-CM-ID: sbx

Request Body

{
  "requestId": "<UUID>",
  "timestamp": "2026-10-15T08:57:00.000Z",
  "notification": {
    "consentId": "<from consent artefact>",
    "transactionId": "YOUR_TRANSACTION_ID",
    "doneAt": "2026-10-15T08:57:00.000Z",
    "statusNotification": {
      "sessionStatus": "TRANSFERRED",
      "hipId": "YOUR_HIP_ID"
    }
  }
}

Encrypted FHIR payload

// Actual data goes via POST /v0.5/health-information/transfer
// Payload: AES-256-GCM encrypted FHIR R4 Bundle
// Key: ECDH-derived shared secret (Fidelius CLI)
// Profile: nrces.in/ndhm/fhir/r4/StructureDefinition/DocumentBundle

ABDM Docs — Transferring Health Data

POST /v0.5/health-information/transfer Push encrypted FHIR bundle to HIU

Host: https://dev.abdm.gov.in/gateway · Auth: Bearer · Encrypt payload with Fidelius CLI before sending

Request Body

{
  "pageNumber": 1,
  "pageCount": 1,
  "transactionId": "YOUR_TRANSACTION_ID",
  "entries": [{
    "content": "<base64 AES-GCM encrypted FHIR bundle>",
    "media": "application/fhir+json",
    "checksum": "<SHA-256 of plaintext>",
    "careContextReference": "CC-RX-20261015-001"
  }],
  "keyMaterial": {
    "cryptoAlg": "ECDH",
    "curve": "Curve25519",
    "dhPublicKey": { ... },
    "nonce": "<12-byte nonce>"
  }
}

Encryption stack

// 1. Generate Curve25519 key pair (HIP)
// 2. Get HIU public key from consent artefact
// 3. ECDH → shared secret
// 4. AES-256-GCM encrypt FHIR bundle
// 5. Base64-encode ciphertext
// Tool: Fidelius CLI (NHA open source)
// Repo: github.com/ProjectOpenH2/Fidelius

ABDM Docs — Encryption & Decryption

8 — Health Facility Registry (HFR)

GET /v1.0/facilities/{facilityId} Check HFR facility status

Host: https://dev.abdm.gov.in/gateway · Auth: Bearer · Replace {facilityId} with your HFR ID

Response (200)

{
  "facilityId": "YOUR_HFR_ID",
  "facilityName": "DEMO_CLINIC_NAME",
  "status": "PENDING_DVO_VERIFICATION",
  "state": "MH",
  "systemOfMedicine": "Modern Medicine"
}

Status values

"PENDING_DVO_VERIFICATION" // after submission
"PROVISIONAL"          // DVO acknowledged
"VERIFIED"             // fully approved
"REJECTED"             // doc mismatch

ABDM Docs — Health Facility Registry

9 — Scan & Share (V3 Link Token)

POST /api/v3/link/carecontext/send-otp V3 scan & share — send OTP

Host: https://dev.abdm.gov.in · Auth: Bearer · Replaces the v0.5 scan & share flow for new integrations

Request Body

{
  "abhaAddress": "YOUR_ABHA_ADDRESS",
  "hipId": "YOUR_HIP_ID",
  "requestId": "<UUID>",
  "timestamp": "2026-10-15T08:57:00.000Z"
}

Follow-up

// After patient enters OTP on ABHA app:
// POST /api/v3/link/carecontext/validate-token
// Then add care context via /v0.5/links/link/add-contexts

ABDM Swagger — V3 Link Token APIs

Send feedback / Contact us

Questions, suggestions, or feedback about Complyo Clinic are welcome. Use the form to prepare an email to our inbox.

How this form works: it opens your device’s email app with the message addressed to justmailsameer@gmail.com. Review and send it from your email app; this website does not submit or store the message.

Navigate ABDM readiness for your clinic.

What is Complyo Clinic?

Clinical Establishments Act (CEA)

ABDM, IRDAI & NHCX Integration

DPDP Act 2023 & ABHA Standards

FHIR R4 & Record Exchange

Understand your clinic's ABDM readiness.

A practical path to ABDM integration

Assess readiness

Choose an approach

Prepare the sandbox

Build and test

Plan production

ABDM questions clinics often ask

Informational walkthrough — not a live application

Clinic Profile & Software Readiness

Health Facility Registry (HFR) Readiness

Check the official HFR process

Healthcare Professional Registry (HPR)

Verification happens outside this walkthrough

Plan practitioner attribution

Example ABHA, consent & FHIR workflow

Readiness summary — not a certificate

ABDM API Reference

Request Body

Response (200)

Request Body

Notes

Request Body

Purpose

Request Body

Response (200)

Response

Use case

Request Body

Response (200)

Request Body

Response (200)

Request Body

Response (200)

Request Body

Response (200)

Request Body

Response (200)

Request Body

Async Callback (on-add-contexts)

Payload received

Your response back

Request Body

Async callback

Request Body

Encrypted FHIR payload

Request Body

Encryption stack

Response (200)

Status values

Request Body

Follow-up

Send feedback / Contact us