I gave a talk on “Unbundling the electronic health record” at #reclojure22 - . I think we need to turn what we think of as the “electronic health record” inside out.
The conventional approach means thinking in terms of applications, and not data, and is centred on organisations / providers, not the patient, or the wider ‘service’. Architecturally, it is a monolith, at least to outsides, and proprietary and organisationally-centric.
Standards and interoperability in the conventional model are outward-facing - requiring external interfacing and a combinatorial explosion. We end up with multiple concretions, fossilised architectures that are poorly adaptive to change, with data only in context of applications.
We end up with false dichotomies between the systems, applications, services, approaches, tooling, teams, departments, organisations and even the programming languages we use depending on whether we’re using those data for direct care, analytics or research. This is madness.
Instead, we should build our systems ‘like we program the outsides’ of our systems - breaking apart our complex domain of health & care into smaller more tractable components only to recompose together to solve user problems, prioritising meaningful data.
Those data should be patient-centred, standards-based and include models of first-class domain events, and we should think of those data as both at rest in buckets, and moving around in pipes / conveyor belts in order to orchestrate and coordinate care across boundaries.
You can try alternative approaches, such as interoperability through convergence [all use the same software], or interoperability through standards / exchange [you create shared records] but far better to unbundle the EPR by making first-class composable data/software components.
Who coined the term shared medication ‘repository’ and does that concept even make sense?
In certain constrained clinical environments, such as inpatient care, it might be a reasonable assumption that the inpatient electronic prescribing medicines administration (ePMA) system is the 'golden record' representing the ‘current medication list’
But even there, a patient may pop down to outpatients and receive their regularly monthly infusion, or take OTC medications. If a drug is given 3-monthly in the community, is it ‘current’? What does ‘current’ even mean?
Graph queries across distributed heterogeneous patient data make run-time analytics and inference magically easily. Here I issue a query - a bit like SQL - for some patient data for patient 17490 - I’m asking for attributes but something special is happening. What is this doing?
If you look carefully, I’m asking for attributes - but I’m drilling into those and having my queries resolved by multiple microservices; this is a federated distributed electronic health record. We start at an edge and navigate seamlessly. Notice how I can resolve ethnicity and
fetch information useful in analytics - the transitive closure tables are there for any arbitrary relationship. Likewise, I can ask for a NHS ORD name (organisation name) or use a more standardised property name (skos:prefLabel) and get the same result for GP surgery or hospital.
So I built an electronic patient record system that's been running since 2007. It was, as far as I am aware, the first implementation of SNOMED CT in a live clinical system. Most users have never known that SNOMED is its *lingua franca*, and most think it is a bespoke 'database’.
They think it’s bespoke because built multiple subject and specialty-specific "prisms" through which to see, what is essentially, single record. I just take some basic building blocks and stitch them together.
There is no better iterative fast feedback loop than being a user as well as a developer. It is difficult to know what works and what doesn't work without an exploratory phase of design and implementation.
1. We want the right information at the right time, for patient, for professional, for direct care, for management, for quality improvement and for research. We use that information to make the best decisions we can.
2. We have an enormous existing legacy of data in different systems and any changes will be incremental; that means we will always have heterogeneity. A lot of data messy, and always will be. Care moves around. Home, community, hospitals, across borders, across disciplines.
So graph-based APIs / queries are a natural fit in health and care - building a semantic graph across health data using first-class properties. Think RDF for health.
For instance, I'm now able to resolve e.g. an index of deprivation score against a patient by walking the graph of properties from current address to LSOA to the index. At the client level, I don't care how those data are fulfilled.
I can do this for arbitrary edge points on the graph, so to lookup a namespace/identifier tuple based on NHS number, local PAS identifier, or whatever, and follow the graph via ontological defined properties. See wardle.org/strategy/2020/… for the background to this work.
We need to take open-source mainstream for health and care, with public sector investing in in-house software development capability. We need to move from trying to integrate full-stack applications to thinking about data and software services in a platform.
There will be a flywheel effect from the availability of open-source, standards-based foundational services and components that can be composed in interesting ways to solve user problems in health and care. Big wins from composing small, independent little wins that stack up!
Each component, of course, itself solving a hard problem but abstracting away those difficulties to give us something to build upon. Buildings blocks that make doing the right things easier than doing the wrong things.