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.

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 [, part two covers the importance of software in our efforts to transform clinical services and improve quality.]

Software and healthcare

“Software is eating the world.”

Marc Andreeson.

Every industry that is not bringing software to the core of their business will be disrupted.

Jeffrey Immelt, CEO and Chairman, General Electric, 2001-2017

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.

Our clinical quality improvement and service transformation endeavours must be supported by new technology, by software and data, to support our efforts to effect change and measure the outcomes of that change in a virtuous cycle of continuous improvement.

Such continuous improvement requires us to be able to rapidly develop, test, integrate and deploy software. That software could be hand-coded or be the product of machine learning; whatever the case, it needs to be developed, tested, integrated and deployed continuously monitored to ensure it works safely and reliably.

Are we confident that we have the right culture and architecture in order to do that, because if we don’t, won’t we need to transform our organisations, our culture and our technical architecture to support those needs?

In essence, we must recognise that our technology, quality improvement and research endeavours are best considered as related and mutually supportive:

Quality improvement relies on measurement, analysis and action and therefore most effectively supported by the provision of digital tools to those who wish to transform their services.

Likewise, development and deployment of technology should, itself, be subject to the same approach to quality improvement so that we develop, test, measure, analyse and deploy in the same virtuous cycle of continuous improvement.

Similarly, research, a process to advance our knowledge, requires very similar but more robust and formal protocols and oversight. But technology can help us here, supporting our decision making when in situations of genuine equipoise by providing transformative technology supporting identification, recruitment and randomisation of patients into complex, multi-arm trials currently require manual labour-intensive work.

Metrics of success

We must admit that our work will never be complete. As a result, whether we are talking about our clinical services, our technology or our research, we should never use metrics that simply talk about deployment, but instead consider outcomes and our efforts should be focused on improving those outcomes.

Like many others, NHS Wales currently uses deployment as a metric for success, but we need to change the conversation to value and outcome and shift to adopting the best industry practices for creating safe, reliable and valuable clinical software at pace.

In part three, I talk about the importance of technical and information standards, standardised application programming interfaces and frameworks to create ecosystems of interoperating smaller, well-defined contextually domain bound components sharing the same platform. Continue reading…

Posts in this series

• Part one: creative destruction
• Part two: the value of software for healthcare
• Part three: ecosystems and the platform

Further reading

• “Lean healthcare” : Value stream: transforming health and care technology implementations using lean, agile, “DevOps” and serverless with small, cross-functional teams.
• “Where is the value?”: Creative destruction and ecosystems

Footnotes

a:The single patient record is a good idea - a logical single source-of-truth that is the canonical repository of information. Except, i) there is no truth in healthcare so you are better with models of uncertainty and ii) a medical record must be faceted so that it is possible to regulate access to different categories of information such as source (e.g. provider) and type (e.g. sexual or reproductive health matters, mental health, genetics, general medical etc). But, for now, “single patient record” is a useful pragmatic label.