Thread by @mwardle

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.

But historically, 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).

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? 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?

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?

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 & 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? 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 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 need to become a commodity over time as we switch to using it.

But 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. So that means we can add standards and the supporting processes for their adoption to our map.

So I think this demonstrates that: a) we need a single authoritative source of patient identity information, b) applications should delegate identity services to that module rather than trying to manage demographics themselves ...

c) we need to adopt robust open technical standards (e.g. HL7 FHIR Patient) and d) 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. /End