Glossary

The Ayushman Bharat Digital Mission is the programme under which India builds shared digital health infrastructure. It was launched nationally in 2021 and is implemented by the National Health Authority.

ABDM is infrastructure rather than an application. It defines the identity layer (ABHA), the registries of facilities and practitioners (HFR and HPR), and the consent and routing layer (HIE-CM) that lets records move between organisations. Participation is voluntary for individuals and for facilities.

The Ayushman Bharat Health Account is the identity layer of ABDM. It gives a person a single reference that participating facilities can use to link records that would otherwise sit in separate systems.

A person can hold an ABHA number and, separately, an ABHA address, which is the handle used when sharing records. Creating one is voluntary, and a person can deactivate or delete it. An ABHA number is not a medical record and holds no clinical data by itself.

An ABHA address is the handle a person uses when records are requested or shared. It takes the form username@consent-manager, for example meera@abdm.

The distinction from the ABHA number matters in practice. The number identifies the person; the address is the routing handle used by the consent manager. A person can hold more than one ABHA address, and an address can exist with or without a linked ABHA number.

A Health Locker is an ABDM service that a person may authorise to hold copies of records on their behalf. It differs from a plain PHR application in that it can retain records rather than only display them at the moment of a consented fetch.

Use of a locker is the person’s choice, and the authorisation can be withdrawn.

A Personal Health Record application is the interface through which a person manages their own records under ABDM. It is where consent requests arrive and where a person links care contexts from facilities they have visited.

A PHR app is a view onto records, not a store of them. Under ABDM’s federated design the records remain with the health information provider that created them, and are fetched when consent is granted.

The ABDM Sandbox is where integration actually happens. Developers register an application, work against the published APIs with test data, and complete the milestone demonstrations that gate access to production.

Sandbox completion is the practical meaning of “ABDM integrated” for a software vendor, and it is the step most often underestimated in project plans.

ABDM integration is certified in stages rather than all at once. Each milestone requires a working demonstration of a defined set of capabilities against the sandbox, and passing one unlocks the next.

Broadly, the earlier milestones cover identity and verification, and the later ones cover linking care contexts and fulfilling consented requests for records. Specifications change, so the current milestone definitions should be read from the NHA sandbox documentation rather than assumed.

The Centre for Development of Advanced Computing is India’s premier public research and development organisation for computing, working under the Ministry of Electronics and Information Technology.

It appears in digital health because public infrastructure is frequently built and operated by such bodies rather than procured as a product, which shapes how specifications evolve and how support works in practice.

The Digital Health Incentive Scheme offers financial incentives for qualifying ABDM transactions, aimed at moving facilities from registration to actual use.

Eligibility depends on HFR registration and on transactions being recorded through certified software. Scheme terms and rates are revised periodically, so current figures should be taken from NHA rather than from secondary coverage.

Fidelius is ABDM’s approach to end-to-end encryption of health data in transit. Records are encrypted by the sending participant and decrypted only by the intended recipient, which means the routing layer carries data it cannot read.

This is what allows a federated exchange to move sensitive records across shared infrastructure without the infrastructure operator having access to their contents.

The Health Facility Registry is the authoritative list of health facilities in India under ABDM. It covers hospitals, clinics, diagnostic laboratories and pharmacies, across both the public and private sectors.

A facility that completes registration receives an HFR ID. That identifier is what other participants rely on to answer a single question before any data moves: is this facility a verified participant in the ecosystem. HFR registration is therefore a prerequisite for acting as a health information provider, and it is referenced by schemes that pay incentives for digital transactions.

HFR answers “which facility”, while HPR answers “which practitioner”. The two are separate registries, and a facility needs both kinds of records in place for a complete ABDM footprint.

The Health Information Exchange and Consent Manager is the layer that makes consent operational. It delivers a request to the person’s PHR application, records the decision, and issues the consent artefact that lets a health information provider release records to a health information user.

The HIE-CM does not hold records. This is a deliberate design choice, and it is what keeps ABDM federated rather than a central repository.

Note the naming collision. “Consent Manager” in an ABDM context means this technical role. Under the Digital Personal Data Protection Act 2023 the same phrase means a different, statutory entity. See the separate entry for Consent Manager (DPDP).

A Health Information Provider is the participant that holds records and responds to a consented request for them. Hospitals, diagnostic laboratories and clinics act as HIPs.

HIP is a role rather than a category of organisation. The same hospital is a HIP when it shares a discharge summary it created, and a HIU when it requests a record held elsewhere.

A Health Information User is the participant that asks for records. A hospital treating a person for the first time, or an insurer assessing a claim, acts as a HIU when it requests records held by someone else.

As with HIP, this is a role rather than a fixed identity, and an organisation commonly acts as both depending on the direction of the request.

The Health Professional Registry is the verified list of practitioners participating in India’s digital health ecosystem. It spans modern medicine and the traditional systems, and links a practitioner to their registration with the relevant council.

Where HFR establishes that a facility is authorised to participate, HPR establishes that the professional who generated a record is credentialled. Both checks happen before record exchange, which is why the two registries are usually discussed together and are frequently confused with each other.

The National Accreditation Board for Hospitals and Healthcare Providers accredits hospitals and healthcare organisations against defined quality and patient safety standards.

Its commercial significance is in empanelment. Payers and public schemes frequently tier hospitals by accreditation status, so it influences both which networks a hospital can join and the rates it is offered within them.

The National Accreditation Board for Testing and Calibration Laboratories accredits laboratories against international competence standards.

For health data this matters at the point where results are trusted across organisations. A result shared under ABDM carries more weight when the originating laboratory’s competence is independently accredited.

The National Health Authority is the agency responsible for India’s flagship digital health and public insurance programmes. It implements the Ayushman Bharat Digital Mission and administers Ayushman Bharat Pradhan Mantri Jan Arogya Yojana.

For anyone building on these rails, NHA is the source of the specifications, the sandbox environment, the certification milestones and the incentive schemes.

The National Health Resource Repository was an effort to enumerate India’s health facilities and their capacity, conducted before ABDM’s registries existed.

Its relevance now is practical rather than architectural. A facility already present in NHRR has records that can support HFR registration, so the two are worth checking together rather than starting from nothing.

The National Medical Commission regulates medical education and the practice of modern medicine in India, and maintains the register of qualified practitioners. It replaced the Medical Council of India in 2020.

For digital health, its relevance is verification. HPR establishes that a professional is credentialled, and that claim ultimately rests on council registration rather than on self-declaration.

Scan and Share replaces manual entry at the outpatient registration counter. The facility displays a QR code, the person scans it in their PHR application and shares their ABHA profile, and the registration token is generated from that.

It is the most visible consumer-facing ABDM service, and the one most people encounter before they encounter anything else in the mission.

The Unified Health Interface applies an open-network model to health services. It is intended to let a person use any participating application to find and book services offered by any participating provider.

UHI addresses service discovery and booking. It is distinct from the consent and record-exchange layer, and the two are often conflated.

A Web Application Security Audit is conducted by an auditor empanelled with CERT-In and results in a certificate that ABDM requires before production access is granted.

It is a scheduling risk more than a technical one. Auditor availability, remediation rounds and re-testing all take calendar time that sits outside the development team’s control, and it cannot be started at the end.

A care context represents one episode of care at one facility, for example an outpatient consultation, an admission, or a diagnostic report.

Records become discoverable only once the corresponding care context is linked to the person’s ABHA address. A person can have many care contexts across many facilities, and unlinked records remain invisible to the exchange even though the facility still holds them.

Federated architecture describes how ABDM is put together. The mission provides the identity layer, the registries and the consent and routing layer, but it does not operate a central database of health records.

When a record is needed, the request is routed to the health information provider that holds it, and the record travels to the requesting participant once a valid consent artefact exists. The practical consequences are that there is no single store to breach, and that availability depends on the source facility’s systems being reachable.

Record linking is the act of associating existing records with an ABHA address, usually at registration or discharge. Until it happens, the records exist but are not reachable through ABDM.

This is a common reason a person finds their PHR application empty after a hospital visit. The care was delivered and the record exists, but the linking step was not completed.

Ayushman Bharat Pradhan Mantri Jan Arogya Yojana provides cover for secondary and tertiary hospitalisation to eligible families, delivered through empanelled public and private hospitals on defined package rates.

It is administered by the National Health Authority, the same body that implements ABDM, which is why the scheme and the digital infrastructure are frequently discussed together.

The Central Government Health Scheme covers serving and retired central government employees and their dependants.

It matters beyond its own membership because CGHS publishes rate schedules that are widely referenced as a benchmark when other schemes and payers set package rates.

Inpatient care involves formal admission. It is the basis on which most Indian health insurance cover is constructed, and the trigger for pre-authorization and cashless arrangements.

Because cover follows admission, the line between an extended day procedure and a short admission carries real financial consequences, and is a recurring source of queries at adjudication.

The Insurance Regulatory and Development Authority of India regulates insurers and intermediaries, including third party administrators.

For claims work, IRDAI is the source of the rules on policy wording, claim handling obligations and settlement timelines. Where a question concerns what a payer is required to do, IRDAI regulation rather than NHCX specification is the relevant authority.

The National Health Claims Exchange is the claims-routing layer of India’s digital health infrastructure. Its purpose is to replace a fragmented set of portals, email threads and proprietary formats with one standardised exchange that every participant can connect to once.

NHCX carries messages: coverage eligibility checks, pre-authorization requests, claim submissions, status queries and responses. It does not adjudicate. The decision on any claim stays with the payer, and the clinical and contractual terms are unchanged by the exchange.

The practical benefit is one integration instead of many, and a consistent format for what was previously bespoke per payer.

Outpatient care is delivered without admission. It covers consultations, diagnostics, day procedures and follow-ups.

The distinction matters for two reasons. In insurance, cover is commonly written around hospitalisation, so outpatient costs frequently fall outside the policy or sit under a separate limit. In ABDM, the outpatient registration counter is where most people first encounter the system, through Scan and Share.

A Third Party Administrator is licensed to administer claims for one or more insurers. TPAs typically operate the pre-authorization desk, process claim documents and coordinate with hospital insurance desks.

The TPA does not carry the risk. The policy sits with the insurer, and the TPA acts within the mandate the insurer sets. For a hospital this distinction matters when a decision needs to be escalated beyond the administrator.

Under a cashless arrangement the covered cost is settled between the hospital and the payer. The person remains responsible for amounts outside the cover, such as co-payment, deductibles, non-medical items and excluded treatments.

Cashless normally requires the hospital to be in the payer’s network, and planned treatment usually requires pre-authorization before admission.

Adjudication is where a claim is decided. The payer checks eligibility, policy terms, exclusions, documentation and the applicable rate, and issues an outcome.

Four outcomes are common: full settlement, short settlement, a query requiring further information, and denial. Each has a different operational consequence for the hospital, which is why claims teams track them separately rather than as a single approval rate.

Claim status carries two senses that are worth separating.

In NHCX terms it is a specific transaction: a structured request from a provider to a payer asking for the current state of an identified claim, and a structured response.

In everyday use it means the stage a claim has reached. The difference matters when reading integration documentation, where “claim status” refers to the message, not the state.

Co-payment is a contractual share of the admissible amount borne by the person. It applies after the claim is assessed, on the amount the payer accepts.

It is distinct from an exclusion, where the payer covers nothing, and from a deductible, which is an amount met before cover begins at all.

A coverage eligibility check establishes whether a policy is active and what it covers, before care is delivered and before a claim is raised.

Done well it prevents a large share of downstream denials, because the questions that would otherwise surface at adjudication are answered at the front of the process. NHCX defines it as a standard transaction, which is what makes it automatable rather than manual.

A deductible sets the threshold at which cover starts. Below it, the person meets the cost; above it, the policy responds subject to its other terms.

Deductibles and co-payments are frequently confused. A deductible is met before cover begins; a co-payment is a share of what is covered.

A denial is a refusal to pay, accompanied by a reason code or narrative. Reasons range across eligibility, missing pre-authorization, documentation, coding, policy exclusions and timeliness.

A useful distinction in revenue cycle work is between denials that are avoidable, where something upstream was not done, and denials that are correct, where the treatment genuinely sits outside cover. Only the first category is worth building process around.

Exclusions are the treatments and costs a policy places outside cover, whether permanently or for a stated waiting period.

A denial grounded in a genuine exclusion is not a process failure, and treating it as one wastes appeal effort. Separating exclusion-based denials from avoidable ones is the first step in any useful denial analysis.

A network hospital has a contract with the payer or its administrator setting out which procedures are covered, at what rates, and on what cashless terms.

Being in network is what normally makes cashless available. Outside the network a person usually pays and claims reimbursement afterwards.

A package rate bundles a procedure’s components into one contracted price, typically covering the surgery, stay for a defined period, standard consumables and routine follow-up.

Packages simplify adjudication and make cost predictable, but they also mean that anything genuinely outside the package has to be identified and claimed separately, or it is absorbed by the hospital.

A payer is an insurer, a government scheme or a self-funded entity that carries financial responsibility for care. In claims messaging the payer is the counterparty to the provider.

Third party administrators often act on a payer’s behalf in the operational flow, which is why the payer named on a policy and the organisation a hospital actually corresponds with are frequently not the same.

Pre-authorization is the step where a hospital sets out the proposed treatment and expected cost, and the payer confirms cover before admission.

It exists to remove uncertainty for both sides before money is committed. In practice it is also one of the slowest points in the Indian claims process, which is why it is a primary target for standardisation on NHCX and for automation in revenue cycle work.

In a claims context, provider means the organisation delivering care and submitting the claim. This is the sense used throughout NHCX documentation and in revenue cycle work.

The word carries a second, clinical sense in which an individual clinician is described as a provider, a usage more common in American material than Indian. Where both senses could apply, the surrounding text should make clear whether an organisation or an individual is meant.

A query, also called an information request, is the payer asking for something it considers missing: a document, a clinical justification, a clarification on coding or duration of stay.

Queries are worth tracking separately from denials, and they are common: a claim that is queried is not a claim that is failing, it is a claim that is waiting.

The cost is in time rather than in the decision. Each rework loop restarts the settlement clock instead of continuing it, so a claim queried twice can age well past the point the original timeline implied. A high query rate points at documentation practice at submission, which is fixable upstream, whereas a high denial rate more often points at eligibility and coverage checking.

Reimbursement is the alternative to cashless settlement. It applies when the hospital is outside the network, when pre-authorization was not obtained, or when the payer does not offer cashless for that treatment.

The person carries the cost until the claim is settled, which is why the availability of cashless at a given hospital is a material question rather than an administrative detail.

Short settlement is a partial payment rather than a refusal. The claim is accepted but paid at a reduced amount.

In Indian hospital finance the deducted amount is usually called a disallowance, and appears in published accounts as TPA or insurer disallowances.

Common causes are contracted package rates, sub-limits on room rent or specific procedures, non-medical consumables, and deductions the payer applies on review. Because the claim reads as settled, short settlements are easy to miss unless remittance advice is reconciled line by line.

Revenue cycle management covers the full path from a person arriving for care to the last rupee of that episode being collected or written off.

The stages are commonly grouped as front end (registration, eligibility, pre-authorization), middle (documentation, coding, charge capture) and back end (submission, adjudication, denial management, payment posting, reconciliation).

Most revenue lost in the cycle is decided at the front end, because eligibility and authorisation errors made before treatment surface as denials weeks later, when they are expensive to fix.

Bad debt is receivable value the provider no longer expects to collect. It most often arises from patient responsibility balances such as co-payment, deductibles and non-covered items.

It is distinct from a contractual write-off, which was never payable in the first place.

Charge capture is the point at which clinical activity becomes billable detail. Anything not captured here cannot be claimed later.

Indian hospital finance more often describes the failure than the function, calling the result unbilled services: an investigation is ordered in the clinical system, the test is performed and reported, and the charge never reaches the bill because the clinical and billing systems are not joined up.

Losses at this stage are silent. There is no denial to investigate and no rejection to appeal, because the service simply never appeared on the claim. This is why charge capture is audited by sampling against clinical notes rather than by looking at claim outcomes.

Clean claim rate is the proportion of claims that need no intervention after submission.

It is a more actionable measure than approval rate, because every point below 100 represents rework that has already been paid for in staff time. Tracking it alongside first-pass resolution rate separates claims that go out correctly from claims that end up paid after effort.

Days in accounts receivable measures collection speed across the whole receivable book.

The general finance equivalent is days sales outstanding, and the two terms are used interchangeably in hospital reporting.

The average alone can conceal the problem, because a long tail of aged claims is often what is actually hurting cash flow. Ageing buckets, for example the share of receivables beyond ninety days, usually say more than the single figure.

Denial rate can be counted by claim volume or by claim value, and the two tell different stories. A small number of high-value denials may matter more than a large number of small ones.

The number is of limited use in aggregate. Grouped by reason it becomes a work list, because each reason maps to a specific upstream step that can be changed.

First-pass resolution rate looks past acceptance to settlement. A claim can be accepted cleanly and still require follow-up before it is paid.

Read together, a high clean claim rate with a low first-pass resolution rate indicates that submissions are well formed but something downstream, often eligibility or authorisation, is failing.

Medical coding converts the clinical record into the standardised vocabulary a payer adjudicates against.

Coding quality drives both denial rate and paid amount. Under-coding loses legitimate revenue, and coding unsupported by documentation creates compliance exposure. The correct standard is that the code matches what the record demonstrably supports.

Reconciliation closes the loop between what was billed, what was decided and what arrived in the bank.

Without it, short settlements go unnoticed and aged claims accumulate quietly. It is the least visible part of the revenue cycle and frequently the one where the largest recoverable sums are found.

Remittance advice accompanies payment and sets out the disposition of each claim: the amount allowed, the amount paid, and the reason for any difference.

It is the only reliable basis for detecting short settlement and underpayment, because the bank credit alone shows a total and not its composition.

India has a defined mechanism for this. The NHCX profiles in the ABDM FHIR implementation guide include PaymentNotice and PaymentReconciliation, and the exchange covers payment notification and payment acknowledgment alongside eligibility, pre-authorization and claims.

Specification and practice are different things. Most hospitals today still reconcile from a payer or administrator portal and a bank credit rather than from a structured payment message, which is why reconciliation remains manual work in most finance teams.

An underpayment is a claim that was settled, but for less than the contract entitles the provider to.

Because the claim shows as paid, underpayments do not appear in denial reporting and are only found by reconciling remittance advice against contracted rates line by line. Indian hospitals generally record these as disallowances rather than as underpayments. This is the main reason short settlement is tracked as a distinct outcome.

Write-offs fall into two groups that should never be reported together.

Contractual write-offs are the expected difference between billed charges and contracted rates, and are a normal consequence of the agreement. Operational write-offs are amounts that were payable but were lost to missed deadlines, incomplete documentation or unworked denials. Only the second group represents recoverable revenue.

An Application Programming Interface is the contract through which software talks to software: the requests that can be made, the data required, and the responses returned.

ABDM and NHCX are delivered as APIs rather than as portals to log into, which is what allows the exchange to be automated inside existing hospital systems instead of adding another screen for staff.

DICOM governs how imaging studies are stored and moved. It carries the pixel data together with the metadata describing the study, the equipment and the person.

Because imaging studies are large, ABDM record sharing commonly exchanges reports and links to studies rather than the studies themselves.

Digital Public Infrastructure describes shared digital systems operated as public utilities: open specifications, many participants, no single private owner of the rail.

India’s usual examples are identity, payments and now health data. The pattern matters because it changes where integration effort goes. Instead of every organisation building bilateral connections to every other, each connects once to a common rail.

ABDM and NHCX are the health applications of this idea, which is why they are routinely explained by analogy to payments rather than on their own terms.

Electronic Data Interchange predates modern web APIs. Documents such as claims, remittances and eligibility enquiries are encoded in rigid, position-sensitive formats and exchanged in batches.

It is the comparison point for NHCX. EDI proved that standardising claim messages works at national scale, and also demonstrated the costs of a format designed before the web: batch rather than real time, and expensive to change once embedded.

India’s choice of FHIR over an EDI-style format is a deliberate departure from that history.

An Electronic Health Record is the person-centred, cross-institution view of health information.

Under ABDM’s federated design this view is assembled on demand from records held by each provider, rather than being stored as a single document anywhere. The EHR is therefore something the architecture produces, not something it keeps.

An Electronic Medical Record is one organisation’s clinical record. Its scope is the care delivered by that organisation.

The distinction from EHR is one of scope rather than technology: an EMR is bounded by the institution, whereas an EHR is intended to follow the person across institutions.

Fast Healthcare Interoperability Resources is the HL7 standard underlying most modern health data exchange. It models information as discrete resources, such as Patient, Encounter, Condition and Claim, exchanged over ordinary web APIs.

India’s digital health rails are built on FHIR, which is why a hospital system’s FHIR capability determines how much work ABDM or NHCX integration actually involves.

FHIR R4 is the release that made core parts of the standard normative, meaning they carry a stability commitment that earlier releases did not.

That stability is why it became the common target for national programmes and vendor implementations. When a specification says only “FHIR”, the version still has to be confirmed, because resources differ between releases in ways that break integrations.

A Hospital Information System runs the operational spine of a hospital: registration, admissions, orders, results, billing and discharge.

For ABDM and NHCX work the HIS is the integration point, because it holds both the clinical record and the billing detail a claim needs. Its capabilities usually set the realistic scope of any digital health project.

HL7 version 2 predates FHIR and remains in heavy use for intra-hospital messaging. It is pipe-delimited rather than resource based, and highly variable between deployments.

Most Indian hospitals meeting ABDM requirements are bridging HL7 v2 traffic inside the building to FHIR at the boundary, rather than replacing internal systems.

ICD-10 is the diagnosis classification in widest use, including across Indian claims processing.

It classifies conditions into a defined hierarchy for statistical and payment purposes, which makes it coarser than a clinical terminology such as SNOMED CT and better suited to adjudication.

ICD-11 succeeds ICD-10 with a structure intended for electronic systems and better mapping to clinical terminologies.

Migration is gradual and coexistence with ICD-10 is normal, so claims systems generally need to handle both during the transition.

A Laboratory Information System handles the laboratory workflow from order to validated result.

It matters for ABDM because diagnostic reports are among the most commonly linked record types, and because results are only comparable across facilities when the LIS codes them to a shared terminology such as LOINC rather than to local test names.

LOINC gives laboratory tests and observations universal identifiers. Without it, the same test reported by two laboratories arrives under two different local names and cannot be compared automatically.

It is the reason a consolidated view of results across facilities is possible at all under a federated model.

The National Resource Centre for EHR Standards maintains India’s health data standards, including the FHIR implementation guides that define exactly which resources and fields Indian systems must use.

For integration work this is the practical source of truth. The base FHIR specification says what is possible; the NRCES implementation guide says what is required here, and it is versioned, so the version in use should always be stated.

A Picture Archiving and Communication System is where imaging studies live: acquisition from the modality, storage, and retrieval by clinicians.

PACS and DICOM are frequently conflated. DICOM is the standard for the images and their metadata; PACS is the system that manages them. In record sharing, what usually travels is the report and a reference to the study, because studies themselves are large.

SNOMED CT provides granular clinical concepts and the relationships between them, allowing records to be coded in detail and queried meaningfully.

It sits alongside classifications such as ICD rather than replacing them. SNOMED CT describes clinical detail; ICD groups conditions for statistical and reimbursement purposes.

The Unified Payments Interface is India’s interoperable real-time payments network. Its significance for health data is as a precedent rather than as a payment mechanism.

UPI demonstrated that shared public infrastructure plus a common specification can replace a mesh of private, bilateral integrations. ABDM and NHCX apply the same pattern to health records and claims: connect once to the rail, reach every participant on it.

The analogy has limits worth stating. A payment is a small, standardised message with an unambiguous outcome. A health record is large, clinically variable and subject to consent that can be withdrawn.

X12 is the EDI standard maintained by the Accredited Standards Committee under ANSI. Its healthcare transaction sets cover claims, eligibility enquiries, claim status and remittance advice.

Because United States regulation mandated these formats, X12 became the single national vocabulary for claims there. That is the outcome NHCX is pursuing in India, by a different route: a modern, resource-based standard rather than a fixed-position batch format.

FHIR is deliberately general, which means two conforming systems can still fail to interoperate. An implementation guide closes that gap by specifying exactly which resources and fields are used, which are mandatory, and which value sets apply.

For integration work the implementation guide, not the base standard, is the document that governs. It is also the document most likely to be revised.

A terminology server holds code systems such as SNOMED CT, LOINC and ICD, and answers questions about them: is this code valid, what does it mean, what maps to it.

Centralising this prevents every application from carrying its own drifting copy of the same code lists, which is a common source of failures that only appear at exchange time.

The Indian Computer Emergency Response Team operates under the Ministry of Electronics and Information Technology as the national body for cybersecurity incident response.

Two functions matter for digital health. It empanels the auditors who conduct the security audits ABDM requires, and it issues directions obliging organisations to report cyber incidents within set timelines. Those reporting duties sit alongside, and are separate from, breach notification under the DPDP Act.

The Digital Personal Data Protection Act 2023 defines a Consent Manager as a person registered with the Board who acts as a single point of contact enabling a Data Principal to give, manage, review and withdraw consent through an accessible, transparent and interoperable platform (section 2(g)). The Consent Manager is accountable to the Data Principal and must be registered with the Board (section 6(8) and 6(9)).

This is a different thing from ABDM’s Health Information Exchange and Consent Manager, despite the shared name. The HIE-CM is a technical component within the health data exchange; the DPDP Consent Manager is a statutory role across personal data generally.

Where a document says only “consent manager”, establish which is meant before drawing any conclusion. In health data work both can be in scope at once.

The Digital Personal Data Protection Act 2023 governs the processing of digital personal data in India.

It defines the data fiduciary that determines purpose and means of processing, the data principal to whom the data relates, and the data processor acting on a fiduciary’s instructions. It establishes consent requirements, purpose limitation, breach notification duties and the rights of individuals.

Health data processing under ABDM sits inside this framework. Meeting ABDM’s technical consent requirements does not by itself discharge obligations under the Act.

The Digital Personal Data Protection Act 2023 requires a Significant Data Fiduciary, a class the government designates by notification, to appoint a Data Protection Officer based in India.

The officer is the published point of contact for grievances and represents the fiduciary on data protection matters. Ordinary data fiduciaries must still publish a contact for grievances, but are not required to appoint a designated officer.

The General Data Protection Regulation has applied across the European Union since 2018 and has shaped data protection law well beyond it.

India’s Digital Personal Data Protection Act 2023 shares recognisable ideas with it, including consent as a basis for processing, purpose limitation and individual rights. The terminology differs, with data fiduciary and data principal in place of controller and data subject, and so do the specific obligations. Reasoning about Indian duties from GDPR knowledge alone is a common and expensive mistake.

The Health Data Management Policy is the National Health Authority’s stated framework for privacy within ABDM. It covers consent, purpose limitation, data minimisation, the rights of individuals and the obligations of participants.

It predates the Digital Personal Data Protection Act 2023 and is narrower, applying to the ABDM ecosystem rather than to personal data generally. Both can apply to the same processing, and the Act is the higher authority.

The Health Insurance Portability and Accountability Act of 1996 sets privacy and security standards for health information in the United States.

It appears in Indian discussion as a benchmark. The comparison is useful for illustrating concepts, but HIPAA has no force in India, where the Digital Personal Data Protection Act 2023 and the ABDM Health Data Management Policy are the applicable frameworks. Claims of “HIPAA compliance” by Indian vendors should be read as a description of practice, not of legal obligation.

Section 8(6) requires that, in the event of a personal data breach, the Data Fiduciary gives the Board and each affected Data Principal intimation of the breach, in the form and manner prescribed.

The duty attaches to the fiduciary even where the breach occurred at a processor, which is why vendor security arrangements are a fiduciary’s concern and not solely the vendor’s.

Consent carries two related but distinct meanings in this field.

In the statutory sense under the Digital Personal Data Protection Act 2023, consent is the legal basis for processing personal data, and the Act sets conditions on how it must be obtained and how withdrawal must work.

In the ABDM sense, consent is operationalised as a consent artefact carried by the consent manager. The artefact is the mechanism; the statute sets the standard the mechanism has to meet.

A consent artefact is the structured expression of a person’s permission. It names the requester, the record types, the purpose, the date range of records covered and the period for which access holds.

Because it is machine-readable, it is enforced rather than merely recorded. A health information provider checks the artefact before releasing anything, and revocation takes effect for subsequent requests.

The artefact is the ABDM technical instrument. It is not the same thing as consent in the statutory sense under the DPDP Act, though a given disclosure may need to satisfy both.

The data fiduciary decides why and how personal data is processed, and bears the Act’s obligations: lawful basis, purpose limitation, accuracy, security safeguards, breach notification and honouring data principal rights.

In health settings the hospital is normally the fiduciary for the records it creates. Software vendors acting only on its instructions are generally processors rather than fiduciaries, though the classification depends on who actually decides purpose.

The data principal is the person the data is about. Where that individual is a child the term includes the parents or lawful guardian, and where the individual is a person with disability it includes their lawful guardian acting on her behalf (section 2(j)).

The Act grants the right to access information about processing (section 11), to correction, completion, updating and erasure (section 12), to grievance redressal (section 13), and to nominate another individual to exercise those rights on death or incapacity (section 14).

The term corresponds to “data subject” in other jurisdictions. In ABDM material the same person is usually described through their ABHA rather than by this statutory term.

A data processor acts on the fiduciary’s behalf rather than deciding purpose itself. The Act permits a fiduciary to involve a processor for activity related to offering goods or services to Data Principals only under a valid contract (section 8(2)), so the contract is a statutory requirement and not merely good practice.

Accountability stays with the fiduciary. Section 8(1) makes a Data Fiduciary responsible for complying with the Act in respect of any processing undertaken by it or on its behalf by a Data Processor, which is why a hospital cannot transfer its obligations to a vendor by outsourcing the processing.

Purpose limitation binds use to the reason given at collection.

In health data exchange it is what prevents records shared for treatment from being reused for an unrelated purpose. The ABDM consent artefact carries the purpose explicitly, which is how the principle is made enforceable rather than declarative.

Retention concerns the period for which data is held once its purpose is complete.

In healthcare this interacts with separate record-keeping obligations that require clinical records to be held for defined periods, so the shortest permissible retention is rarely the applicable one. The two sets of rules have to be read together.