In part one, I highlighted four drivers that will result in creative destruction in the healthcare IT industry:

The first was the recognition that software and data are critical enablers of clinical quality improvement, service transformation and advancing our knowledge (research).

The second was that the best way to build healthcare software is to adopt the behaviours, processes and culture from the most highly productive technology companies. This means adopting quality improvement and research methodologies to develop, test and deploy the software that use to improve our clinical quality, service and research endeavours.

I covered these two first points in more detail in part two.

The third was the importance of separating data storage and transmission from the software operating on those data, with a shared domain language uniting multi-disciplinary cross-functional, semi-autonomous teams creating discrete, carefully bounded components with loose coupling with other components.

The fourth was the recognition of a transformation in software engineering practices with the increasing adoption of cloud and serverless technologies, permitting the development and commodification of components of what will become, a distributed and patient-centred logical electronic health record. The end result? A variety of interoperable applications, both clinical and administrative indeed, focused on workflow and usually task-orientated, making use of that shared health platform.

In this post, I delve into the importance of software architecture and the use of standards in designing healthcare software systems fit for the 21st Century.

Architecture and standards

As our efforts to transform health services are critically dependent on technology, we need to change our approach to health information technology projects to maximise safety, quality, productivity and pace using the best evidence-based practices. This means building in continuous improvement methodologies to ensure we keep on improving our approach.

So, how can create an environment which makes it easy and safe to develop, test, evaluate and deploy software for use in healthcare?

In “Lean Healthcare”, I talked about the quality improvement methodologies and process changes that can be used to develop software faster and more effectively.

One of the important conclusions is the benefit of small cross-functional teams. Such teams must be able to work independently, aligned to a wider strategy, given the right tools and responsibility to get their work done and most importantly, work on discrete components by breaking down work into smaller, less risky units that can evolve independently with only loose-coupling with other components. We modularise our work and limit the interactions between those modules to well-defined publicly documented contracts. It is reported that Jeff Bezos, founder and CEO of Amazon said:

“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”

Jeff Bezos quoted here

Setting this kind of broad architectural principle means a lot and when you write down this and other guiding principles, and they are actionable and meaningful, they drive a change in behaviour and change your culture.

Action 1: We need to be explicit in the broad principles we will use in our architecture and culture in Wales.

Cross-functional teams and delivery

What do I mean by a cross-functional team? A cross-functional team brings together people with different expertise to work together towards a common goal. I want to convince you that we need to modularise our technical architecture in Wales and as a result, we need to modularise our teams.

Usually, it is easy to see software development as a process of generating value akin to a factory assembly line, in which a clinical system is designed, built, tested and then deployed to the end-customer. This is what is called a “value stream”.

It is easy to fall into the trap, usually brought about by naivety mixed with arrogance, that we can define the specifications of what is needed from our software, build it, and then deploy into clinical environments and immediately realise that value, sitting back to announce “our work is done”. As a result, you will have a design team, a development team, a testing team and a deployment (operations) team, and at each step, the “work” is passed from one team to another. When an incident occurs, and they do, perhaps a patient safety team will swing into action.

Is that the right way to structure and operate your organisation?

A cross-functional team brings together those experts into the right sized teams, in which communication between members is easy, there is a shared goal, usually focused on delivery. Members of different functional teams are brought together, for possibly a fixed duration, in order to deliver a goal bringing together design, development, testing, evaluation and deployment and speeding up the lifecycle between these processes so that we aim for continuous integration and continuous delivery.

Action 2: We need to modularise our architecture and modularise our teams, creating cross-functional teams whose task is to deliver discrete components of our architecture which are loosely-coupled from one another, with a focus on automated unit and end-to-end integration testing and continuous delivery.

Creative destruction & ecosystems-thinking

So we want to develop a distributed, standards-driven platform that provides the building blocks with which to build the next generation of electronic health applications?

Notice I don’t say “electronic health record software”, because I want to convince you that:

Data persistence and transfer must be considered separately to the applications and software services that operate upon those data.
We need multiple applications giving different views and bespoke utility using the same data. A single logical record of patient information.^a

The benefits of an open ecosystem extend beyond only a new marketplace for health applications.

Interestingly, another definition of a “platform” is a set of services that bring together users and providers to form a multisided market. Is it possible then to take our “open platform” and start to think of a future in which we have products and services that actually do enable a re-imagining of healthcare provision to bring together patients, carers, health professionals, commissioners, analytics, researchers and all other stakeholders in a safe and secure manner?

My disruptive influences in healthcare blog post

Indeed, a new ecosystem permits us to step-back and re-imagine our healthcare services. When you have physical notes, the team looking after your chronic health conditions or your primary care physician need to be physically located near those notes and near to you.

It used to be the same with online banking in which your local branch held your account. We see the artefact of this configuration even today with account numbers and sort-codes tracking the bank and branch at which your bank account is held. Digital technology was an important tool in re-imagining how we interact with our banks; for them, digital is now the way of doing business.

Can we do the same for healthcare?

Action 3: We need to think ‘open’ and build software services and data repositories that are usable by both internal and external developers to create value and innovation; ecosystems-thinking. We need to “eat our own dog food” and ensure external developers are treated the same as internal development teams.

Mark

Creative 3/3: Ecosystems and the platform

Architecture and standards

Cross-functional teams and delivery

Creative destruction & ecosystems-thinking

Posts in this series

Further reading