How can we make best use of technology to support healthcare?

How can we plan a coherent strategy that delivers, with pace, safety and reliability, solutions to the problems we face now while being adaptable enough to adapt to what is likely to come in the future?

I want to discuss strategy.

While written for NHS Wales, I hope this has a broader appeal.

1. We need information technology for health and care

Health and social care are complex adaptive environments made up of many interdependent parts. They are usually the responsibility of multiple different organisations but ideally, they should all work in a coordinated way to support us all, the citizen in our health and care.

I truly believe that software is critical to the future of healthcare, in supporting both patients and health professionals in their respective roles. Current software usually does little but replace existing paper processes but we should be aiming to use software to transform our health services.

My blog post, May 2018 The value of software for healthcare

Information technology should be the foundation on which our health and care services run. We need to apply deep knowledge of the data, the systems and processes that are involved in those services in order to effectively design and build information technology services to underpin our efforts to support and improve health and social care.

So much of the routine and systematic processes of care, quality improvement and research could be enhanced by the appropriate use of technology.

For many industries, digital is the way that they now conduct their business. Digital technology offers scope to transform our services by making them safer, more efficient and better learning systems by making our work data-driven, whether for direct care of an individual patient, caring for groups of patients or working to research better ways of providing care.

We must stop thinking of information technology as a goal in itself and instead see it as a tool to support our wider ambitions.

2. We need a cohesive strategy

According to Richard Rumelt, a strategy has three core parts that he calls the “kernel”:

  • we must define the challenge
  • we must have a guiding policy
  • we must have coherent action

The decisions we make are about what to do, the broad principles as to how to do them and then ruthlessly acting to deliver, each action coordinated and building upon others iteratively.

We must delicately balance top-down centralisation and standardisation with bottom-up local need and innovation. As such, we must define a set of enduring broad guiding principles about how we will solve problems, likely mandated or recommended across our enterprise while permitting adaptable coherent action at a more local level to solve local problems while not running counter to the overall direction. A guiding policy “directs and constrains action without fully defining its content.”

We need to stubbornly defend and enforce our guiding policies but be flexible and adaptable on the actions that we take to meet our challenges. This is why my first action, as chair of the NHS Wales Technical Standards Board was to propose to our group that we adopt the GDS design principles; we agreed this in our June 2018 meeting.

3. Components and modularisation

We must recognise that different parts of our enterprise are not all the same and so it helps to break up our problems into smaller problems which can be solved independently from the whole. Likewise, we can see that those components can change at different rates depending on user needs.

Breaking up monolithic architectures and applications into components requires skill and experience but is an important part of improving reliability, testability and delivery across an enterprise. When components are tightly coupled then it becomes increasingly difficult to make changes, not only because changes have unpredictable side-effects but because teams need to constantly check with others in order to make progress. I have given a specific example in the footnotes.1

When you break up our healthcare enterprise in Wales, we can see three broad categories of component:

  • some have already well-established solutions and need to focus on operational efficiency, metrics and analytics
  • some have to take what has been proven to work and improve and scale those solutions in order to deliver working products that are safe and reliable
  • some have to take user need and experiment and explore the best way of solving those needs.

You will recognise these three categories as Simon Wardley’s “Town planners”, “Settlers” and “Pioneers”.

Our healthcare information technology strategy must explicitly recognise change and adaptability. One insight, from a healthcare perspective, is that different things change at different speeds and that, given the legal and regulatory aspects of our work in healthcare, data are the bedrock from which we can build. Those data should be structured and clinically meaningful. Conversely, we should regard the tools (applications) with which we interact with those data as much more ephemeral and driven by clinical and business workflow.

A portal-centric approach has, in my opinion, created years of technical debt. We must work immediately to stop this approach and instead build an open, standards-based platform.

4. Let’s map

The value-stream is a flow-chart helpful in illustrating, analysing and improving our delivery of solutions to problems.

This is what we have in Wales:

Maps System Current Value Chain

The vertical axis gives a broad indication of visibility, reflecting that users have needs and that they are supported by visible components of our architecture which themselves are supported by less visible pieces of infrastructure.

It looks a bit complicated doesn’t it?

At the top of the value chain, we have our users and some of their needs. The important points are:

  • Patients and caregivers are considered as well as professionals, reflecting our focus on the citizen and their interactions with health services. We should see digital as a way of transforming health services.
  • The list of user needs is incomplete but I hope illustrative and useful as-is.
  • There are already items of user need from this limited list not met by the architecture as-is, particularly in relation to patients and their caregivers.
  • Trying to integrate multiple applications each with their own storage and structure of data is really complicated and the complexity increases exponentially when we want to add new functionality.
  • I have omitted many important projects such as the Welsh Cancer system, CANISC.
  • I haven’t even included newer projects like e-Observations and flow, recording pulse, blood pressure etc. on mobile devices to identify the deteriorating patient - functionality of high benefit to patients and professionals.
  • I haven’t included the interoperability need with other enterprises, such as cross-border transfers of care with England (particularly important for North Wales and specialist services) or social care.
  • Patients and caregivers have extremely limited functionality presently; they can use a product called “My Health Online” which has failed to gain traction and there is pilot of PatientsKnowBest in Abertawe Bro Morgannwg. Renal patients can also see their own results via PatientView

Much of the complexity seems inherent in healthcare, in which there has traditionally been a cycle of procurement of “systems” or “products” which must be integrated into the wider enterprise. Fortunately, we can make decisions now that can mitigate this complexity. We should always aim for simplicity.

We have multiple local health boards, multiple patient administrative systems (PAS), most of which use the same product but are configured differently and do not support cross-PAS workflows, and multiple instances of a single “portal” (WCP) which are linked to the local PAS so show administrative data only from that health board. This means it is possible for me to login to WCP, a national product, in Cardiff and see that a patient is alive, and at the same time login to the same application in Cwm Taf and see that a patient has died. Similarly, as I sat in clinic yesterday, I could see a list of upcoming appointments for Cwm Taf only, and not for any other health board. We do not have a single patient record but instead multiple instances of multiple applications giving different views of different data. In short, we have a problem.

5. Evolution

We can help ourselves understand our architecture by adding an “evolution” dimension to our value chain:

Maps System Current Map

The horizontal axis is a broad indication of the level of evolution of a component. If you are unfamiliar with Wardley mapping, then I suggest you read Simon Wardley’s mapping book. I am a novice at this - these are my first maps and would value your comments. Power is a commodity; it is fungible - it doesn’t matter who provides electricity. The laboratory information management software (LIMS) from Intersystems is a product, bought off-the-shelf and integrated with the wider enterprise via another off-the-shelf product, the enterprise service bus providing a messaging fabric. Custom-built software and components such as our data centres

We now see that we are using several off-the-shelf components - such as GP systems, emergency unit systems, laboratory systems etc. in conjunction with several custom-built applications and services.

The benefit of this type of map is that it helps us understand the options available to us. It also forces us to reconsider our architectural decisions and start to think about whether we have actually made the right decisions about the type of components we use. I think it is obvious from this map that focusing on products and projects is creating technical debt and making it more difficult to deliver solutions to end-users.

Likewise, we see that we are building in-house some components that, with a basic knowledge of the commercial market, we could instead buy off-the-shelf. Can we justify, for example, running two data centres and building custom software that is already available elsewhere?

There are some in Wales who think that it is right to adopt a “portal” based approach, but this map clearly shows how that approach is wrong.

  • The map shows how professionals already use multiple software applications; we know the current portal cannot replace that functionality in any timely fashion.
  • The map shows the difficulties inherent in trying to integrate multiple applications without an underlying single patient record. Many of the reliability and data inconsistency problems result from a lack of focus on that record
  • There has been a historic focus on bespoke point-to-point integration with proprietary APIs that then become difficult to manage and impossible to change for fear of breaking another integration somewhere else.
  • We are spending time and resources on developing the things that others can do, and failing to build the things only Wales can build.
  • Our portal is a single code-base providing user-facing functionality (user interface), business logic and tightly-coupled bespoke interfaces to services that are usually not made available to any other application. This fails to recognise that different components can be developed at different speeds with different methodologies.
  • Instead, we need to understand that different components are subject to different rules - so that components on the left of our diagram should be built in an agile-way, with rapid iterations and significant user engagement. Components to the right are commodities or components with well developed solutions that can be bought or rented. When a component can be provided as a commodity, we should not be developing it in-house without very good reason. Our architecture needs to reflect these differences. As such, it makes more sense to create a portal using components of a wider platform than a monolithic application.

Adapting to change

These maps also help us to understand how we are positioned to take advantage of new innovation and changing need. For example, we increasingly see adoption of cloud-computing, in which data centres become a commodity onto which computing power can be provided. We see an increasing marketplace of cloud-based functions, software code run on demand usually on a pay-as-you-go model, providing both core and specialist computing functionality such as data storage, speech-to-text and text-to-speech services, translation services etc.

I predict a marketplace of discrete computing services tailored for healthcare provision. Such services will make use of open industry standards to decouple code from the data on which they operate and offer increasingly valuable functionality such as clinical decision support.

Likewise, patients and caregivers now expect to be able to interact with their health and care services by using technology. Part of digital inclusion is ensuring that multiple channels of interaction are possible, designed to suit different people. We see Apple rapidly bringing clinical data from multiple hospital sites in the United States to patient’s own devices via their Health app and the use of HL7 FHIR standard.

In addition, we can see that we will be wanting to evaluate and make use of machine learning within our healthcare systems very soon. We need to build systems that permit the safe deployment and evaluation of such systems and a much of that work will involve plumbing together data pipelines safely and securely, subject to patient consent and an option to opt-out.

Can we add all of these to our map?

Maps System Future Broken Map

As you can see, the architecture lacks a cohesive design requiring multiple bespoke end-to-end integrations between systems.

Think of functional services not products

We should instead be thinking of discrete, functional logical services which can be built and run independently or semi-independently that, together form part a platform.

One of our core design principles is to do the hard work to make things easy. This means rethinking our map. It is still complicated, but our user-facing applications like mobile applications and a modern rewritten portal can be developed in an agile way while using platform components that are either a built in-house, bought or rented or, over time, a commodity.

Importantly, we don’t expect client applications to understand the nuances of our local enterprise architecture, but instead provide a managed API gateway, offering simplifying access to a logical single patient record.

Maps System Future Logical Map

Indeed, one can see that many of these components will increasingly become a commodity. I’ve shown this with the “data repositories” component, which spans the “product” and “commodity” evolutionary sectors.

6. Delivery

This work informs our work on the technical standards we need to prioritise in order to deliver a modern, open, standards-based platform for Wales providing a single patient record for use by a variety of user-facing applications. Such applications may be a commodity or custom-built but are ephemeral and lightweight, with business logic delegated to the platform.

As such, we need to reconfigure the way we work in Wales and create:

  • an applications group who have responsibility for delivering lightweight applications to solve user need. These teams should work in an agile-fashion and share code and frameworks, releasing their work as open-source, building libraries and components that, together with the open platform, provide a toolbox of functionality for building the next generation of healthcare applications.
  • a platforms group made up of teams, each of which are responsible for developing, testing and deploying modular components of the wider platform according to our mandated technical standards and design principles. These teams should deliver components which are continuous deployed into multiple production-like test environments allowing automated testing of both operation and performance. Similarly, commodity computing power, such as that provided by commodity cloud providers like Amazon, Google and Microsoft, should be available on-demand with infrastructure-as-code, allowing teams to easily build, test and deploy without recourse to external teams. These principles underpin the “DevOps” movement.
  • an architectural standards and strategy board, including both technical and information standards boards for operational and analytics use and defining the top-down broad principles for use across NHS Wales and its partners.

The Welsh digital ecosystem project is critically dependent on an open platform. We can build that open platform using a lot of the good work already done in Wales. We have a terrific opportunity to create a health and care enterprise fit for the 21st Century for the citizens of Wales.

And what might our map look like in the future? Here the platform and its components are evolving to become a commodity, but we can see that our work will be in developing the best user-facing components, focused on solving workflow and user need while taking advantage of new advances in machine learning, artificial intelligence and decision support. Who thinks we’ll be running our own data centres then?

Maps System Future Future Simple Map

Mark

Acronyms / descriptions

  • API - application programming interface
  • ESB - enterprise service bus. Messaging fabric carrying HL7 v2 messages between producers and listeners. Should allow decoupled development but caveat emptor! Continue to use for some uses but move to an API-based approach for most modern applications.
  • ESR - electronic staff record
  • NIIAS - “National Intelligent Integrated Audit Service” - currently used at the application-level. Needs to be embedded at the API-layer (platform) instead
  • OAUTH2 - authentication framework
  • PAS - patient administration systems
  • WCP - Welsh Clinical Portal - a currently monolithic application providing a portal, one instance per health board coupled to the local PAS.
  • WCRS - Welsh Care Records Service - a document repository and search service

Footnotes

1: Modularisation of architecture is important for reliability and pace of delivery. When components are loosely-coupled, the interactions between them are limited and it becomes possible to develop them independently, in parallel. A team can completely change the underlying implementation or even whether the service runs on-premises or in the cloud. Conversely, a tightly-coupled architecture makes change difficult.

An example in Wales is a service like the Welsh Care Records Service (WCRS) which provides a non-standard application programming interface to store and retrieve documents and the application Welsh Clinical Portal (WCP) uses that API, together with an associated instance of Apache Solr in order to provide search. In essence, these are tightly coupled because if the team working on WCRS wish to change the way the Solr index is built, they must link very closely with those building the user-facing application, WCP. It also means other parties cannot, independently, make use of WCRS to implement functionality in their systems at the application programming interface (API)-level.

Wcrs Architecture

This is shown in this schematic, where “external” services such as document repositories in the health boards publish documents into WCRS but the only way to view and search documents is via a portal application, WCP. There are less than a handful of releases of WCP per year. Is it any wonder that users across Wales are dissatisfied with the pace of change?