ABDM Integration Status

1. What Is ABDM (Ayushman Bharat Digital Mission)

The Ayushman Bharat Digital Mission (ABDM), led by the National Health Authority (NHA), creates a unified digital health ecosystem for India. Key building blocks:

• ABHA (Ayushman Bharat Health Account): Unique 14-digit health ID for every citizen, enabling longitudinal health records across providers.
• HFR (Health Facility Registry): Verified registry of hospitals, clinics, diagnostic centers, and health facilities.
• HPR (Healthcare Professional Registry): Verified registry of doctors, nurses, paramedics, and allied health professionals.
• PHR (Personal Health Record): Citizen-controlled health record app (e.g., Aarogya Setu, ABHA app, third-party PHR apps) for consented access to records.
• Consent Manager: Framework for granular, auditable, revocable patient consent for health data sharing (per DPDP Act).
• UHI (Unified Health Interface): Open protocol for interoperable health service discovery, appointment booking, teleconsultation, and record exchange.

ABDM compliance requires integration with these registries, consent artefacts, and the UHI protocol. Formal onboarding involves NHA sandbox testing, security assessment, and certification.

2. What DocVerb Has That Aligns With ABDM Principles

While not ABDM-integrated, DocVerb's architecture reflects several ABDM-aligned principles:

• Data minimisation: DocVerb is designed with data minimisation principles. We do not build centralized patient identity databases. We process audio transiently to generate documentation, then delete the source.
• Encryption: Clinical documentation is protected using encryption at multiple layers (TLS 1.3 in transit, AES-256-GCM at rest, envelope encryption with cloud KMS).
• Consent-ready architecture: Our QR follow-up workflow uses signed, expiring URLs with HMAC-SHA256—no patient accounts, no stored patient PII, granular access control. This mirrors consent-manager patterns.
• Audit logs: Immutable, append-only audit logs (WORM storage) capture authentication, data access, export, deletion, admin actions, and AI generation events with timestamps, actors, correlation IDs. Retention: 2+ years.
• India-hosted infrastructure: Primary processing in AWS/GCP India regions (Mumbai/Bangalore). No cross-border transfer of clinical content by default.
• Role-based access control: Workspace-isolated, per-doctor cryptographic namespaces. No cross-patient linking. Row-level security at database layer.
• DPDP Act alignment: Processor-role architecture, 72-hour breach notification, Data Processing Agreements with subprocessors, grievance redressal.

3. UID Architecture — How DocVerb Handles Identity

DocVerb uses a unique UID architecture designed for privacy-first clinical documentation. This section describes the architecture honestly and how it could align with ABDM's federated identity model.

3.1 Core UID Principles

• Only SOAP notes and prescriptions are stored — no patient identifying information (name, phone, email, ABHA ID, government IDs) is ever persisted in DocVerb's database.
• First encounter: details shown once, never uploaded — During consultation, the doctor sees patient name/details on screen for context. This data exists only in the browser session and is never transmitted to or stored on DocVerb servers.
• UID is anonymous on the server — The UID generated for each patient encounter is a cryptographic token with no linkage to human identity. It cannot be reverse-engineered to reveal who the patient is.
• Identification only via external sharing — A patient can only be identified if the UID is explicitly shared from outside the system (e.g., doctor tells patient their UID, patient shares it with another provider). The UID itself carries no identity.
• Doctor ID + Patient ID matching required — Data is encrypted per doctor-patient pair. Without the correct Doctor ID and Patient ID combination, the encrypted SOAP/prescription data is mathematically inaccessible.
• Four-factor identification — The only way to access a specific encounter record is the combination of: Doctor ID + Patient ID + UID + Timestamp. All four must match. No subset is sufficient.

3.2 Alignment With ABDM's Federated Identity Model

ABDM's architecture is federated: identity (ABHA) lives with the citizen, facilities register in HFR, professionals in HPR, and consent flows through Consent Managers. No central identity database exists.

DocVerb's UID architecture shares this philosophy:

• No central patient registry — DocVerb does not maintain a patient master database. Each doctor's workspace is cryptographically isolated.
• Patient-held identity — Just as ABHA puts identity in the citizen's hands, DocVerb's UID puts encounter linkage in the doctor-patient relationship. The "link" exists only when both parties hold their respective IDs.
• Consent as capability — Our QR follow-up (signed, expiring URLs with HMAC) mirrors consent-manager patterns: access is granted via cryptographic capability, not identity lookup.
• Interoperability via export — DocVerb exports (JSON/PDF/CSV) can be imported into ABDM-compliant PHR/HIS systems. The UID can map to ABHA ID at the receiving system's discretion — DocVerb does not enforce or manage this mapping.

Key difference: ABDM uses ABHA as a universal citizen identifier across the ecosystem. DocVerb uses per-doctor-per-patient UIDs with no cross-doctor linkage. Future ABHA integration would allow doctors to optionally associate a UID with an ABHA ID at export time, preserving the current architecture for non-ABDM workflows.

4. Current Gaps (What We Do NOT Have)

The following ABDM integrations are not implemented:

• ❌ ABHA linking: No patient ABHA ID capture, verification, or linkage to consultations.
• ❌ HFR registration: Practices/facilities cannot register or verify against Health Facility Registry.
• ❌ HPR registration: Doctors cannot register or verify against Healthcare Professional Registry.
• ❌ UHI integration: No UHI protocol implementation for service discovery, appointment booking, or record exchange.
• ❌ Consent Manager integration: No integration with ABDM consent artefacts (consent request, grant, revoke, audit).
• ❌ NHA sandbox testing: No sandbox onboarding, no compliance testing, no certification application submitted.
• ❌ ABDM-compliant health record export: Exports are JSON/PDF/CSV but not FHIR R4/ABDM-standard bundles.
• ❌ Gateway/API integration: No connection to ABDM gateway APIs (ABHA, HFR, HPR, Consent, UHI).

5. Roadmap

We are actively building toward ABDM alignment. Timelines are targets, not guarantees:

Milestone	Target	Status
ABHA linking (patient ID capture, verification, longitudinal record association)	Q2 2026	Design phase
HFR/HPR registration workflows (facility & professional verification)	Q3 2026	Research
UHI protocol integration (service discovery, appointments, record exchange)	Q4 2026	Research
Consent Manager integration (ABDM consent artefacts, granular patient consent)	Q4 2026	Research
NHA sandbox onboarding & compliance testing	H1 2027	Not started
ABDM certification (if achieved)	TBD	Not started

Roadmap subject to NHA API stability, regulatory changes, and engineering capacity. No commitment to certification.

6. Guidance for Indian Doctors

7. What "ABDM-Ready" Means for DocVerb

When we say "ABDM-ready" (future state), we mean:

• Technical capability to integrate with ABHA, HFR, HPR, Consent Manager, and UHI APIs
• Consent artefact generation and verification
• Audit trails meeting NHA requirements
• Not: Automatic certification, guaranteed NHA approval, or mandatory integration

Integration will be opt-in. Doctors not participating in ABDM will see no workflow changes.

8. Related Policies

• Privacy Policy
• Terms of Service
• DPDP Compliance
• Security
• Data Retention
• Responsible AI Policy
• HIPAA Compliance
• Cookie Policy

9. Contact for ABDM Discussions

Questions about ABDM roadmap, integration partnerships, or regulatory alignment:

docverb.no.reply@gmail.com (Subject: ABDM)

We respond within 5 business days. No sales outreach—technical/regulatory discussions only.