In most hospitals in Northern Ireland (and indeed in many care settings), clinicians still rely on paper notes. The dream of "going paperless" seems very remote. Despite the spectacular success of the Northern Ireland Electronic Care Record (NIECR), many in the Health & Social Care sector are deeply suspicious of computers, and not especially keen to move to a system where the paper is replaced by screens.
There are good reasons for this. We peer across the Irish Sea at the fiasco of the NHS England "Connecting for Health" initiative, in which billions of taxpayers' pounds were wasted trying to get big corporations to devise One System - a megasuite - to pretty much manage the whole of health IT in a "replace all" model.
|[Altnagelvin Hospital's new South Wing. Photo: Belfast Telegraph]|
Not that such models are necessarily doomed to failure - several large corporations (mainly US-based) have made a very successful business from selling broad-scale electronic health record (EHR) systems to hospitals and healthcare organisations. This almost inevitably includes getting doctors, nurses, allied health professionals, administrative staff and others adopting the company's way of doing things. And that might not be a Bad Thing in itself - after all, the company may rightly pride itself on bringing a wealth of learning about processes and flow from its previous customers, so if you change to the Company's Way, you will be changing to a tried-and-tested model of lean efficiency. But if the local change process is managed badly - or if you haven't decided exactly where it is you want to go - you could end up spending hundreds of millions of pounds and getting thousands of people very disgruntled indeed. Nobody needs that.
So let's back up a bit. What is an EHR in this context? What IS Shane talking about? Essentially an EHR is more than a record - it provides an electronic framework for managing patients details as they proceed through the health system (hospital, community, GP etc). As such it may include patient details (demographics); scheduling of appointments, operating theatre lists, ward lists etc; we'll obviously want to have clinical noting in there (do away with the paper charts!); documents management; medicines management and e-prescribing would be great (let's make sure everyone is using the same medicines list); observations; laboratory test ordering and results; radiology ordering and images; and more besides. We'll clearly need ways for clinicians (by which I mean doctors, nurses and associated health professionals) to access the system; we'll need to let the admin people in; and in most forward-thinking approaches, we need ways for patients themselves to access and interact with their data (patient portals). Because it is THE PATIENT'S data. Then there is the need for public health and other aspects of population-based data crunching to ground good decisions about resource allocation and response to health needs.
There are other elements too - clinical decision support; terminology repositories (to make sure we are all speaking the same language); alerts, coding, and (particularly in the American scenario, which is where all this started - and it shows) billing. This is not an exhaustive overview - I've rattled this off the top of my head and I could probably come up with another ten or fifteen core functions if I wanted to make this post even longer and less likely to be read.
So if your head is not reeling already, it jolly well should be, because we are talking about a very complex set of requirements. If you're a health service that is still very much paper-based for many of these functions, and the computer systems that you do have don't talk very well to each other, you're likely to want to buy one of those big snazzy systems that offers a solution to everything.
But hang on a second. Do not - and I repeat, DO NOT - underestimate the scale of the challenge of change. Implementing a do-it-all system is a perilous process, and while some organisations have managed this very well, and the vendors of the systems are themselves very skilled in their processes, the path to EHRvana is littered with the shattered remains (OK, I'm over-egging this a bit) of organisations which failed to plan and implement effectively. This is going to require a LOT of resource, in terms of raw cash and most importantly people who have the energy and leadership to pull the rest of their colleagues over the line. For some organisations this is the right approach. But it is not the only approach.
Let's step back a bit. What exactly are we trying to achieve here. What is "EHRvana" anyway? It turns out that what we're really looking for is a way to have a single "source of truth" about our patients - a pool of data - that is accessible to us and our patients at the point of care and wherever else we need it. It needs to be secure to protect confidentiality and confidence. It needs to be accurate and up to date. It needs to be rich, in that it should not omit anything important. It needs to be structured in such a way to allow smart queries to deliver relevant results back, without drowning the user in useless stuff.
If I'm a cardiologist, I want to see information on the patient relevant to my job. Likewise if I'm a podiatrist, I need my own view. Or a geneticist. Or a nephrologist. Or an appointments clerk. The requirement is not that we all use the same interface, but that we all dip into the same data pool and extract the information that is relevant to us. And some of our data requirements will overlap. And the patient will want to see snippets of them all.
So an alternative model might look like a single common data structure (like a big database that contains everything), supported by various interfaces (in technolingo these can be referred to as "APIs") that do the data depositing, querying and processing. On top of those layers, instead of a megasuite, we may have different applications that provide the user interface, and they talk to the APIs to read and write data from/to the data structure.
If we break things up this way, it does a couple of things. One, it opens up the market. Instead of being forced to go with the big boys, we can have smaller software vendors competing in a much more accessible space. If we need a cardiology system, we buy a cardiology system; we don't need to buy an entire acute specialties suite. Secondly, it can rapidly speed up product development, in that interfaces can be tailored to local needs, or even new emerging needs that weren't considered in the early days of the project.
OK, Dr McKee, you may ask, what is the best solution for Northern Ireland? I admit to being something of a newbie to this arena, but one principle looms large in my thinking. We have an opportunity here to do things OUR way. We're planning for the next 10 years, and trying to deliver high quality health care to a population of almost 2 million. We're trying to do that within constrained budgets. We do have fantastic patients. We have excellent healthcare personnel. We have strong relationships built up over many years across our health and social care sector. We have the experience of working with a system (NIECR) which delivers relevant clinical narrative right to the bedside or clinic.
We need to decide what Northern Ireland is about. Are we following the world, or do we want to lead the world? Can we design a patient-centred approach to healthcare data that allows us to bring different services on-stream, to maintain the leadership and drive over a long period, to deliver value for money to our taxpayers, to provide workable models for others to follow?
I believe we can. And in a future blog I'll lay out some of the steps that I think we need to take in order to do that. Some of the strategic partnerships we may wish to engage in to ensure that we get the best health results possible for our patients, and how we can provide a stimulus to the knowledge economy that will carry Northern Ireland forward in the coming decade.