We should use information technology to better deliver our broad health and care objectives.

That means using information technology to support, improve, transform and re-imagine the delivery of health care; that means we must move away from delegating information technology to a separate department or even, as we do in Wales, a separate organisation.

Most modern enterprises have recognised the integral role information technology plays in operating their business. A failure in technology is a failure of business. That means services that have responsibility for delivering health and care objectives need to be responsible for the acquisition and development of technology used to support their work in delivering and improving care.

Alignment of information technology with business objectives requires a careful balance between top-down standardisation and enabling local, ‘bottom-up’ innovation. Standardisation, executed badly, creates fragility and inertia but when done well it creates an environment in which we can deliver technology at pace because we can decouple our developer teams and let them work independently. We know that pace of work is inversely proportional to the number of people who need to be involved in decisions.

We need to re-imagine our organisational structures, governance and architecture to reflect modern information technology best practice. This means understanding the challenges we face:

we work in complex, constantly changing, heterogeneous clinical environments across Wales
we need a single patient record with all of our user-facing applications giving a view on the same information.
we need to improve productivity; that means delivering technology at pace to meet the demands of the service
we need to be able to make changes while adhering to legal, regulatory, safety and ethical standards
we need to share common national services avoiding wasteful duplication
we need to permit local innovation and learning, particularly when we recognise that there is no already established best way of delivering business value, and rapidly scale success across organisations in Wales
we need to understand that we have existing applications hosted nationally and locally, with health boards all at different levels of maturity, we want to harmonise but not suffocate.
both healthcare, and the design of software to support healthcare, must be data-driven.

We know that we are not meeting these challenges in Wales; the Welsh Audit Office report is damning in the failure of delivery.

What are our options?

There are three potential options for us:

Continue the status quo.
Buy an off-the-shelf electronic health record “mega-suite” from a large vendor and deploy across Wales, e.g. Cerner Millennium or Epic.
Change our strategy, creating an open health and care platform

I believe that there are substantial problems with information technology in healthcare in Wales including issues of governance, leadership, organisational structure and architecture. Is there anyone who thinks we can continue the status quo?

My favoured approach is to recognise that our technical architecture determines our organisational and governance structures in Wales, and that architecture needs to be designed for

improving developer productivity
supporting extremely high reliability as well as enabling testability, safety and performance
permitting the use of structured, meaningful clinical data for direct care, service management, quality improvement as well as clinical research

Fortunately, we can look at how other technology companies have achieved these goals.

An evolutionary architecture

An evolutionary architecture is one that can adapt to change. We must understand that our work in technology will never be complete and we will need to continually improve, adapting to changing clinical need and new technological advances.

One of the recognised characteristics of an evolutionary architecture is modularity, in which we break-up our enterprise into modules, each with a well defined and usually constrained purpose. Modern architecture usually focuses on modularity at the domain-level while more old-fashioned service-orientated architectures are partitioned at a technical-level.

NHS Wales currently uses the latter which means that end-to-end testing is very difficult and, in effect, one ends up with a distributed monolith and paradoxically makes change more difficult, the whole system less predictable and resilient. It might takes weeks to create developer or test environments that replicate live and it becomes difficult to keep those different environments synchronised.

Instead, domain-driven design recognises the need to modularise and align modules to meaningful constructs in the business domain; we recognise inherent partitions in functionality and then tightly define the interactions between those modules. In essence, we need a microservice based architecture.

Example platform services needed to support a modern electronic health record might be:

Patient demographic services, providing a single authoritative snapshot of demographic information about a single patient.
Scheduling services, providing an aggregated view across multiple administrative systems to provide scheduling across multiple organisations.
Staff identity services, providing canonical staff information, bringing together information information from the electronic staff record and national active directory
Clinical document repository, storing clinical documents and associated metadata
Results repository, storing laboratory and radiology results
Test requesting concierge service
Security (authentication/authorisation) and logging services
Clinical data repository

Scheduling services are a great example because they are needed to satisfy the vision from multiple workstreams of the Informed Health and Care strategy; patients and professionals need to be able to see and schedule appointments in order to deliver care more efficiently and more safely. At the moment, I login to Welsh Clinical Portal in Cwm Taf and see only Cwm Taf appointments, and login to Welsh Clinical Portal in Cardiff and see only Cardiff appointments. We have something wrong with our current architecture.

However, there has been much good work in Wales on some of these core services, but these services need to be resourced appropriately and recognised as key enablers for building the next generation of user-facing applications. That means prioritising the deliver of these discrete services. Importantly, those services need to adopt open standards and be well-defined, loosely-coupled, documented and permit federation. As discrete modules, it becomes possible for use to run automated tests so that we know how our computing services provide accurate results and perform under pressure.

Contracts: abstract computing services

One of the fundamental characteristics of an evolutionary architecture is that developers are able to work independently from one another, as long as they work within the defined contracts that document the functionality needed and how that module will interact with others.

Fundamentally, our modules create an abstractions of a computing service.

Abstraction is an important software engineering principle which means that developers do not need to be concerned with how a service or application is implemented, only that it meets the agreed contracts. This is powerful because it acts to decouple components meaning that they can be developed independently and in parallel, as long as they each work to the contracts specified.

In essence, the processes of simplification and abstraction mean reduce the interactions between discrete components within an architecture to a well-defined, constrained set of agreed contracts between parties.

Those contracts may be technical, defining how to interact at a technical level with the underlying services providing using that platform. Technical contracts usually define an application programming interface (API), but those must be supplemented by a range of legal and regulatory contracts defining how those services may be used and for what purposes. In addition, those contracts can define how the different teams might work with one another and provide assurances regarding performance and reliability. In essence, the contracts document obligations for all parties.

It is possible to ensure that parties are working appropriately to those contracts by the use of automated tests and fitness functions. Such an approach means that changes that break an agreed contract are recognised early in the development pipeline, rather than at a late stage. We should aim for an efficient flow of work from conception, development, testing, assurance to deployment, and we should question any step that delays or reverses that flow of work.

For example, in our scheduling example, the developer team simply needs to deliver an API, probably based on the HL7 FHIR Appointment resource. Our initial version could simply provide a read-only view and satisfy the request by sending out its own request to all of the multiple patient administrative systems in Wales, collect and aggregate the results and return a unified view. That might work, but we would ensure fitness functions would assess not only the data returned but the performance metrics. We might expect to get results within 100 milliseconds, and so the team might instead create a vendor-neutral scheduling repository which takes a feed of data from each patient administrative system and, essentially, caches the results for performance.

The important thing is that, from an architectural point of view, we don’t care. We set the specifications for that service and trust our team to work out how to deliver what we need, bringing together expertise from across organisations in Wales in order to safely deliver a service that meets our requirements. If the team improve the implementation, or create a new implementation, our client applications do not ever need to know.

Multiple services create a platform

A computing platform is the environment in which a piece of software is executed; they provide a range of software and data services that make it easier to develop applications.

For example, the Apple developer platform provides a range of sophisticated building blocks that permit developers to create applications for mobile devices. Similarly, there are core services and frameworks that developers can use for common operations such as data storage or processing. This means developers can focus on delivering value to their end-users, building on a foundation of different building blocks that factor out some of the complexity.

This approach means that applications become lightweight and often ephemeral, simply stitching together functionality from the underlying platform. A proprietary platform can lock developers into that platform, while open platforms, build using open standards can commoditise core computing functionality, foster innovation and create new marketplaces and ecosystems.

So we need to design our modules to work together to provide the building blocks of the next-generation of electronic health records, recognising that, when combined, those modules will provide a cohesive platform. That platform encwhile developed independently, those modules must be designed to work together to provide a platform

It is not difficult to see the range of discrete computing services that are needed to create a functional health and care platform, but this model needs a change in culture and change in the way that we think about information technology, moving away from purchasing applications towards a separation of data from the software that acts upon those data.

There has been some fantastic work in NHS Wales and there is a real appetite for cooperation and collaboration; we now need to work out how to take the next steps and build an open, standards-based computing platform for NHS Wales.

So what’s next?

We need a national platform group that will define the platform and the contractual obligations for each service, documenting the technical (API) interactions and other dependencies. This architectural design group will need to work closely with the technical and information standards boards.
We need multiple independent cross-functional teams each tasked with delivering discrete modular computing services that meet the standards defined by the national platform group. Those teams need to bring together developers with members of other teams, including security, operations, patient safety and assurance.
We need a national applications group that to build example national applications, like a national modular portal, that can be used by all but, importantly, permit the different modules to be stitched together by developers irrespective of their location.
We need to recognise that our platform services three categories of developer: those working for NHS Wales developing national applications, those working for NHS Wales developing local applications (that might end up being scaled out if successful), and those working for academia and commercial organisations as part of our ecosystem. All three should be treated equally, using the same APIs. We cannot have a situation where internal and external developers are treated differently, or that successful local innovation cannot be easily scaled to other regions.
Our organisational and governance structures need to reflect these changes and we need to adequately resource, on a recurring basis, the ongoing development and improvement of these core national services.

And what about a portal?

We do need a national portal. But our national strategy cannot be defined by a portal.

It makes little sense to duplicate portal functionality in different places, but each organisation needs a realistic convergence strategy that takes into account existing solutions and avoids long delays in providing functionality for our users. For example, we need to be able to embed portal functionality into emergency unit systems across Wales.

But we also need to ensure that our portal gives an accurate view of the single patient record; our focus must be on data. We cannot repeat the situation where different instances of portal provides the same view of different data. That means redesigning our national portal to be a lightweight, modular wrapper around national services; it too needs to use our national platform and provide common user-facing elements for use by all.

To move towards a modular portal, we will embrace the idea that we will stitch together components of the national platform, including components of that portal, to meet our user needs. I believe that, given the right architecture, we will see a natural convergence as it will be possible to rapidly scale solutions developed locally to other organisations, as those new developments should use those standardised APIs. We should aim for true application portability, collaboration and cooperation. At the moment, local developments are difficult to scale because there isn’t truly, an open standards-based platform.

If we cannot do this, then we should continue to consider procuring a mega-suite electronic health record system, because without change, we will be failing our staff and our patients in Wales.

Mark