This blog post is a slightly expanded version of a recent Twitter thread that I live tweeted during the creation of a Wardley map looking at health and care architecture in relation to identity services and specifically, how we manage patient demographic information. You can read more about Wardley mapping from Simon Wardley’s own blog.

---

So I’ve been practicing my @swardley mapping to try to look at one facet of our health and care architecture and ecosystem: patient demographics. Wardley maps use a value chain to show user need and their dependencies running from top to bottom.

Understanding patient identity is pretty much essential to all that we do in health and care. One of major problems in health is that legacy applications have tended to be “full stack”, containing different components that are user-facing, do business logic and that do data.

This approach is shown in this schematic:

The application is dependent on components that support user-facing logic, components that handle business logic, and components that provide data storage. All are dependent on computing power and computing power is dependent on power (electricity).

The historic approach to health and care software is the procurement of multiple ‘full-stack’ applications and consequently we, within health and care, have to consider how to integrate these applications in order to ensure information is available at the right time across different systems. In general, however, we have seen multiple applications in silos, resulting in patients being surprised that updating their address at their general practitioner might not be propagated to, for example, the radiology booking office.

We realised that running multiple health and care applications each with their own idea of patient demographics was a BAD IDEA. Many applications switched to using demographic information from the local (organisation-bound) “patient administrative system” (PAS).

As a result, the user facing application becomes dependent on local (organisation) patient administrative system. However, that might work in one organisation, with the PAS acting as an authoritative source of patient identity (demographic) information, but we have multiple organisations! So what happened? We ended up with multiple applications and multiple organisations, all in silos:

And now we have a problem. How do we share information about patients if we can’t match identities between organisations? How can we track the progress of a pathway of care across organisational boundaries without this? Patients don’t experience a “single seamless system” but the fractured, silo approach is evident for all to see - they update their telephone number with their general practitioner and are surprised when the hospital doesn’t know about the change.

Enter the EMPI, or “enterprise master patient index”.

But, you will also see that we need a new national identifier service, the WDS, that can reach out to NHS England who provides NHS number generation. This is getting complicated. How do we write applications that can deal with this? And what if the patient wants to get involved?

Are we now expecting applications to handle understanding demographics across multiple PAS, and to manage the ongoing updates and calls to the NHS Number Tracing Service?

Surely we want a “one system” approach in Wales, centred on the patient and not the organisation?

And hold on. We need to start running analytics across our whole enterprise, seeing how patients fare in the course of their care. How do we track them in our analytics software? We’re going to take A&E attendance data from a PAS and then, how do we match up information?

In Wales, there is an enterprise service bus (ESB) which securely carries HL7 V2 messages to request, update and merge demographic information. This approach means that your application will need to plug-in to what is essentially a firehose and deal with filtering and managing these messages to track changes over time.

Mapping

Mapping allows us to add another axis - the maturity of our components - from components that are brand new and being developed, to those that are custom-built, to those we can buy, to those that are a commodity (readily interchangeable alternatives exist). Let’s do that:

We have a problem and the map demonstrates it for us. The map allows us to start to test our models & starts our discussions. Are we really expecting each of our user facing applications & analytics to try to deal with this mess? Instead, surely we need a single authoritative source of identity?

And that means we can break apart the tight (organisationally-centric) coupling between our applications & individual PAS Instead, we do the hard work to hide the complexity inherent in what is a complex adaptive enterprise containing multiple sources of demographic information.

We can see that our single authoritative source, abstracting (hiding) the complexity of our legacy problems with patient identity, will itself evolve towards being a commodity over time as we switch to using it. The red arrow shows the movement over time, as we first build and then deploy this service, and applications move from directly integrating with local administrative systems to a new shared national service.

So how to permit such an evolution? Such a switch will be best driven by adoption of robust open technical standards that make it easy for applications to consume and process patient identity information using this service. That means making it easier for applications to use our new service rather than directly integrating with proprietary lower level systems. To enable that transformation, we must recognise the value of open standards. So that means we must add standards and the supporting processes for their adoption to our map:

The final step is that this new service encapsulates and hides underlying platform implementation details. It is conceivable that, over time, that underlying implementation can be changed, simplified and removed without changing client application code, because we’ve ensured loose coupling via the use of open standards and APIs.

Conclusions

So I think this demonstrates that:

1. We need a single authoritative source of patient identity information
2. Applications should delegate identity services to that module rather than trying to manage demographics themselves …
3. We need to adopt robust open technical standards (e.g. HL7 FHIR Patient)
4. We need to support the ongoing processes to curate, manage and adopt technical standards to drive the commoditisation of a new “one system” approach to demographic, patient identity services.

Demographics is but one foundational service that are needed to build a modern open platform for health and care. I discuss the wider issues on the next steps in building an open platform in different blog post, including the importance of demographics and appointments/scheduling as good examples of programmes of work, focused on implementing products not projects, that will give us valuable learning for our next steps.

Mark Wardle