This is part three of a three-part series on why and how we should be building an open digital health platform in Wales.
Part one was a high-level overview of how standards and interoperability are critical in building a digital ecosystem. Part two assessed our current messaging-based architecture and highlighted the benefits of an API-first enterprise architecture together with the new technologies that have facilitated the move to cloud computing in other industries. This part ties together these strands into a manifesto for phase 1 of building our open platform.
We need to change what we are doing in Wales. We have two important reports that have criticised how healthcare information technology has been delivered - the Welsh Audit Office report and the Parliamentary Review.
We must ask hard questions about what we should do about the issues raised in the audit report including defects in governance and leadership, lack of delivery and concerns about the quality of information technology systems that are delivered.
I believe that the only logical response to the Welsh Audit Office report is to re-imagine the relationship between the NHS Wales Informatics Service (NWIS) and the health boards. Such a re-imagining requires us to stop ignoring the, in my view, currently incoherent set of responsibilities and divisions of labour that exist within Wales.
from my blog post, “Focus focus focus”
In my view, we need to focus our energy on creating an open platform onto which the next generation of applications, created internally and externally, can run.
The Parliamentary Review of Health and Social Care report, published in January 2018 highlights the need for a seamless health and care system in Wales, centred around the citizen irrespective of where they live with the avoidance of creating artificial barriers between services and organisations.
from my blog post, The challenges we face in delivering the vision
Likewise, our services must re-focus on our citizens to transform healthcare with digital tools enabling that transformation. As I have written before, we need to enable innovation and invert the current paradox we have in command and control of our software systems
It is important to recognise the obstacles in our way, some of them non-technical:
Strategies focus resources, energy, and attention on some objectives rather than others. Unless collective ruin is imminent, a change in strategy will make some people worse off. Hence there will be powerful forces opposed to almost any change in strategy.
When organisations are unable to make new strategies - when people evade the work of choosing among different paths into the future - then you get vague mom-and-apple-pie goals that everyone can agree on. Such goals are direct evidence of leadership’s insufficient will or political power to make or enforce hard choices. Put differently, universal buy-in usually signals the absence of choice.
“Good Strategy, Bad strategy” by Richard Rumelt.
We need to make use of our existing good work and build on that. We cannot afford to rip-and-replace, but plan, pragmatically and carefully, taking advantage of the new digital technologies available to us, to transform our health system.
We must build an evolutionary architecture
An evolutionary architecture is one that supports change, recognising we need, both figuratively and literally, platform on which we can build solutions to meet our current and future needs.
The principles to consider are:
- Plan for change at the outset
- Build a cohesive vision
- Create modular services cared for by cross-functional teams
1. Plan for change at the outset
The most appropriate way to build an evolutionary architecture is to ensure that support for evolutionary change is built-in to your designs at the outset. This means recognising the components that are likely to change and those that are not. On many occasions, I have stressed the need for clinical modelling in which we think carefully about how to create model data:
A model is an abstraction of the real-world distilling knowledge into core concepts and processes. A model is a careful balance between complexity and over-simplification with models that are too complex model providing brittle abstractions which are poorly generalisable and models that are too simple model not supporting all of the demands placed upon it in real-life clinical scenarios.
This, essentially, underpins a data-driven approach in we consider data and the computing services that operate on those data as our platform onto which ephemeral and lightweight applications can be built.
It also means that we leverage what we have already built in Wales and plan to build increasingly sophisticated functionality over time. As a result, we turn the existing ESB-based architecture into a more modern, API-based architecture in which data and services are made available to both internal and external users.
2. Build a cohesive vision
Likewise, the components which underpin our platform must be cohesive. Cohesion means that the plan and the components that make up delivery of that plan form a cohesive and integrated plan.
A coherent plan to deliver the [Informed Health and Care strategy] needs more than a list of disconnected and incompatible goals but instead a clear understanding of what needs to be done and what doesn’t need to be done; we must know when to say “no”. Instead, we focus our limited resources on specific tangible actions and make some difficult decisions to prune areas of work that do not support delivery of the wider vision. […] As such, we need a coordinated all-Wales approach that permits all stakeholders to work cooperatively and collaboratively with clear lines of responsibility and governance. We need to re-organise our approach to healthcare information technology taking into account the steps needed to deliver the vision, the principles of enterprise architectural design, modern information standards and interoperability, modern quality improvement methodology and user-centred design.
by me, Focus focus focus
We need to build consensus around a cohesive plan to deliver the vision in the Informed Health and Care Strategy. This doesn’t mean getting everyone to agree, but requires political drive to make difficult decisions about what we can do with limited resources, taking into account our own strengths and weaknesses as public sector organisations.
3. Create modular services cared for by cross-functional teams
I suggest that you read the very helpful Apperta documents on “open platforms”. In it, they give a high-level overview of the typical ‘services’ which are required from an open platform. They suggest:
- Identity assurance
- Data repositories
- Record location
- Resource discovery and scheduling
- Knowledge sources
- Legacy connectors
These are a useful starting point, but the most helpful chapters are 3 and 4 on why an open platform is a good idea for healthcare and their proposed definition of an open platform.
In Wales, I would argue that we need a phased approach to make the best use of the good work already done. This could include in phase 1:
- User identity services
- Wrap existing “NADEX” Windows (Kerberos) domain controllers into an OAUTH2 service that be used to authenticate and authorise healthcare users. Later phases should include federation of other authentication providers in non-health domains such as social care.
- Citizen identity and delegation. We need to evaluate different options including GOV.UK VERIFY
- Electronic staff record integration that, together with the user directory from NADEX, is exposed as a FHIR Practitioner resource.
- Patient identity services
- Wrap existing patient administration systems across Wales, the enterprise master patient index and the Welsh Demographic Service into a simple HL7 FHIR Patient resource
- Results reporting and requesting services
- Wrap existing vendor neutral archive of results from the national laboratory information management system as a FHIR Diagnostic report resource or Imaging study resource.
- Create new requesting service based on HL7 FHIR ProcedureRequest resource which acts as a concierge handling and delegating multiple different types of request to our existing underlying laboratory and radiology systems.
- New e-Obs repository to include HL7 FHIR Observation resource permitting storage and retrieval of observations such as pulse, blood pressure, temperature and weight and height.
- Appointments and scheduling including providing federated read-only views initially across our multiple PAS and radiology services to provide Episode of care resources, Clinical encounters and Appointments. Such a service could be used by professionals and citizens alike to see upcoming appointments for example.
- A document repository, wrapping our existing national document repository (WCRS) but adding a more sophisticated metadata model to expose data as a HL7 FHIR Document resource.
- Reference data services including the UK-wide organisational data services (ODS) to create FHIR endpoints including Organisation, Service and Location
- Centralised logging and audit services, exposing our existing national audit service as a FHIR Audit event resource.
These services are shown in schematic form here, from my data-driven presentation:
These would form a bare-bones set of services that could be used by a new generation of applications providing the right information for users at the right time, whether professional, citizen or their delegate. In line with an evolutionary approach, we need to recognise the challenges ahead including:
- A robust approach to citizen consent in order to control how and why their health data is shared.
- We need to start thinking about how “API gateways” could be used across our health enterprise.
- To work with industry on how we can enable an ecosystem of healthcare software and real-time analytics that permit the safe use of independent software modules within the wider ecosystem. We probably need something much like the Amazon AWS Serverless Application Model I have referenced previously when discussing “Serverless in healthcare”. For example, how can we safely make use of a cloud-hosted service that is the result of machine learning that can tell us whether a chest x-ray is normal or abnormal? How can we make use of a new acute kidney injury algorithm? What are the technical and legal requirements we must solve to do that?
- To work to change our governance and funding models.
On the latter point, we must recognise Conway’s Law:
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”
Conway, Melvin E. (April 1968), “How do Committees Invent?”, Datamation, 14 (5): 28–31
We must, therefore, change our governance structures in tandem with changing our software architecture.