I think that many of us, if we were asked how to build an electronic patient record, would quite reasonably say: “Well, I wouldn’t start from here.”
At University Hospital Southampton, we have been working for many years on what used to be called ‘an incremental model’. This paints a simple picture of ‘start here, follow some steps, and get there’.
However, the reality is that when you start to mix applications together, the ecosystem created means you have to manage an increasingly complex set of overlaps. This is the reality of what now seems to be called ‘best of breed’, or ‘connect all’.
In addition, if you have already interfaced/integrated a discharge summary product with a patient administration system, order communications system and theatres data, you are dictating to the next supplier (of, for example, e-prescribing) that they must adapt to this.
And in doing that, you will maybe have to accept that you are not going to use all the functionality available in their system. So the issues with following this approach are not just that you have to build and maintain an awful lot of interfaces.
Decoupling parts of systems, and running them without certain key functions, can be quite challenging when they were built with particular workflows and logic in mind.
Still, at the end of the day, the aim is to make it work as if the whole were a single system. Users need to log-in, search and then navigate functions without repeated authentication challenges, let alone different user interfaces, or the need to complete a marathon training programme.
Pros and cons on all sides
The model we have been following can, therefore, be shown to have fundamental weaknesses. Decision support could be difficult to deliver, and the overall support effort of keeping it all going may become a burden.
It may seem logical, instead, to put as many eggs into the one basket as you can by implementing a ‘single-supplier’ EPR; and I can certainly see the case for doing that. Those who have done more incrementally could feel disadvantaged by the market if and when more complete EPRs are proven to work in UK hospitals.
So, am I siding against the strategy I have been working with? It may sound that way. However, nothing is as simple as it seems.
A large single product, which may or may not be modular (even if it is badged up under one supplier name), requires a large degree of tailoring for an installation, which can take a number of years.
Installation itself may be so difficult that you have to weigh up the cost of possibly taking a step backwards initially, in order to take two forwards later.
So the decisions that an organisation makes should be based on many factors; not least its inherent ability to deliver the integration required to a satisfactory level; bearing in mind that while today’s integration tools and techniques are pretty good, many suppliers are working with some quite dated technologies.
Bringing it all together
We have worked with our main EPR vendor, Ascribe, to bring all of the products we built and bought along the way under a single framework.
Some would call it a portal, but I hesitate to use the word. The main thrust of this is a component that gives doctors and other clinical staff a “list” view of the world, based on their team, ward, consultant or operating mode.
From here, they can carry out a range of tasks, complete assessments such as VTE (the risk of a patient suffering a venous thromboembolism, or blood clot), look at history (including the local Hampshire Health Record summary record), acknowledge results, order investigations, and prescribe (in a third party embedded application, JAC).
When a patient is selected in the list, they stay in context throughout the whole suite of applications, and a user is prevented from seeing different patients in different modules.
The level of integration required to achieve this, along with the underlying interactions, is what makes me quite nervous about the word portal. I am concerned that things that are described as ‘portals’ can be used to paste a layer of veneer over systems, while offering only restricted functionality.
I think this could conceivably leave some ‘bear traps’ in terms of safety; something that EHI’s newseditor, Rebecca Todd, noted that we were keen to avoid when she paid a recent visit to the trust to see what we had been up to.
In three years, a lot can change
The choice that faces us now is the choice that many others will be facing. Do we continue what we are doing, or go out and try and buy something that does it all?
Every time I think about this, I am swayed by two main factors. Firstly, can we get to where we need to be pursuing our current route or by testing the market? And secondly, if we bought something, would it be as good as what we have at the moment?
When I was speaking to Rebecca, I picked up some element of surprise that we had not mapped out the total piece of work to where we are and then go beyond it.
We tend to work on a three year horizon in terms of funding and technical/product direction. Sometimes, I feel we have to accept that we don’t yet know what the next step will be, and that is not easy in strategic thinking terms.
However, although tablet computing has been around for years, the iPad came out in 2010 and suddenly showed us that we could do some things differently, making a step forward in the process. The iPad came out in 2010 – that was just three years ago!
Adrian Byrne
Adrian – Ade – Byrne is director of IM&T at University Hospital Southampton NHS Foundation Trust which, he says, has been working on its IT environment for 15 years.
On his LinkedIn profile, he says its aim is to “build an electronic patient record with full decision support, sharing data across disparate, so-called best of breed systems.” The trust is also developing a patient record and services, built on Microsoft HealthVault.