The following blog post is from a debate that we will have at the Welsh Clinical Informatics Council tomorrow, 16th March 2017, in relation to the current healthcare IT strategy in Wales, which has at its core, the mantra ‘Once for Wales’. This has been variously interpreted, and historically has been used to focus on a single product, such as a single patient administration system for each of the health boards in Wales. I should like to re-define this to focus on the formation of a “platform” in Wales, built on open standards and interoperability. It is essentially a summary of my larger domain-driven design clinical information system document.

Once for Wales

So what does “Once for Wales” mean to me?

To answer that question, we have to decide what we’re trying to do and what are our priorities.

To that, I would answer: to valuably support the care of patients within NHS Wales.

The most important priority is the patient. It is not technology, it is not politics. We need to focus on the patient, and to support health professionals and those working in the NHS in looking after the patient.

How then do we support health professionals and managers in their quest to effectively look after the patients under their care?

1. Plan for innovation

I think the most important fact to recognise is that I don’t have all of the answers. I know some of them, but many remain unsolved. Before explaining what I do know, I’d rather talk about what I don’t know, and the importance of this. We need to build an infrastructure that explicitly recognises that we don’t have all of the answers, and therefore must support innovation. Such innovation may simply be incremental improvement of existing technology, but also must cope with and embrace the introduction of transformative and disruptive technologies.

The logical conclusion from this is that we need to build solutions within NHS Wales that allow innovation to flourish, but in an environment that is safe and meets the range of regulations in which we all must work.

2. Build a service-orientated architecture

Many people are currently interpreting “Once for Wales” as only about national systems, one portal, one emergency unit system, one patient administration system. Indeed, currently when I ask colleagues about what NWIS is doing, they know only about the “Welsh Clinical Portal” product, and little else, and I am afraid, even with all of the improvements, it is usually accompanied by a sigh and a roll of the eyes, as their experience of this product has been difficult.

NWIS has done a fantastic job on the most difficult of tasks, implementing many interoperable core services than underpin much of what exists within Welsh Clinical Portal. Some of the most difficult work has been not technical, but instead has been about managing change across multiple organisations, such as the harmonisation of laboratory systems across Wales. However, because that work and those services are not currently exposed, except to Welsh Clinical Portal, few know about these successes. In my opinion, NWIS has not done enough to broadcast those successes. The Welsh Results Reports Service, integrating results from laboratories and radiology across Wales is a terrific accomplishment and the teams should be congratulated.

My second conclusion is that, much like Amazon, NWIS should have a strong focus on a service-orientated architecture, and critically, those services must be made available to all within NHS Wales as well as permitted third-parties.¹

From an engineering perspective, this makes a lot of sense. It is almost always the case that when building complex solutions to real-life problems, no-one person can conceive of all of the problems in one go. The natural solution to such complexity is to break-down a problem into manageable chunks. These chunks, much like “lego bricks”, can be joined together to form something greater than the sum of the parts. Importantly, it is more likely that we can vouch that a system is deterministic. This means that the behaviour of a system is predictable. We’ve seen the consequences of non-deterministic systems when we heard about laboratory results being misreported to general practitioners. Healthcare information technology should be deterministic.

It is really difficult to know a system is doing what it should be doing when it is really complicated, so breaking systems into smaller components that do one or two things really well makes a lot of sense. It also means we can take those components and test them systematically so that we can prove that they are doing what we think they should be doing.

Importantly, it is at this service-layer that a mantra of “Once for Wales” really makes sense. It doesn’t make sense to manage user authentication and authorisation in multiple services. We want single-sign-on for users, and this process should be orchestrated by a national service that handles this for multiple applications. It may be that this service federates for a range of systems across health and social care, but nationally, it makes sense to be “Once for Wales”.

3. An extensible platform for NHS Wales

It is therefore not difficult to imagine the core services that are truly “Once for Wales”. User authentication, laboratory and radiology results, a document repository, a reference data service, a clinical data repository. In fact, all but the last of these services exist and when combined together, form a platform on which clinical applications can sit.

It is important to note that services can “wrap” or federate other services to provide additional functionality. A service to provide laboratory results can connect to multiple laboratory systems and provide a unified view. Such integration does not require all laboratories to use the same product, but only expose their data in a standardised way with harmonisation of meaning, so that a full blood count in one system is equivalent to a full blood count in another system. There is a growing momentum towards a standards-based approach internationally.

Similarly, the fact that the same patient administrative system is in use in multiple organisations does not magically mean that we can track the care of a patient on a single pathway that spans those organisations. The logical conclusion is that it is much more important to think about high-level clinical requirements than focus on products, and that services can be combined together to form an extensible platform.

4. Focus on standards and contracts

I’ve previously quipped that I don’t care what system is used in the emergency department. That isn’t quite true, but I’m not an expert on the workflows and processes that occur in an emergency unit. What I am interested in is knowing how many of my patients attend the emergency unit, how patients at the front-door flow through my hospital and which of them I need to see when I am on-call. I might want to set-up some automatic notification when one of my patients with motor neurone disease turns up in the department.

As a relative outsider, it is logical for me to think about emergency unit systems as a black-box. I don’t need to see how it is implemented, what magic goes on under the lid, but I do need a report telling me what has happened to the patient. For me therefore, a “Once for Wales” approach means focusing on a “Once for Wales” contract - a contract in which we give the high-level functional requirements and expect organisations and third-parties to meet those contracts. Those contracts are a combination of clinical requirements (for instance, notifications) and technical - so that we know it will interoperate.

Similarly, the same could be said for specialty-specific systems like nephrology or ophthalmology.

Now it may make sense financially to procure a single EU product for use across Wales, it may not. As a member of council, I’m not sure I should have any say at all. To me, the EU system needs to interoperate with the workflow and processes within that organisation, and that is pretty much none of my business. All I want is for it to meet the requirements firstly of the EU staff, secondly, the organisation and its management, and thirdly, everyone else who looks after that patient.

A focus on a single product stops us thinking about what really matters across NHS Wales. We should be discussing what is in that contract for any EU system and how it interoperates with our national platform. It is the contract that is “Once for Wales”, what data standards must be used and not the details of the implementation. It avoids a procurement like WCCIS, in which we still don’t have a handle on how this project will interoperate with the rest of our architecture.

Such an approach then permits local innovation and for local organisations to work at their own pace and priorities. Our health boards are under a statutory obligation to provide healthcare for their populations. We must avoid a “my way or the highway” approach, but allow local developments in order to solve local problems that can work in harmony with the national platform. Importantly, we must then create an environment where we can pick up those local innovations and easily apply them in different organisations preventing wasteful duplication of effort, or the creation of functional silos which cannot interoperate with any other system.

Conclusions

I therefore commend to council that we re-imagine “Once for Wales” to focus on a “platform” for Wales, a set of contracts, data standards and integration services. Welsh Clinical Portal should be but one window into our national platform. We need a national architecture board in which we define those core national services, define those data standards and evaluate products to ensure that are truly interoperable with our platform. The final piece of “Once for Wales” should be a plan to develop a workforce of informatics staff, clinical and technical, who can make healthcare IT in Wales the best in the world.

Thank you,

Mark Wardle

Footnotes

1: Jeff Bezos did the same for Amazon in 2002, with the following commandments:

All teams will henceforth expose their data and functionality through service interfaces.
Teams must communicate with each other through these interfaces.
There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
It doesn’t matter what technology they use.
All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.