- Every data use tied to a recorded purpose, and to consent where consent is the basis
- Results shareable into patients' digital health records with their approval
- Local test codes mapped to a standard terminology once, reused everywhere
- A pseudonymised research store kept apart from operational data
- Breach detection and reporting routes ready ahead of May 2027
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A diagnostics chain in India ran collection centres, home sample collection and several regional laboratories. Results went out as PDFs by email and WhatsApp. Each lab used its own test codes, so a haemoglobin result from one city did not match the same test from another. The analytics team copied production tables into a warehouse with names and phone numbers intact, and the business wanted to start using the data for research partnerships and AI models.
Why now. India's Digital Personal Data Protection Rules were notified in November 2025 and apply in phases1. The consent manager framework applies from 13 November 2026, and most obligations on data fiduciaries, including notices, consent, data principal rights, breach reporting and children's data, from 13 May 202723. At the same time, the Ayushman Bharat Digital Mission (ABDM) gives patients a digital health account and a consent-based way to share records between providers4. The chain wanted to join that ecosystem properly and be ready for the DPDP deadlines in one programme.
What had to be true
- Purpose for every use: reporting results, billing, analytics, research and AI, each with a recorded basis.
- Patient-approved sharing of results into digital health records through ABDM.
- One meaning per test: local codes mapped to a standard terminology once.
- Research kept apart: pseudonymised, purpose-bound and never mixed with operations.
- Breach-ready: detection, assessment and reporting routes tested before May 2027.
Architecture
The data flow, end to end
- RegisterThe patient is registered with a clear notice and choices for optional uses
- TestThe sample is processed; the result is stored with its local code
- StandardiseThe result is mapped to a standard code and expressed as a FHIR resource
- ShareWith the patient's approval, the result is linked to their digital health record
- PseudonymiseFor approved research purposes, identifiers are replaced before data enters the research store
- HonourWithdrawals and rights requests flow back through the consent service to every store
The hard part: one test, many meanings, many purposes
The first problem was meaning. Each lab had grown its own test catalogue, so the same test had different codes and units across cities. Mapping every local code to LOINC once, with the mapping owned by a clinical team and versioned, made results comparable for doctors and usable for research. See clinical terminologies and OMOP vocabularies.
The second was purpose. Operational use, such as reporting a result, rests on a different basis from research. The team kept them physically apart. The research store follows the OMOP Common Data Model, built through a planned extract, transform and load process that starts with the person and visit structure before clinical tables5, and it only ever receives pseudonymised data for recorded purposes. See FHIR to OMOP architecture.
The third was withdrawal. A patient who withdraws consent for research must be removed from future extracts, and the system must be able to show that. Because every research load is driven by the consent service, a withdrawal stops the next load and is recorded against the patient's consent history.
Consent is not a checkbox at registration. It is a record that every pipeline reads before it moves data.
How it ran
- Test catalogue owners
- LOINC mapping review
- Result formats
- Consent service
- ABDM and FHIR integration
- Research store
- Purposes and notices
- Research governance
- Breach playbook
- Personal data inventory
- Purposes defined
- Warehouse copies removed
- Consent and purpose service
- New notices
- Consent manager interfaces
- LOINC mapping
- FHIR results
- ABDM integration
- Pseudonymisation
- OMOP store
- Breach drills
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Central consent and purpose service | Consent flags in each system | One record every pipeline checks |
| Map to LOINC once | Map per use case | Consistent meaning for care and research |
| Separate pseudonymised research store | Research on the warehouse | Purposes stay separate and auditable |
| Design for consent managers now | Wait for registrations | Interfaces ready when managers arrive |
| Remove identified warehouse copies | Restrict access only | Data that is not there cannot leak |
What I'd do again, and differently
Again: put clinicians in charge of terminology mapping. It was the foundation for everything else. Differently: deal with the identified warehouse copies on day one. They were the largest risk and the easiest to remove. Related: a DPDP-ready consent platform for lending, a FHIR and OMOP evidence platform, India's proposed frontier AI law and the India page.
If you hold health data in India, see my healthcare data architecture work, or analyse your challenge and bring the result to a call.
- 1Digital Personal Data Protection Rules, 2025Wikipedia · 2026
- 2DPDP Act Timeline 2026-27: What's Live, What's ComingNetwork Intelligence · 2026
- 3
- 4Ayushman Bharat Digital MissionNational Health Authority (India)
- 5The Book of OHDSI: Extract Transform LoadOHDSI · 2021