In this blog post, I want to talk about transforming our health services using technology.

There are four core messages:

Most of us working in healthcare are already familiar with a range of quality improvement methodologies - we see them at work when we discuss our healthcare services - and yet we frequently fail to use those same improvement techniques in our information technology projects.
We can learn from how technology companies have adopted similar quality improvement methodologies (lean and agile) in their efforts to develop new technology, and use the same approaches to both develop and manage healthcare information technology.
That small, cross-functional teams can be given responsibility for delivering discrete functional components of a wider software architecture, bringing together development, testing and deployment as part of a wider “DevOps” strategy. Increasing adoption of ‘serverless’ technologies is a logical result of this strategy.
That these same approaches can be extended to include our existing quality improvement and research methodologies so that we accelerate the adoption of data-driven value-based healthcare in a virtuous cycle of improvement. We use technology to re-imagine how we deliver healthcare to our citizens, with information technology an enabler of transformation; ownership is key here with IT and quality improvement going hand-in-hand.

I’ve included some links to resources for further reading at the end.

Healthcare transformation

We need to consider how we most effectively use information technology in healthcare so that we do more than simply replace our paper records with electronic equivalents.

We must think deeply about how we can use technology to transform how we deliver healthcare to our citizens. We must be ambitious and yet plan to deliver those ambitions incrementally, safely, carefully and within the constraints within which we work.

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

Fundamentally, we need to re-imagine a new technical architecture - an open platform at its core - built on standards and interoperability. But, we must also go much further than simply talk about technical architectures and drive a change in culture and trust.

In essence, to deliver IT-enabled healthcare transformation, we need the right:

open architecture
cultural ‘norms’
technical and information standards

These should underpin our software development and technical operations.^a

A cohesive strategy

Information technology projects must be ‘owned’ by the organisations delivering care with a focus on quality improvement.

“The key to creating a lean enterprise is to enable those doing the work to solve their customers’ problems in a way that is aligned with the strategy of the wider organization. To achieve this, we rely on people being able to make local decisions that are sound at a strategic level—which, in turn, relies critically on the flow of information, including feedback loops.”

Lean Enterprise, 2015, Jez Humble, Joanne Molesky, and Barry O’Reilly

It is difficult to defend organisational structures in which ownership of information technology projects is outsourced to an external agency. Such issues of ownership are a fundamental problem when something goes wrong^b; a safer approach is to make the ownership explicit with a clear purchaser/commissional-provider split in which lines of responsibility are explicit. The health organisation as a whole must “own” the information technology solutions and take responsibility for any consequences of failure.

Similarly, given that all organisations and businesses are now, in effect, information technology companies (including healthcare organisations), information technology should not be the responsibility of a single department but cut across all internal departments. What changes can be made to the way we deliver healthcare that doesn’t have some need for information technology change?

“Historically, the adoption and management of health care IT has been left to an organization’s chief information officer and other technical personnel. This is a mistake. … health care IT is effective only when all members of an organization work to unlock its potential.”

“… many health care organizations use IT as a tool to monitor current processes and protocols; what only a small number have done is leverage those same IT systems to see if those processes and protocols can be improved—and if so, to act accordingly.”

“… [we need to] embrace [IT] as an instrument to help transform the way they deliver medical care. This will entail prioritizing quality improvement over cost cutting, making data collection easier and better, turning the data into actionable information for clinicians, and forging new operating and business models. We have found that while numerous health care organizations are moving in this direction, the majority are not making the holistic changes needed for transformation.”

Harvard Business Review (HBR) The IT Transformation Health Care Needs, Dec 2017

So what are our goals?

How can we make the right decisions about architecture, culture and standards to enable us to use information technology effectively to monitor, improve and transform our health services?

What are our goals, given we work in complex, heterogeneous, ever-changing adaptive systems, with a high degree of uncertainty?

At our foundation, we need a high-trust collaborative cross-organisational culture. What culture do you have in your own organisation, or across multiple organisations in your wider health economy? We need a ‘generative’ culture:

Pathological organizations are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.

Bureaucratic organizations protect departments. Those in the department want to maintain their “turf,” insist on their own rules, and generally do things by the book—their book.

Generative organizations focus on the mission. How do we accomplish our goal? Everything is subordinated to good performance, to doing what we are supposed to do.

Lean Enterprise, 2015, Jez Humble, Joanne Molesky, and Barry O’Reilly

As part of that culture, we must recognise that we do not have all of the answers and that we must be able to adapt to change.

It is easy to fall into a trap of thinking the best way of dealing with uncertainty is building “command-and-control” like structures in which we analyse the work to be done and deliver it by breaking it up into components or projects. It is, unfortunately, naive to think that centralised command-and-control reduces risk in delivering valuable information technology.

Instead, we must focus our efforts around high-level strategic objectives and then create small cross-functional teams empowered to deliver components of that vision.

“According to the Principle of Mission, we create alignment not by making a detailed plan of how we achieve our objective but by describing the intent of our mission and communicating why we are undertaking it.The key to the Principle of Mission is to create alignment and enable autonomy by setting out clear, high-level target conditions with an agreed time frame—which gets smaller under conditions of greater uncertainty—and then leaving the details of how to achieve the conditions to teams.”

Lean Enterprise, 2015 quoting “The Principles of Product Development Flow” by Donald Reinertsen

As I wrote in “The paradox of control”:

“There is an important paradox in many health services, including Wales, is that there is a tendency to centralise the day-to-day management and delivery of individual products and yet high-level strategic and prioritisation decisions are decentralised, haphazard and dependant on capital funding with little or no consideration or control as to how those projects will fit into a wider technical healthcare enterprise architecture.”

“A paradox of control”

Balancing inherent conflicts

We need to explicitly create a) an architecture, b) a culture and c) appropriate standards that result in overall solutions that are safe and secure and yet at the same time enable innovation.

It is easy to see how such goals can be in conflict, unless we explicitly mitigate that conflict in how we design and manage that architecture, that culture and those technical standards.

Here are just three examples of what appear to such conflicts:

we need software to respond to our changing needs and provide ever increasing value via automation (IT “developments”) while at the same time, we need to provide stable, reliable and secure services (IT “operations”)
we need local innovation and local decision making but ensure that local developments are not orthogonal to the wider strategic roadmap.
we need to adopt technical and information standards and yet support innovation and flexibility in approach.

Such conflicts are magnified if we have the wrong architecture, culture and standards. Similarly, the right architecture, culture and standards can minimise or entirely mitigate these apparently intractable conflicts.

We need to adopt “DevOps”, agility and lean thinking.

DevOps

“DevOps” refers to creating cross-functional teams who break-down the traditional barriers between IT developments and operations.

Modern technology companies have seen huge productivity gains from creating small teams to quickly and independently develop, test and deploy software and therefore deliver value at pace. They minimise risk by breaking down work into smaller, less risky units that can evolve independently with only loose-coupling with other components. They combine the development of new functionality with highly automated testing and deployment, often building in “feature switches” which optionally turn specific new functionality on or off depending on runtime configuration for testing in limited real-life environments before more widespread use is permitted. Such teams may deploy multiple versions per day, each deployment small and low risk, dependent on successfully passing automated testing and easily rolled back in the event of problems.

The key is that developers can deploy into potentially multiple production-like test environments with little or no manual effort. Deployment is automated from a technical point-of-view, and, codified. As a result, testing and deployment are both designed and executed using code or configuration files and is therefore automated. It is entirely reasonable to delay actual deployment into production until other requirements are met, but that process becomes one of simply migrating provenly reliable code.

Such an approach is very different to what usually happens in healthcare IT. Those of you who work within the NHS will be familiar with long development cycles, entirely separate teams running the different stages of development, testing, deployment, and maintaining services. The process for creating and deploying new functionality typically requires long test-cycles, user-acceptance tests and then, at some indeterminate time in the future, features are rolled into a high-risk big-bang deployment.

The DevOps Handbook talks about a “downward spiral” in three acts, in which components of a wider architecture become fragile and increasingly difficult to change, building an increasing “technical debt”, of attempting to make changes by cutting corners and never really having time to fix the underlying issues and so adding to that “debt”, and resulting in a situation in which:

“everything becomes just a little more difficult, bit by bit— everybody gets a little busier, work takes a little more time, communications become a little slower, and work queues get a little longer.

“Our work becomes more tightly-coupled, smaller actions cause bigger failures, and we become more fearful and less tolerant of making changes.”

“Work requires more communication, coordination, and approvals; teams must wait just a little longer for their dependent work to get done; and our quality keeps getting worse. The wheels begin grinding slower and require more effort to keep turning.”

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

The natural conclusion is that we should aim for continuous integration (CI) and continuous deployment (CD), with a focus on splitting up what we need to deliver into manageable chunks to be worked upon semi-autonomously by small, independent, cross-functional teams themselves releasing software frequently and often with the confidence of automated toolchains to support extensive unit, integration and security testing with deployment into production-like environments.

The advent of “serverless” technologies supports and extends “DevOps” principles:

Serverless computing allows users to run code without provisioning or managing any underlying system or application infrastructure, and they automatically scale to support increasing or decreasing loads. https://blogs.gartner.com/andrew-lerner/2017/07/21/serverless-is-not-networkless/

With “serverless” computing, we no longer need to manage our own infrastructure but instead make use of commodity cloud computing providers who take our code and run, monitor and scale to meet demand automatically. Our IT “operations” work is still needed however, but almost by default, software development is immediately deployable into production-like environments. Operations are still needed in order to orchestrate multiple semi-independent services but technologies such as API gateways can act to provide a unified single point of access to multiple services.

Agile

The “Agile” manifesto was released in 2001; the key points for the purposes of this post are:

continuous delivery of quality software
delivering working software frequently
harnessing change

It is easy to see that “agile” is about culture change and that the consequences of a change in culture are a set of technical solutions such as DevOps and Serverless. Agile is, in effect an enabler of “DevOps”.

“Instead of large batches of work being processed sequentially through the design/ development value stream and then through the test/ operations value stream (such as when we have a large batch waterfall process or long-lived feature branches), our goal is to have testing and operations happening simultaneously with design/ development, enabling fast flow and high quality. This method succeeds when we work in small batches and build quality into every part of our value stream.”

The DevOps Handbook

Lean principles and Six Sigma

While “Lean” was originally created by Toyota to improve productivity and quality, the principles are much more widely applicable to other industries.

The five Lean principles are:

Value: what we want to do or deliver
Value stream: the steps and processes needed to deliver the ‘value’, removing steps that do not add value
Flow: ensuring that the steps and processes that contribute to ‘value’ flow smoothly with no interruptions, delays or bottlenecks.
Pull: delivery of value as required ‘just-in-time’
Perfection: making lean thinking and process improvement part of the culture

Similarly, many readers might be more familiar with the Six Sigma methodology, now widely used within healthcare. Six Sigma focuses more on variation and design than flow and waste, but clearly these approaches are complementary and indeed, many now combine the two as “Lean Six Sigma”.

I have discussed the Six Sigma DMAIC cycle previously when discussing “The Medical Record” and the importance of a data-driven approach to quality improvement.

Dmaic

Application to healthcare

So we have a convergence that, at its core, is focused on delivering value. Information technology is critical in our healthcare quality improvement endeavours and we can apply those same endeavours to how we build our information technology tools.

It is my view that quality improvement, in all its forms (e.g. our 1000 lives campaign in Wales), and information technology are inextricably linked and mutually beneficial. Quality improvement benefits from good information technology as the latter is fundamental in performance of the “measure”, “analyse” and “improve” steps of a typical DMAIC cycle. Similarly, information technology benefits from applying those same quality improvement methodologies.

We need a “reset” in NHS Wales when it comes to information technology and I suspect this applies to other health economies as well.

We need to embed quality improvement at the heart of our information technology and information technology at the heart of our healthcare, adopt a generative culture and deliver at pace.

We need less command-and-control and more trust and collaboration, with decision-making, clinical and design, based on meaningful data.

“Scott Cook, the founder of Intuit, has long advocated building a culture of innovation, encouraging teams to take an experimental approach to product development and exhorting leadership to support them. As he said, “Instead of focusing on the boss’s vote… the emphasis is on getting real people to really behave in real experiments, and basing your decisions on that.” This is the epitome of a scientific approach to product development.”

The DevOps Handbook.

Questions to ask

If you are working in healthcare information technology, particularly if you’re in Wales, ask yourself these questions:

Do you have a clear view of your “mission” and yet have sufficient autonomy to create teams to get things done?
Do you have “can-do” ethos and a culture of trust and collaboration?
Do you have a track record of delivering valuable products consistently, to time and within budget?
What is the time interval between development and deployment? Is it measured in hours, days, weeks or months?
Similarly, do you have ready access to production-like test environments to prove, via high-levels of automation, that changes in one system have no untoward effects in another? (Ask questions about test environments and automated checks that our systems are deterministic, both when running independently and when integrated with other systems).
Does your team view deployment in the same way as committing code instead of with trepidation, planning and prolonged downtime?
Do you have robust investigation of failures, with a learning culture and codified tests to ensure such failures are prevented in the future?
Do you have objective measures of quality improvement, do you routinely collect metrics on user satisfaction, performance, downtime or whatever else needs to improve? Have you adopted a data-driven approach to informatics and quality improvement?
Do you have a cadre of professional user-interface designers working across teams to focus on improving your user’s experience in using your software?

Because, if you can answer yes to these questions, you are much more likely to be able to…

Move fast and ~~break~~ fix healthcare…

Do you want to join me?

Mark

Footnotes

a:That’s why I was delighted to be asked to chair the new Welsh Technical Standards Board (WTSB), a new group that will work in partnership with the Welsh Information Standards Board (WISB).

b: 3079 “parked” electronic referrals unintentionally unsent by general practitioners in Wales to secondary care services were deemed a “process issue” and not an “IT failure” and resulting investigation was “difficult due to lack of engagement from health boards” as the software supplier “owned” the project to digitise the referral pathways and not the organisations that owned the care pathways involved.

Lean healthcare