The funding for the NHS Frontline Digitisation initiative is imminent with the aim, according to Dr. Tim Ferris, the National Director of Transformation at NHS England and NHS Improvement and his Chief Information Officer, Simon Bolton; of “levelling-up acute sector IT and ‘converge’ the systems in use across hospital groups and, possibly, integrated care systems”.
At BridgeHead, we’re already seeing preparation in full flow by many NHS Trusts and some integrated care systems (ICS) who will soon go out to tender for the procurement of an electronic patient record (EPR) solution (if they haven’t already).
For some organizations, this will be their first foray into the world of a centralised EPR solution (known in Frontline Digitisation terms as Group 0). But for others, this is a path that they have trodden before as they embark on procuring their next generation EPR solution (Group 2). The final cohort (group 3) tend to be more digitally mature and already have EPRs in place (that are deemed to already meet the requisite ‘core capabilities’) but may still be looking at ways to further enhance and improve their technology landscape.
Does a shiny new EPR solve all ills or create other issues?
It’s an exciting time for many NHS organisations who are anxious to glean the benefits of their first, second, or even third generation EPR. As the technology has evolved, the solutions available today have advanced considerably; and it’s no coincidence that many of the EPR vendors have focused a lot of time and attention ensuring their products are truly ‘fit for purpose’ for the NHS (which wasn’t always the case).
As great as many of these solutions now are, EPR implementations are notoriously arduous. They are time consuming, resource intensive, expensive, and rarely go live without incident. But it’s a commonly held view that the ‘pay-off’ is worth the pain and stress that naturally accompanies projects of this scale and size.
However, one thing to bear in mind… as you set the wheels in motion to procure your new EPR, you will invariably create a stream of legacy applications! Though these legacy applications are essentially obsolete (with much of their functionality to be replaced by your new incoming EPR), they still contain valuable patient, clinical, and/or operational information.
Legacy EPR data – blockers and migration headaches
Time and time again, we see healthcare organisations around the world focus all of their attention and energy into the process of specifying, buying, rolling out, and then managing and maintaining their new EPR. I totally understand why this is critical to the success of the project. But, one important (and often overlooked) question that should be top of mind when embarking on an EPR project is: “what is going to happen to your legacy patient, clinical, and administrative data?”
Based on my experience, healthcare organisations generally answer this question in one of two ways:
- “We’ll just migrate all of the data from our old EPR (or the array of applications that provided the essence of an EPR, such as PAS, clinical portals, and homegrown solutions) into the new EPR”;
- “We will run our old EPR (or other systems as described in #1) in parallel with our new EPR until such a time we can deal with it/them”.
Well, here’s the rub! (Note: I don’t know why I used this term – I really don’t like it, but couldn’t think of an alternative while writing this). In the case of example #1, it’s a fallacy that all of your legacy data is simply migrated into the new EPR. Typically, the new EPR vendor will limit the amount of data that it will allow into its application – usually a maximum of 2 years. But this does not cater for the vast majority of historical data (which, in some cases, could be anywhere between 10 and 20 years’ worth).
In the case of example #2, this places a huge burden on healthcare IT teams who are tasked with funding and managing the legacy EPR (or the disparate legacy solutions that were running previously) simply to provide ongoing access to the data they contain. And, underlying this, is an expectation that clinicians and support staff will search both the old and new EPRs to access the patient information they need – particularly needed when dealing with long-term or more complex cases. We shouldn’t underestimate the cost of running and maintaining two EPRs, which is not only expensive, but a significant drain on resources. Plus, we also need to consider the security implications of running older systems (often utilising older hardware) given the focus of cybercriminals who are continuously targeting vulnerabilities and security loopholes that have the potential to cripple healthcare operations.
Legacy applications are not new – but they are a persistent problem
The first thing to say is that legacy applications are not a new phenomenon in the NHS. As technology has increasingly enabled the streamlining of clinical practice and hospital operations, it has and continues to be adopted more widely. However, as innovations emerge and demands change, a technological lifecycle was born.
As a rule of thumb, EPRs tend to change every 10-15 years; PACS applications every 5-10 years, LIMS every 5-10 years; and storage hardware every 3-5 years. As new applications are procured and implemented, they tend to, by default, create legacy systems – those superseded clinical, patient, and administrative systems that are left behind.
The ongoing challenge for healthcare organisations is that there were no obvious solutions to deal with their legacy application estate (which has grown considerably over the years). Historically, it has been deemed extremely difficult, very expensive, time consuming, and was not considered a high priority in the grand scheme of things. For many, the cost of continuing to run legacy applications has been factored into the annual IT budget as a ‘business as usual’ expense. However, the landscape has changed. With the need to have information more readily available across healthcare organisations (be they multi-site NHS Trusts, ICSs, diagnostic networks and the like) and the security implications of managing aging systems and hardware, ‘do nothing’ is no longer an option.
Surely, there must be a better, more efficient, and cost-effective way to deal with your legacy applications and the important data they contain.
Consider a clinical data repository and registry to help you retire your legacy EPR
Increasingly, NHS organisations are looking to tackle the issue of retiring their legacy applications whilst still retaining access to the valuable patient, clinical, and administrative information they contain. And one option starting to gain momentum is the implementation of a clinical data repository (CDR) and registry.
The idea behind the CDR is to provide a centralised, long-term home for patient health information from across multiple sources such as (but not limited to) imaging systems (e.g. PACS, RIS, specialist applications), laboratory systems (e.g. LIMS), and other clinical and administrative applications. But it is also a perfect solution for managing data from your legacy EPR and other replaced, duplicate, or outdated applications.
The CDR should integrate directly with your EPR to offer clinicians and support staff a much richer patient record – especially as, in our experience, 70% of all healthcare information lives outside of the EPR. This is a winning combination when it comes to harnessing data, particularly when it comes to making patient information available outside the walls of a hospital, such as in community healthcare, mental health, tertiary care, or more broadly at the ICS or diagnostic network level. And as well as providing clinical decision support, it can also be used for research, population health management, and to power AI and machine learning initiatives.
A New National Framework For Legacy Information Integration And Management
The good news is that the problem faced by NHS organisations of how to deal with their legacy EPR applications and data is not only understood, but it appears that funding of £150m is being made available to tackle the issue. The Countess of Chester Hospital NHS Foundation Trust’s Commercial Procurement Services is looking to introduce a new framework entitled ‘National Framework Agreement for Legacy Information Integration and Management’. This framework will allow NHS Trusts to procure legacy information integration and management solutions to address the challenges outlined above.
Where can I find a clinical data repository and registry solution?
Here’s the unapologetic plug but I promise to keep it short. BridgeHead Software’s HealthStore® solution enables you to extract data from your legacy EPR and other systems, ingest that data into a central repository and registry, where it is easily searchable and accessible by clinicians and support staff directly through your new EPR – and all ‘in patient context’. But, importantly, it also allows you to retire those legacy systems – saving cost, time, and resources; whilst also removing system vulnerabilities from aging applications.
By employing a CDR, like BridgeHead’s HealthStore, to retire your legacy EPR system whilst putting that data to work is a significant step in modernizing your healthcare organisation. By carefully considering the reasons for retiring your legacy systems, and making the necessary preparations, you can ensure a smooth transition to a modern, efficient, and secure new EPR.
If you would like to learn more on how BridgeHead can help your initiatives for frontline digitisation, diagnostics modernisation, and/or infrastructure improvements…
Working in tech marketing for almost 30 years, and specifically in health tech for the last 13 years, John has and continues to learn about the real issues faced by healthcare providers and is convinced that technology, when specified and implemented correctly, can be a ‘game changer’ in the delivery of patient care.
At BridgeHead Software, John is working to disrupt the myopia around healthcare applications instead supporting the view that data (and not applications) is the strategic asset by which patient outcomes and experience can be improved.
