{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicpoikvhody7gp5vs77mraffgudrkm7l2ktpkhiwaqprgbozziovy",
    "uri": "at://did:plc:2ngsl5btroik454wzz7vpbzq/app.bsky.feed.post/3mn6cg5tbnn2u"
  },
  "canonicalUrl": "https://oli.zilla.org.uk/2026/05/21/digital-interop-in-the-nhs",
  "description": "We need interop that is loosely coupled across a diverse ecosystem.",
  "path": "/2026/05/21/digital-interop-in-the-nhs",
  "publishedAt": "2026-05-21T00:00:00.000Z",
  "site": "at://did:plc:2ngsl5btroik454wzz7vpbzq/site.standard.publication/3mn67n3cam32w",
  "textContent": "Talk: Digital Interoperability in the NHS\n\n_A talk I presented in May 2026 to the NHS DPSP team._\n\n<figure>\n\n<figcaption>\n\nI’m going to talk about digital interop in the NHS, starting with my motivation:\n- The bad things that happen when interop fails.\n- The realities of what is holding up progress.\n- Some ideas from academia on patterns of nation scale digital transformation.\n- And then look at work that is happening here and in Catalonia.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nTo declare my biases up front\nI believe open source code, open data formats and open digital protocols are the essential ingredients for interoperability.\nMy credentials:\n- I’ve been and open source software engineer for 20 years.\n- I’ve spent 6 years working on open data formats and protocols to bring the magic of content addressing to the web.\nAnd for the last 2 years I’ve been studying a Masters of Public Administration focusing on collaboration, governance, economics and public value.\n…and it’s where I built the Digital Public Infrastructure map with the team at UCL IIPP\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nIts live at dpimap.org\nIt lets you view info about the spread of nationally owned digital infra for ID systems, payment rails, and data exchanges around the world.\n\nThe data is available in open formats like CSV, JSON\nThe code is open source…\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nI also want to take a moment to acknowledge that it feels like a rough time work in open source, with new supply chain attacks and the scrutiny and noise of AI models.\n\nIt is understandable to want to hide from it, but all the arguments against security through obscurity still stand.\nAnd we really need to be collecting and sharing the fixes for these vulnerabilities in the public domain.\n\nNHS DPSP Team: I see your good open source work, and I support it.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nIn the meantime we can still make progress on interop!\nOpen source lets us collaborate at build time,\nreusing work, and sharing solutions to common problems\n\nOpen data formats and open protocols let diverse systems collaborate at run time\n\nUsing open formats let us\n- store data outside of apps\n- save our work so we can open it again without paying a tithe to a proprietary vendor.\n\nUsing Open protocols let us\n- define the rules of a multiplayer system, in a way that can\n- shape the market for public and private vendors to collaborate,\n- protect it from lock-in and\n- support a healthy digital ecosystem \n- ...where vendors can demonstrate their tool by plugging it in to a well defined interface and show that it works, rather than promising it will once the procurement marathon is done.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nSo to the motivation:\nwhy am i trying to fit any of the complexity of the NHS digital universe into my head.\nBad things happen when interop fails:\n1. There are process errors that harm patients and staff\n2. Data loss and degradation of our health records\n3. And Digital sprawl that wastes our time and money\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nMy other motivation is I have a thesis to write!\nPlease do reach out and tell me what else is going wrong, or anything i have got wrong.\n\nIn the meantime: I am going to share back to you what i have heard in interviews, data preservation groups, and from other researchers.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nI reached out to a network of GPs in south london and asked\nWhat problems does the current lack of interop cause?\n\nI got a response that basically said “all of them”\n\n> Interoperability relevant to every Learning Event in last 2 months.\n> These aren't the most heinous, just examples of how frequently\n> there are issues and how severe the consequences are\n\nThey signed off with “if you want to see more, just ask again next month”\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\n> Urgent cancer referral not sent.\n> \n> Patient consultation recorded on one platform (EMIS), then referral form raised in a separate platform (DXS), then referral manually sent off to hospital via 3rd platform (eRS), then safety netted by the practice in a fourth platform (Excel).\n> \n> _...lots of potential moments to make a mistake._\n> \n> Manager at a GP in South London\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\n> Child protection issue missed in A&E document\n> \n> Important info buried in 100s of letters / PDFs / Word docs in different formats received each day from services.\n> \n> _...Time consuming and prone to error due to sheer volume_\n> \n> Manager at a GP in South London\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\n> Death notification not actioned\n> \n> Notifications sent by post/email, have to be manually uploaded, duty Dr. notified, then task sent to manager to process the deduction.\n> \n> Manager at a GP in South London\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nIn summary:\n- Staff are manually covering the interoperability gaps - it’s draining, mechanical work.\n- And those gaps create room for errors that harm patients.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nNext up: Data loss!\n\nI attended the inaugural Digital Preservation Coalition meeting focused on Health records. Convened by Marcus Baw, and attended by clinicians and health data archivists across the UK!\n\nThe takeaway was that we are storing health records in many different proprietary formats. As we move data from EPR to EPR it gets degraded, as it has to be translated from one custom schema to another.\n\nWe have retention policies to keep health records for 30 years, and in places like Barts they increase that to 40 years for cancer records. But if that data is repeatedly degraded along the way it will fail to serve its purpose to inform clinical decisions.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nThis paper from 2021 puts a number on it.\n\nWhen moved between EPRs from the same vendor the mean score was 0.68 for how closely the representation of the info matched the source system.\n\nWhen moved between EPRs from different vendors the mean score was 0.22.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nThese problems are reiterated by “the bit list of endangered digital materials”.\n\nIt lists medical records as “endangered”, with “immediate action required” and “loss has already occurred”.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nLetting vendors pick terminology creates confusion.\n\nLetting vendors pick our data formats causes degradation of our health records.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nDigital Sprawl — the NHS has A LOT of IT systems.\n\nSome hospitals have over 400 IT systems. Treating a patient can involve 10 or more systems.\n\nThis drains clinicians' time.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nNot a problem in itself, but just for a sense of scale, there are 44 thousand IT systems connected to the NHS Spine now, from 26 thousand organisations.\n\nThere are many more ad-hoc shadow IT systems out there too.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nUsing data collected by 6b.health, I built a chart to show the number of distinct EPR systems per county. Some have 10! That’s ok!\n\nThis is a somewhat risky chart to share. One way to interpret it is that we should have fewer distinct EPR systems, and that we should standardise on one.\n\nBut economists would call that a market failure, a monopoly. Historically, monopolies lead to predictable outcomes: the product gets more expensive while the quality stalls or declines.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nDiversity in the market is good. You want competition!\n\nWhat we need are open data formats and protocols so we can easily swap between providers without laborious and “degrading” translation work. Convergence on a single provider is not interoperability!\n\nIt’s worth calling this out, as it seems to come up a lot. For example, the GPs in South London have been told by the ICB that they will only get tech support for EMIS. If you use anything else, you are on your own, and you will have additional manual reporting overhead that you have to do!\n\nConsequently, South London GPs all use EMIS except for one maverick who is trialling Medicus!\n\nThis isn’t how it should work!\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nHow we doing? Any questions so far?\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nA quick plug for good sources of information: if you are interested in this stuff too, I highly recommend Dr. Betton’s book “Towards a digital ecology”, which surfaces the many challenges that software projects in the NHS face.\n\nAnd 6b.health — they just keep publishing really useful open data on IT systems the NHS uses today.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nNext up, what is blocking progress on interoperability!\n\nI’m going to summarise some themes that came up in interviews.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nPolitical Pressure\n\nThe centre feels pressured to deliver efficiency improvements ASAP.\n\nWorking with EPR vendors to add an API takes over 2 years to get it deployed in enough trusts to show any improvements.\n\nBespoke work to translate between whatever APIs are already there delivers small improvements quickly.\n\n_Whack-a-mole interop. Case-by-case. Expensive. Politically viable._\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nOrganisational churn!\n\nI’m not gonna narrate the blow-by-blow… but it's a lot. In England there has been a significant org change roughly every 2 years.\n\nDigital interop work at scale requires steady focus over a decade! This reinforces a short-term focus: work that can be completed in less than a year stands a greater chance of getting done.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nPriorities\n\nHospitals prioritise local needs first; interop with other sites will never be their top priority.\n\nICSs should be pushing cross-site interop. Do they have the resources, support, and people to drive it? (I don't know yet, but the implication is no… please tell me if you know more here).\n\nCoercing all GPs to use the same EPR is not the way.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nSo what work is happening?\n\nI’m going to share some ideas from the digital transformation experts.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nDavid Eaves discusses patterns that we see in large-scale digital transformation efforts.\n\nThere's “Come in high”: where you start with the user-facing part and work down. Get in between the user and the current mess, show value to the public quickly. GDS started here with gov.uk — they built a common publishing platform for all gov services to present themselves to citizens.\n\nOr start with one end-to-end service, tackling everything from the UI to the data layer for a specific user need.\n\nOr build out fundamental components first, like identity and payment systems, that you then reuse to build user-facing services. India’s national DPI stack started here with the Aadhaar digital ID scheme.\n\nOr you can “Come in low”: start with the data layer and build up. Estonia’s X-Road is an example of this. They focused on getting existing data out of the silos.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nTo visualise this, I’m gonna reuse open-source components:\n- A slide from the digital public infrastructure expert David Eaves!\n- With an openly licensed image created by digital government expert Richard Pope!\n\nBut let’s update it for the NHS!\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nTaa-daa!\n\nHere, the NHS App is a service that represents the “come in high” strategy. It hides the current complexity from the users behind a uniform user interface you control, while we work on upgrading the old plumbing that feeds it. It creates a focal point for interoperability work — all new services should share data with the patient via the NHS App.\n\nMAVIS tackles a whole service end-to-end to ensure it works seamlessly for the users and the data gets to where it needs to be. Build enough of these and you have a digital platform!\n\nNHS Notify is a shared component that lifts a burden from all other services that adopt it, creating a more consistent experience for users.\n\nThe FDP represents the “Come in low” strategy: organise the data, and then build up from there. My assertion is we need a more radically interoperable strategy for the data layer, so let’s look at how the FDP works.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nI can talk about this a lot, but I’d summarise the strategy as “use the Palantir Foundry platform everywhere”.\n\nAs a plan, it acknowledges that changing things at every trust may take too long. So to speed things up, it leaves the data in trusts as it is:\n- It copies it up to the Foundry platform\n- Cleans it up in the Foundry platform\n- And provides access to it via the Foundry platform\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nBut it’s not an interoperable solution:\n- It's not using open formats\n- The governance of the Canonical Data Model isn’t open\n- It’s not using an open protocol to move the data\n- We are using a proprietary data collection agent to copy data up to Foundry\n- We can’t reuse that tool to send data elsewhere, like the new Health Data Research Service project\n- We can only access the data via Foundry\n\nSo we are back in that single-vendor mode, that looks like interop but isn’t.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nThe obvious challenge is what to do about the vendor lock-in.\n\nAs the amount of data in it grows, and hospitals update workflows to depend on Foundry for operational and clinical work:\n- We lack a credible exit\n- And end up in a weak negotiating position when the contract comes up for renewal\n\nIt also cements in the old EPRs in the trusts as well:\n- Once we have written the custom transforms for it, there is an incentive to keep the old one in place, otherwise we have to redo that work.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nWhat is happening elsewhere?\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nThe Catalonian national health service is also taking this “come in low” approach.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nThey call it “driving semantic coherence”. I’d summarise it as “fix the data at the source”.\n\nThey are 2 years into a 6-year plan to:\n- Upgrade the EPRs in every hospital\n- Store the data in an open format\n- Split the data store from the EPR app services (letting them change EPRs and A/B test them without harming the data)\n- Share access with other systems via open protocols\n\nThey also copy that data up to a central regional repository for resilience and to replicate it to other hospitals as needed. It’s moving the exact same data around in the same open data format to all locations, which avoids the degradation issue when moving between different EPR data models.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nSo they are moving to:\n- An open format\n- An open protocol\n- An ecosystem of vendors\n\nSome of those vendors include:\n- Better (Slovenia)\n- Vitagroup and EHRbase (Germany)\n- DIPS (Norway)\n- And more…\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nChallenge! Upgrading the EPRs in every hospital!\n\nThe plan is to start by getting:\n- The old EPRs to write to the new open format locally\n- Any new systems to integrate with the open format rather than the old EPR\n- When the contract expires: replace the EPR with one that uses the open format natively\n\nThe result they are aiming for is incremental improvement at the edge, or “semantic coherence”.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nWhat’s going on elsewhere? I need to dig deeper on these, but at a high level:\n\n- Australia: is moving to FHIR as its open protocol, and the Australian Clinical Data for Interoperability team are deciding the open formats to use.\n- Norway: is openEHR everywhere for the format and protocol.\n- India: is an interesting case. Its healthcare data solution is still TBD, but in general they are focused on building out national DPI components and open protocols everywhere, deciding the rules of the game at the national level but getting private companies to build implementations of those protocols.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nSo, what should we do?\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nKeep calm and open source, open format, and open protocol!\n\nThe DPSP should keep on building high-quality end-to-end services that solve a problem well. If you keep adding more services, you will end up with a digital “platform”, and the shared components like Notify make it easier to build more.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nBetter still if you find the open protocols we need that allow public and private teams to collaborate on building pieces of the puzzle that work together. Choose plug sockets and the data formats that let us plug in different solutions and A/B test them, in-situ, rather than locking us into their service, or capturing all the data.\n\nNotably, AWS kept on adding services. It now has hundreds and it is definitely a “platform” — millions of developers now build solutions on top of it. A nationally owned digital platform could allow public and private delivery of interoperable solutions, but that puts a lot of work on the NHS to build all the services.\n\nAWS also accidentally built a de-facto protocol with its S3 API. Now there are dozens of services and hundreds of tools that implement that API. It started as an API for a single service, as part of a platform, but has become a protocol that many systems understand.\n\nFor healthcare, we’ll need well-governed, open protocols that are multiplayer… and don’t assume that the FDP or Epic etc. will always be the thing that holds the data.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nWe need solutions that lead to a form of digital interoperability that is loosely coupled across a diverse ecosystem, not a single-vendor monoculture.\n\n</figcaption>\n</figure>\n<figure>\n\n<figcaption>\n\nFor me: I’m about to start digging into what is needed to coax the duopoly of EHR providers for GPs in the UK to use open data formats, and what would help open solutions compete in that market.\n\nIf you have any info on that, please share.\n\nIf you’ve spotted errors or have suggestions, please get in touch: oli@zilla.org.uk\n\nTAA DAA.\n\n</figcaption>\n</figure>\n\n---\n\n_Original Deck: docs.google.com_\n\n_Extracted via: github.com/olizilla/slides-out_\n\n_Published: 2026-05-28_",
  "title": "Talk: Digital Interoperability in the NHS"
}