In May of 2022, the UK government announced a program aimed at accelerating the adoption of the HIMSS Electronic Records Adoption Model (EMRAM) across the UK (albeit it’s referred to locally as ‘Minimal Digital Foundations’ and is subject to some variations to the original specifically for the NHS. But for the purposes of this blog, we will continue to refer to it as the HIMSS EMRAM model). The government’s aim is for all UK NHS hospitals to reach a baseline level of digital maturity, the target being HIMSS Level 5 by the ambitious deadline of March 2025.

The HIMSS EMRAM model was designed to provide a scale of measurement for healthcare organisations to assess clinical outcomes, patient engagement, and the use of electronic medical records (EMR) technology. Ultimately, the model intends to guide hospitals through its stages, each helping to improve the delivery of better healthcare at a more affordable cost.

The use of the HIMSS EMRAM model really took centre stage in the US during ‘Obamacare’ or, more precisely, the HITECH Act, both of which directly linked to the American Recovery and Reinvestment Act (ARRA) from the same time period. The key purpose was to reduce costs and increase efficiencies in the delivery of quality healthcare. But it should be noted that the HIMSS EMRAM model doesn’t specifically focus on cost, rather the efficient use of data across the healthcare ecosystem.

Even though HIMSS EMRAM stems from the US healthcare system, it’s become highly relevant to the UK’s Frontline Digitisation initiative and, specifically, the removal of as many paper-based systems as possible. In this blog, I will be particularly focusing on the UK government’s plans for HIMSS EMRAM Levels 1 through 5.

The Seven Stages Of The HIMSS EMRAM Model

There are 7 stages to the HIMSS EMRAM model (see ‘Figure 1’). The common thread across them all is the requirement for digitisation, especially the modernised management of data; all in a bid to improve healthcare.

Broadly speaking, the levels can be divided into two camps:

Levels 0 – 5

These are self-certification levels with a focus on monitoring the removal of paper-based processes and the introduction of electronic systems (a quick comment from me: this actually causes an interesting paradox in that, with the rise of cyberattacks, more facilities are introducing paper-based processes in the event that their electronic systems are compromised!)

Levels 6 & 7

These are externally assessed levels that measure how well healthcare organisations manage data and how this data is used as part of a constant improvement cycle.

Figure 1 – Stages of the HIMSS EMRAM Model



HIMSS EMRAM – A Force For Good

Firstly, I would like to state that the objectives of the HIMSS EMRAM program are laudable and certainly worth pursuing in my opinion. Like many ‘regulations’ we see across the broader business landscape, HIMSS EMRAM is promoting better practices that will lead to the delivery of more efficient and effective healthcare. That’s one of the main reasons EMRAM has taken off and moved beyond the confines of the US Government’s plans to a worldwide aspirational model.

Being somewhat ‘late to the show’, the UK government is right to focus on this initiative. In the US, 10% of hospitals have reached HIMSS Level 6/7 while in the UK only 0.6% have the same attainment. So the NHS clearly has some catching up to do – this is being addressed directly by the Frontline Digitisation initiative. It should be stated that healthcare organisations do not have to go through this program in a linear fashion. It is possible that they can leapfrog straight to stage 7; or they can start at 0 and take action to achieve Level 3. However, most organisations focus on ‘doing the groundwork’ first (aiming for Level 5) before moving on to 6/7, which are much more onerous.

The Focus: The ‘E’ In ‘EMR’

For the US, the direction of travel for the original EMRAM model was to implement electronic medical records (EMRs), with an emphasis on the ‘E’ in ‘EMR’. There have always been medical records – it was just that, historically, they were paper based as opposed to electronic. And, it’s important to state that HIMSS does not directly suggest the need to implement an electronic medical record application (though the preferred nomenclature in the NHS seems to favour the ‘Electronic Patient Record’ or ‘EPR’) in order to create electronic medical records (as you will see below). But it is now the case that the terms ‘EMR’ or ‘EPR‘ are synonymous with large scale applications that are charged with not only managing patient data but extend, in many cases, to underpinning hospital operations. And this has certainly been one of the objectives for the US government.

Computerised Physician Order Entry (CPOE)

The system that allows transactions and instructions to be passed between ‘the big 3’ and, eventually, all other applications.

Clinical Data Repository (CDR)

The single and central source of information for all healthcare applications. All electronic systems should store their ‘copy of record’ in the clinical data repository such that it is available to all other systems. Furthermore, that data should be stored in a manner that makes it accessible to other healthcare applications (i.e., not in a proprietary and/or encrypted format, for example).

The Clinical Data Repository Or CDR

My area of interest and expertise focuses on the Clinical Data Repository or CDR for short. Throughout my many years in health tech, and with my particular focus on healthcare data management, I have been puzzled as to why healthcare organisations don’t have independent data repositories and a single agreed protocol for transferring clinical information. The industry ‘may’ be arriving at the protocol for interoperability with the advances in Fast Healthcare Interoperability Resources otherwise known as FHIR. Yet, when talking to our customers, it is still very much the case that data continues to be ‘locked’ in applications (especially given older applications don’t support FHIR); this can be a very dangerous strategy long-term because data is generally retained for far longer than the lifespan of any application. Organisations that I deal with seem to spend a lot of time and effort managing redundant applications simply to meet their compliance and governance obligations for pre-defined data retention policies. A CDR, and a process for moving data from redundant applications to the CDR, is something that would make all healthcare organisations more efficient.

The CDR also helps address the bigger immediate issue and that is the use of paper-based systems within the NHS. A paper-based workflow isn’t a problem because it uses paper. The problem is that it prevents the free flow of accurate information around the organisation. Digitising this data could set it free BUT not if that data is hidden away in a system that no one can access, and which doesn’t support open data standards. The CDR aims to be the open repository on which you can transform paper-based workflows.

Today, it’s still the case that accessing data from across the healthcare ecosystem is difficult. More concerning is the real danger that the situation could worsen in the future! Ask yourself a simple question: if applications have a shelf life of (let’s say) 10 years, but the data they create has a retention period that could easily be 5 times the life of that system, what is your strategy for storing that data once the application has gone? Your answer can’t be “all of the information is in the EPR” because:

  1. an EPR is also an application which, by nature, has its own ‘shelf life’ (this could be 10 years or beyond, but it will eventually disappear – usually replaced by a newer system);
  2. in my experience, most EPRs contain around 30% of all the data found across a healthcare organisation. So that leaves approximately 70% of data unaccounted for in this scenario.

Some healthcare organisations may say “my strategy is to delete the data once it’s no longer needed”. However, the next question I would ask is: define what “no longer needed” means. In the world of AI and data-powered healthcare, the value of electronic information is changing dramatically. As a result, even older data can be incredibly useful – after all, large datasets can be leveraged to create AI algorithms that can be used to treat people in the future. Clinical regulations, such as the Records Management Code of Practice for the NHS; are now just one of the parameters that will define how long content is useful. And as more and more patients allow use of their data for clinical advancement, records will be retained for differing purposes.

The Spaghetti Incident

In the new world of healthcare, some may think that FHIR could be considered as a replacement for the EMRAM CDR as it allows the free flow of data around the healthcare ecosystem. But I would argue that history has taught us there is a problem here. Though HL7 has many flaws, it has been very successful in data sharing. The main issue was the complexity of keeping all of the HL7 connections working – every time there is a change to any system, it may break the HL7 connectivity. This complex web of HL7 connections was often described as the ‘HL7 Spaghetti’.

Almost every hospital has an integration engine. The keepers of those systems will often say that “we know when something has stopped working, but the integration is so complicated it takes time to understand why”. HL7 certainly made interoperability possible, but FHIR should make it more efficient. FHIR has better methods to ensure that all application endpoints are constantly talking the same language; and FHIR is also vital for treating the current patient episode. However, most of the data that an organisation manages is far from ‘current’ – it’s largely old and historical. Although FHIR is an improvement over HL7 in terms of efficiency, it’s still going to be comparatively expensive for managing historical data because it will mean that all systems will need to support FHIR. This would mean that older systems would need to be retrofitted to support FHIR even though they may be legacy applications. This may happen to a point, but not exhaustively – it would be time consuming, cost prohibitive, and not all application vendors will play ball.

While HIMSS EMRAM doesn’t reference FHIR, the model does, with its endorsement of a CDR, fix some of the issues that FHIR will create, such as multiple end points and the ‘HL7 Spaghetti Incident’.

The Missing Part – Document Search And Availability

If I could make one change to the EMRAM program it would be the addition of a Document Registry. The CDR proposed by the EMRAM program is still bound to the EPR and really makes demands on the EPR/PAS functions. As we generally expect that 30% of an organisations data is in the EPR, a lot of information that needs to be interoperable resides outside of the system (often in application silos).

It’s really important that we know that data exists in the first place. In most cases, simply identifying there is data, and ideally having a known method to access it, would be a huge improvement over the situation we have today. At a very high level, a registry that indicates that information is present and where is resides (in terms of the applications that manage it) will have many advantages:

  1. It will decrease the number of systems that need to support end points (you effectively query the registry not the core application) and reduce the traffic in searching for historical information;
  2. It will reduce the cost of implementing activities, such as retention management; since most of the historical data can be ‘found’ through one system. Implementing governance policies, again such as retention management; is greatly simplified if there are fewer systems to manage or interact with.

The nirvana of having to query just the registry will make controlling access to data, for any reason, much easier.

Some of you that are versed in healthcare protocols may think of standards, such as XDS, which has the concept of both a repository and a registry. Please don’t misunderstand – I am not suggesting the use of XDS rather than FHIR. Any protocol will fail if it doesn’t have wide adoption; and XDS (though a great standard) simply doesn’t have the take-up. FHIR, by comparison, is clearly gaining global momentum and its adoption fixes significant issues with the classification of data. What I am proposing isn’t ‘one or the other’. It’s that FHIR doesn’t preclude the use of a registry. I feel a central registry would greatly improve the efficiency of data search and retrieval whilst reducing the ‘spaghetti’ mentioned above. There is no reason why a single data item can’t be accessed via FHIR and XDS (or other standards such as DICOM and HL7).

Procuring Or Upgrading Your EPR?

As we’ve seen, the HIMSS EMRAM model suggests healthcare organisations need to modernize their electronic data efforts in a bid to provide electronic patient records. Across the NHS, organisations are at varying levels of digital maturity, so this direction of travel impacts them in different ways. But the focal point continues to be largely (though not exclusively) on a centralised EPR solution. For some, they may be starting at ground zero – never having had an EPR before (where the current functionality in place has been provided by a collection of other systems, such as a PAS, clinical portal, or home-grown system; or, in extreme cases, entirely paper based). For others, they may already have an EPR, but their contracts are close to ending and/or they may be looking to upgrade or move to an alternative EPR provider. And for those that are already at HIMSS Level 5 (and beyond) it’s more about optimising their existing environments – making them more integrated with other applications in the ecosystem, or simply working more efficiently.

From whichever point you may be starting, my experience is that when you implement a new EPR, your vendor will only allow the migration of the last 2 years of data (regardless of its source). Yet, if you have had an EPR (or other systems) for the last 15 years, for example, then you will understandably have a lot of legacy data looking for a new home. This is often overlooked and something that really needs due consideration and planning as part of your holistic EPR strategy.


The HIMSS EMRAM model has been around a long time; and it is a very worthy goal to bring NHS organisations up to a ‘Minimal Digital Foundation’ namely HIMSS Level 5. In my opinion, the CDR (suggested by EMRAM) should be a ‘must have’ for maintaining historical data – something every NHS organisation has; but should also feature a registry for the easy searching and retrieval of information, as and where needed, across the healthcare ecosystem.

In addition, let’s not forget the most important recipients of EMRAM. The NHS Frontline Digitisation initiative, and the push for more efficient use of electronic data within healthcare, can only be a good thing for patients! To my mind, helping all NHS organisations to achieve HIMSS EMRAM Level 5 is far more helpful to the health economy rather than assisting a few organisations to achieve Level 6 or 7 (as with all models, such as this, I think there are diminishing returns as you progress to the higher levels).