Consent Framework

Nothing moves in ABDM without a consent artefact: a digitally signed document, issued by the patient's consent manager, describing exactly what data may be shared, with whom, for what purpose, and until when.

Anatomy of a consent artefact

{
  "consentDetail": {
    "consentId": "a1b2c3d4-...",
    "patient": { "id": "sunita.sharma@abdm" },
    "purpose": { "code": "CAREMGT", "text": "Care Management" },
    "hiu": { "id": "IN0510000456" },
    "hip": { "id": "IN0410000123" },
    "careContexts": [
      { "patientReference": "MRN-2024-0042", "careContextReference": "OPD-2025-01-15" }
    ],
    "hiTypes": ["Prescription", "DiagnosticReport", "DischargeSummary"],
    "permission": {
      "accessMode": "VIEW",
      "dateRange": { "from": "2024-01-01T00:00:00Z", "to": "2025-01-15T00:00:00Z" },
      "dataEraseAt": "2025-07-15T00:00:00Z",
      "frequency": { "unit": "HOUR", "value": 1, "repeats": 0 }
    }
  },
  "signature": "..."
}

Key fields:

• purpose — a coded reason (care management, break-the-glass, insurance claims, self-requested, etc.).
• hiTypes — the record categories covered (see below).
• permission.dateRange — the clinical period of records covered, not the validity of the consent.
• permission.dataEraseAt — when the HIU must delete fetched data.
• careContexts — the specific episodes covered. A grant may narrow the request to particular contexts.

Health information types

The standard hiTypes include:

OPConsultation · Prescription · DischargeSummary · DiagnosticReport · ImmunizationRecord · HealthDocumentRecord · WellnessRecord · Invoice (newer additions appear over time)

Lifecycle

stateDiagram-v2
  [*] --> REQUESTED: HIU initiates
  REQUESTED --> GRANTED: patient approves
  REQUESTED --> DENIED: patient rejects
  GRANTED --> EXPIRED: validity passes
  GRANTED --> REVOKED: patient revokes
  EXPIRED --> [*]
  DENIED --> [*]
  REVOKED --> [*]

1. Request — HIU calls consent-request init with purpose, hiTypes, date range, and requested expiry.
2. Notify — CM pushes the pending request to the patient's PHR app.
3. Grant / Deny — the patient reviews; on grant the CM issues one artefact per HIP covered and notifies each HIP.
4. Fetch — the HIU fetches granted artefacts and can then issue health information requests.
5. Expiry / Revocation — the CM notifies both sides; the HIU must stop using and erase the data per dataEraseAt.

Patient-initiated consents

Patients can also proactively share from their PHR app (self-initiated consent / subscription flows), and set auto-approval policies for trusted HIUs — your HIU should handle artefacts that arrive without a preceding request from your side.