#84. A Blueprint for Digital Public Infrastructure in Health

The most interesting thing I read this week was the draft Reference Architecture for Digital Public Infrastructure (DPI) for Health, currently out for public consultation. Thanks to Jordi Piera Jiménez for sharing a great document. At over 300 pages, it’s not a light read, but it tackles a common challenge of how do you stop building disconnected applications and instead create national digital capabilities that can be reused across the system?

The document argues that health systems should be built on shared foundations such as digital identity, registries, and interoperability services rather than a collection of standalone systems. The emphasis on open standards, interoperability and reusable components is particularly welcome.

Another strength is the recognition that governance matters as much as technology. The document emphasises the importance of stewardship, trust, standards and national coordination. It also avoids presenting DPI as a greenfield exercise, instead acknowledging that most countries will need to evolve existing systems over time rather than replace them wholesale.

Overall, the direction of travel is very good. However, as with many digital health frameworks, the harder questions lie in implementation. In the spirit of openness, my initial comments on this draft are summarised below.

1. Start with User Needs

The document talks extensively about infrastructure and architecture but says surprisingly little about users. One of the strongest principles in the UK Government Digital Service framework is “Start with user needs.” In a healthcare context, that means patients, carers, clinicians, administrators and operational staff. I am a strong believer that no architecture is complete unless it includes a clear overview of who its users are.

I think this framework should explicitly emphasise this as ones of its principles in section 2.3, making it clear that digital public infrastructure exists to solve real user problems rather than simply create technical consistency.

2. Expand the Implementation Guidance

The document acknowledges that most countries are not starting from scratch. It also (understandably) focuses on shared registries, interoperability services and common infrastructure. However, it is less clear how these components interact with the highly variable application landscapes that exist across countries.

For example:

One country may have a single national EHR used across most care settings.
Another may have dozens of regional, hospital and primary care EHRs.
A third may have hundreds of provider systems operated by different organisations and vendors.

In theory, all of these environments could sit above the same DPI layer. In practice, the effort required to integrate them may be radically different.

The guidance would benefit from discussing architectural patterns from this perspective vs the patterns outlined in Section 3.6. This would account for readers with different levels of application fragmentation, particularly where existing systems are monolithic, proprietary or have limited interoperability capabilities.

3. Review the Role of the Lifelong Health Reocord

The guidance describes a lifelong health record as an aggregated view assembled from multiple source systems. That reflects the reality of most health systems today, where information is dispersed across many applications and organisational boundaries.

However, if a country were designing a digital health ecosystem from first principles, would it choose to create a separate longitudinal record at all?

One could argue that the need for a lifelong health record is itself a consequence of fragmented application architectures. Rather than maintaining multiple source systems and then aggregating information into a separate record, a greenfield architecture might instead be built around a shared patient record platform, with clinical and operational applications reading from and writing to the same underlying data layer.

So from reading this framework, I am unsure if the LHR is part of the reference architecture as an acknowledgement of the current status quo in most countries, or if it is here a standalone component irrespective of this.

As an aside, the reference to the LHR being a FHIR store is something I personally don’t agree with, but that is well documented here: https://medium.com/@alastairallen/fhir-openehr-2022-53716f837340

4. Include Change Management and Adoption

I appreciate this is a technology reference architecture but despite this I still believe that one notable gap is change management.

The document describes what the future architecture looks like, but less attention is given to how organisations and users transition to it, and how we measure if is delivering the anticipated benefits. Adoption rarely happens automatically. Countries need approaches for stakeholder engagement, training, capability building and behavioural change if the benefits of DPI are to be realised.

5. Strengthen the Focus on Clinical Safety

Healthcare differs from most other digital public infrastructure domains because technology failures can directly affect patient care. As services become consolidated and shared across multiple systems, organisations and use cases, the nature of risk changes. A failure is no longer isolated to a single application or organisation; instead, it can propagate across interconnected services at scale, introducing the potential for widespread unintended consequences. For example, defects in shared interoperability layers, common patient record services, or national identity and consent mechanisms can cascade into multiple clinical workflows simultaneously, increasing the likelihood of systemic disruption rather than localised failure.

Clinical safety, safety assurance and risk management therefore deserve greater prominence as cross-cutting architectural concerns alongside interoperability, security and governance. They must be embedded not just at the point of system design, but continuously across lifecycle management, change control, and operational monitoring.

Despite these comments, this is an important and timely contribution to the conversation about the future of national digital health infrastructure. The emphasis on open standards, interoperability and shared capabilities is exactly the right direction of travel, and I look forward to seeing how the framework evolves through the consultation process.

Originally published on LinkedIn.