My comments on WHO's draft guidance for health DPI

In 2026, WHO opened a public consultation on a draft guidance document and invited anyone to comment before it is finalised. The draft addresses a question every country building digital health infrastructure eventually faces. What should be shared? Which registries, records and services should be national public infrastructure, and which should be left to individual programmes and vendors?

The draft is called the Reference Architecture and Guidance for Digital Public Infrastructure for the Health Sector (DPI-H), and it runs to 254 pages. I read it and submitted eight comments through the open call, each with suggested wording. This piece explains what the draft sets out to do, who it is written for, and what I suggested. The comments were a public submission like many others, and WHO will decide what goes into the final version. This is my own account, not an official assessment of the guidance.

What the draft sets out to do

Digital public infrastructure (DPI) usually means three foundational layers that any sector can build on, digital identity, payments and data exchange. India’s Aadhaar and UPI and Estonia’s X-Road are well-known examples.

The draft’s starting point is that health needs more than the foundations. A national ID system establishes who a person is, but health also needs to know what that person is eligible for, what treatment they are receiving, what has been dispensed, and whether they have agreed to share specific data with specific people. Foundational identity can also miss people the health sector must still serve, such as newborns before civil registration and refugees.

So the draft defines DPI-H, shared health-specific infrastructure that sits on top of foundational DPI rather than duplicating it. It includes core registries (clients, facilities, health workers and products), a Lifelong Health Record that follows a person across their life and across the health system, terminology services, and shared services such as consent management and clinical decision support. It links these to priority health goals, including trusted data foundations, health financing and resilience to climate change and epidemics. It also introduces REDDHI (Resilient Essential Data and Digital Health Infrastructure), a minimum starting set of components, with several entry points for countries starting from very different places.

Who it is written for

The draft names its readers, including health ministries and programme managers, the authorities that run national DPI, architects and technical teams, development partners, procurement teams and policy makers. It offers each of them a reading path, so that no one has to read all 254 pages.

It is also clear about who should benefit. Patients get continuity of care. Health workers get less duplicate data entry and better information at the point of care. Programme managers get a consistent data foundation across programmes. Finance ministries get visibility into health spending, donors get infrastructure that outlasts individual funding cycles, and researchers get better data under appropriate governance.

Having worked with health departments, programme teams and development partners, I recognised these groups and the problems the draft is trying to address for them. That shaped how I read it.

What I found especially useful

Three ideas stood out.

Interoperability is treated as a property, not a product. The draft describes interoperability as something that should run through the whole architecture, through shared standards, common data models and defined exchange patterns, rather than a component built once. I think this is one of the most useful points in the draft, and I have written separately about why.

Data models come before software. The draft stresses that what data a country captures, and how it is structured, matters more than which software it buys.

It is realistic about where countries start. The different entry points recognise that countries begin from very different places, and that projects can move faster than national governance if they are not coordinated.

My eight comments

WHO asked for comments tied to specific sections of the draft, with suggested replacement text. My eight comments were these.

1. Emergency medical response and blood services
2. Resilience testing under peak load and degraded connectivity
3. Secondary use of data in federated and virtual record models
4. Patient-generated health data
5. Clinical risk management
6. Checks between enrolment and claims in benefits schemes
7. Evidence for finance ministries
8. Where consent is checked in each exchange pattern

My eight comments alongside a simplified view of the architecture in the consultation draft. Diagram: Hussain MS.

Services that cannot wait

The draft’s examples lean towards routine care, and two essential services appear less often, emergency medical response and blood and transfusion services. Both appear in WHO’s own Classification of digital interventions, services and applications in health, and both depend on knowing which facilities exist, what they offer and where supplies are.

I suggested small additions, such as listing blood banks and emergency medical service stations among the illustrative facility types in the facility registry, and emergency care and transfusion among the services a facility can offer. The aim was for the architecture to support the information these services need, not for national DPI to run dispatch or transfusion services itself.

Resilience testing

The draft’s testing chapter covers functional conformance in detail, meaning whether a system does what the specification says. I suggested making testing for stress conditions more explicit too, especially for shared components whose disruption could affect many services at once.

The COVID-19 pandemic highlighted how quickly demand on digital systems can change, with registrations, laboratory results, surveillance reports and supply requests rising together, sometimes while connectivity is poor. I proposed a subsection on non-functional and resilience testing, asking implementers to test core registries and the Lifelong Health Record under high loads and degraded connectivity, and to record how systems degrade and recover.

Data use beyond the clinic

The draft lets countries implement the Lifelong Health Record as a central store, a federated network or a virtual record assembled on demand. The ability to provide data for secondary uses, such as the health management information system, surveillance and research, is marked as “Recommended”. In a federated or virtual model, if this is not designed in from the start, population-level data may need to be collected again separately. I suggested making it “Required” for those models, with access through agreed governance mechanisms. How it is done would still need to fit each country’s legal framework and privacy requirements.

I also suggested an optional, governed pathway for patient-generated health data, such as readings from home blood-pressure monitors, self-tests and wearables, to enter the Lifelong Health Record. That would need the same consent and data quality safeguards as any other source, a clear record of where the data came from, and a way to tell patient-reported readings apart from clinically verified ones.

Clinical risk management

The draft includes clinical decision support as a shared service, with provisions on safe failure, knowledge review and liability. I suggested that it could more explicitly address documented clinical risk management, including identifying hazards, assessing and reducing risks, naming who is accountable, and reviewing this over time. Standards such as ISO 14971 for medical devices, and England’s DCB0129 and DCB0160 standards for those who make and those who deploy health IT, offer useful reference points. As decision support increasingly includes AI, this becomes more important.

Money and trust

Checks in benefits schemes. Health financing schemes often run separate systems for enrolment and claims. I suggested that the guidance consider reconciling enrolment and claims against the shared client identity, including a check across schemes for possible duplicate enrolment. A possible duplicate is a prompt for review, not proof of fraud, so any such check would need clear rules, good quality data and safeguards against wrongly excluding people.

Evidence for finance ministries. The draft argues that shared infrastructure can reduce leakage and improve efficiency. I suggested adding a few well-sourced country examples, such as Estonia’s X-Road or Singapore’s API exchange, with enough context to show the costs, benefits and conditions behind them.

Where consent is checked. The draft gives consent a central place and supports centralised, federated and hybrid exchange. I suggested making explicit, for each pattern, where and when consent or other legal permission is checked and how it is enforced, including how withdrawal and exceptions are handled. For a federated exchange, one option is for the requesting system to check current consent with the source system or a consent service before data is returned.

Why take part

Public consultations like this one are open to anyone, and they give practitioners a direct way to share implementation experience with the people writing global guidance. The final document will be read by ministries, architects, donors and vendors in many countries. I would encourage anyone working in this field to take part when the next one opens.

Views are my own. Descriptions are based on the public consultation draft (Draft V1.0), which may change in the final publication.

Sources

• WHO, Reference Architecture and Guidance for Digital Public Infrastructure for the Health Sector, Draft V1.0 for public consultation (2026)
• WHO. Call for public comments and invitation to review, Draft Reference Architecture Guidance for Digital Public Infrastructure for Health (DPI-H), July 2026
• WHO, Classification of digital interventions, services and applications in health, 2nd edition (2023)
• ISO 14971, Medical devices, application of risk management to medical devices
• NHS England, DCB0129 and DCB0160 clinical risk management standards
• X-Road (Nordic Institute for Interoperability Solutions)