ABDM integration status

Last updated: 16 September 2026

Current status: Doctor Online currently supports optional ABHA identifier capture with patient consent. M2 HIP and M3 HIU health-record workflows are not implemented, and ABDM exchange is not enabled on this public service.

What is currently available

Patients may leave the ABHA number or ABHA address blank and continue a consultation.
If a patient provides an ABHA identifier, it is stored only with explicit consent for the consultation record.
The patient form links to the official ABHA portal; this link does not itself create an ABDM API integration.
The consultation service provides online medical communication and prescription support where clinically appropriate.

What is not currently claimed

This website does not claim that it is ABDM-approved, does not claim that it is currently exchanging health records through ABDM APIs, and does not represent optional ABHA capture or a local draft FHIR package as an ABDM integration.

Integration boundary

Any future ABDM integration will be enabled only after role-specific M2/M3 workflows are implemented and tested, official onboarding and sandbox validation are complete, and configuration uses credentials issued by ABDM. Configuring credentials alone does not enable record exchange. Client secrets will not be exposed in the browser.

The machine-readable status endpoints now include a developer implementation blueprint mapping the M2 HIP and M3 HIU consent, care-context, and data-transfer workflows to example paths from the ABDM documentation reference. Its bundled API schemas are version 0.5 historical examples; ABDM must confirm the current assigned contract before network routes are implemented. The blueprint is not a live API integration.

Official M2 HIP and M3 HIU scope

The current M2 HIP documentation covers linking and discovery of care contexts, consent handling, FHIR health-record formats, packaging, encryption/decryption, and transfer. ABDM lists Diagnostic Report, Discharge Summary, Health Document, Immunization, OP Consult, Prescription, Wellness, and Invoice records; all listed health-information types are required. Before transfer, HIP must check that consent is valid and restrict records to the permitted types and date range; the M2 request guidance specifies a two-hour transfer window. Doctor Online does not currently implement that end-to-end HIP workflow or validate those record types against assigned NRCeS profiles.

The current M3 HIU documentation marks requesting consent, storing consent artefacts, getting health records, and displaying health records as mandatory test scenarios. Consent and data exchange are asynchronous: the HIU must handle consent callbacks, request records against granted consent, receive pushed data, and report receipt status. Doctor Online does not currently implement those HIU workflows.

Use the official M2 HIP and M3 HIU test-case mapping for the current role-specific test workbooks. Passing local checks is not a substitute for those sandbox tests.

Reviewer verification checklist

Public website: This page and the linked public information pages are accessible without a Windows login, VPN, or consultation token.
Professional information: The doctor profile identifies Dr. Avinash Mandre and displays the stated professional registration details.
Privacy and consent: The privacy page and consent terms explain consultation data, optional ABHA capture, consent, retention, and emergency limitations.
Data boundary: Optional ABHA capture is separate from ABDM record exchange. No ABDM record is claimed or represented as exchanged on this public service.
Credential safety: ABDM client secrets are server-side only and are never returned by the public status endpoints.
Sandbox configuration: /api/abdm/verification reports non-secret readiness fields for the reviewer.

Current compliance position

The public website is ready for website and organization review, but it is not yet ABDM API compliant or ABDM certified. Optional local ABHA capture is not ABDM verification, and the current service does not claim M1, M2, M3, M4, HIP, HIU, FHIR exchange, or production approval. The machine-readable status reports M2 HIP and M3 HIU as separate, not-implemented targets; credentials or an environment role setting do not count as onboarding, role assignment, sandbox readiness, or exchange capability. The complete technical gap report is maintained for the operator at C:\SERVER\ABDM_COMPLIANCE_GAP_REPORT.txt.

What must happen next

Register through the official ABDM sandbox registration route and confirm whether ABDM assigns HIP, HIU, or both roles to this service.
Obtain ABDM-issued sandbox credentials, the assigned role(s) and API version(s), callback requirements, test identifiers, and the current FHIR profile specifications.
Implement and securely test the complete role-specific M2 HIP and M3 HIU consent, care-context, FHIR, callback, and transfer workflows without placing credentials in browser code.
Complete the official M2 and M3 sandbox test cases, retain redacted evidence, and wait for ABDM validation before enabling record exchange.

The machine-readable /api/abdm/verification endpoint lists the separate M2 HIP and M3 HIU requirements and remaining gates. Legal organization information, official role assignment, credentials, documents, and certification must be supplied or completed by the authorized applicant and ABDM; they cannot be safely invented by this website.

The application can prepare a doctor-authenticated prescription as a draft FHIR R4 document bundle at /api/abdm/m2/prescriptions/<recordId>/fhir and perform local structural checks at /api/abdm/m2/prescriptions/<recordId>/fhir/validate. The draft includes bundle-local references and requires the assigned HIP/facility ID and name for its organization resource. These endpoints are not live ABDM APIs, do not transmit patient data, and do not establish ABDM/NRCeS profile conformance; profile and API validation remain outstanding until the official M2 role and specification are confirmed.

Planned sandbox data flow

After ABDM issues credentials and confirms the role and APIs, the intended flow will be: patient consent in the Doctor Online interface → server-side ABDM authorization and API request → ABDM sandbox response → application audit/status update → patient/doctor display of the permitted result. The exact APIs, FHIR resources, callback URLs, and consent-revocation behavior will be documented from the official ABDM specification before enabling record exchange.

Verification and support

Public service information is available on the doctor profile, privacy page, consent terms, and contact page. For official ABDM onboarding and sandbox requirements, use the current ABDM Sandbox registration page and the official sandbox documentation.

Join a patient consultation · Technical support