Interweave view on the development of a Unified Digital Health Record

Background

Interweave is the brand name of a shared care record solution in use across six Integrated Care Systems which together cover a total population of almost 9.5m, 15.3% of the population of England (NHS England ICB Allocations 2022/23). You can read more about the collaborative partnership here.
The Interweave partnership facilitates a collaborative approach across the partners and supports local partner-led innovation. Our product stack is based on open standards, modern technology and FHIR compliance.

Developing the Unified Digital Health Record

We set out below our thinking on one potential approach to delivery of a Unified Digital Health Record, based on our own experience and taking into account the wider views of the Shared Care Record community.
Figure 4 below illustrates the conceptual model for a UDHR.

The examples at the bottom of the diagram represent a range of contributors to a UHDR. The architecture should allow for contribution from authorised data providers from across all care settings in both healthcare – both those working in NHS services,private healthcare,and social care.

In addition, patients and their carers should also be seen as partner contributors,indeed the #AboutMe dataset is all about the patient.

Contributions to the UHDR will need to be based on meeting certain key standards:

• messaging standards – for which we would advocate FHIR
• semantic interoperability model standards – for which we would recommend openEHR
• coding standards – where we would recommend use of SNOMED-CT and LOINC.

While Figure 4 illustrates the range of contributors generating content for the UDHR Figure 5 below represents this single logical model in terms of a number of different components.

 

These components – when taken together – represent an individuals UDHR but there is no need to have all these elements held in a single physical location as long as they are discoverable and accessible.

As well as the content, a UDHR solution will need additional capabilities so that there is a ready means of accessing those elements of the UDHR regardless of their physical location. These are described in Figure 4 as

• Authentication – the requirement to be confident of both the individual subject – the patient or citizen – as well as the contributor to their record and the individual or system requesting access.
• Authorisation – Even when confidence of the authenticity of the patient and requestor there is a requirement to ensure that they are authorised to either contribute or request information to or from the record
• Audit – at all times it must be possible to track where contributions have come from and who, and how they have been accessed. We would also advocate designing the capability to notify the patient – should they wish – of any contribution or access (as was delivered as part of the IPS PoC).

 

Figure 6 illustrates how the UDHR might evolve through a combination of national and local (regional) platforms which hold patient record data.

While in theory all data could ultimately be held once nationally, the ambition to create a DHR in the first term of government needs to be tempered with the practical reality. There is a considerable national and local financial investment in the regional shared care record platforms and to minimise cost of duplication – and mitigate against the risk of failing to deliver such an ambitious programme within that timetable – we recommend that the evolution of the UDHR is undertaken in two parallel workstreams.

Workstream1 – starting from national

We already have the essence of a national digital health record, so to minimise duplication of effort, technologies and funding, and to mitigate risk, we recommend building out from on the existing national spine – which already services the National Care Records Service (NCRS), the Personal Demographic Service (PDS),the National Record Locator (NRL), and Organisational Data Services (ODS).

The current national service also holds the Summary Care Record with Additional Information (SCR-AI) data which is accessed via the NCRS. This exists and is operational now.

We would recommend the addition of the ability for patients and carers to be able to contribute to the #AboutMe dataset.

We would also recommend that this #AboutMe data set is supplemented by data about reasonable adjustments, such as the need for translation or for special access requirements. We refer to this as AboutMe+.

Additional capabilities will need to be defined and implemented such as Identify and Access Management and Audit functionality.

Workstream 2 – Connecting up local

In parallel with the reengineering of the existing national components we would recommend progressively integrating with the existing local Shared Care Record  platforms.

At the heart of the architecture will be a record location capability, which will be able to act as a master index to identify where – across the English health and care landscape – elements of a citizen’s records can be found. We believe that this functionality could be delivered through a reengineered National Record Location capability. The core function of this capability will be to store index details of records that exist for an individual patient together with metadata associated with the way in which that data can be accessed.

To illustrate why this is essential to do at a national scale, this we use four example use case classes, these taken from the work of the NHS England national Shared Care Record programme.

 

 

In example 1 a hospital may be located close to an ICS boundary and treat patients coming from several different ICS populations.

As an example, the Airedale NHS Trust sits close to the West Yorkshire/Lancashire boundary. While the majority of patients are residents of West Yorkshire ICS, substantial numbers come from the North Yorkshire and Humber ICS, as well as the Lancashire & South Cumbria ICS.

While the Yorkshire and Humber Care Record platform is capable of supporting those residents of West Yorkshire and North Yorkshire and the Humber ICSs, without a consistent approach embracing the work of the Lancashire in South Cumbria ICS and access to their shared care record platform, there is a risk of providing differential levels of service to patients depending on where they live because of differential access to their health records.

Health and care professionals in that hospital who have a need to look beyond information which may be stored in their hospital EPR, would need to trigger a request to the National Record Locator to identify whether there are records about a specific patient that exist elsewhere across the health and care landscape.

Subject to authentication – are we confident in the identity of the requestor? – and authorisation – even if we are confident about the identity of the requestor, does that individual have the appropriate permissions to access this information? – requests could then be made to the source systems to pull back the information which they have and present it to the requestor.

 

The second use case example is of an ambulance service that spans multiple integrated care systems. Again without a consistent approach they are faced with multiple ways of accessing patient record information, which is a major challenge in an emergency situation. Indeed given that the ambulance service may be called out to many visitors to their region – especially relevant in the South West – access to a national record is critical.

So a health and care professional, such as a paramedic, working in the ambulance service, once they have determined the identity of a patient should be able to readily access key information about a patient whether they live not just from within the footprint of the ambulance services but from elsewhere across the England.

The same process as described in Example 1 can apply, namely that details of the patient identity are sent to the record locator which can identify the location of key information and then return those records to the requestor.

In this scenario the paramedic may only be interested in that information which makes a difference to their care of the patient- for example information about allergies and medications. Their initial query can be parameterised and the response filtered so that they only need see that subset of a patients total record.

 

The third example is of regional clinical networks. In these networks patients may receive treatment in general practice, local secondary care hospitals and tertiary care specialist cancer units. Currently each care setting maintains its own records leading to hand off and communication challenges when patients pass between them if being treated within the wider clinical network.

The problem is compounded in that not all clinical networks align to regional boundaries.

Once again the same model can be applied, namely that a health and care professional involved in the care of that patient, if they have a legimiate need – can retrieve other information about the past records and future care plans of that patient, wherever they may be stored.

 

The final use case class example relates to rare diseases. Because there are so many rare diseases, even though the numbers of patients classified as having a specific rare disease may be small, there are very many of them and in total about 1 in 17 of the population does have a rare disease.

While there may be only one – or a small number – of national specialist centres for those diseases, the patients with those diseases also receive more general care in their local health service. Again, it is essential that all those involved in their care have ready access to information about the records of those patients regardless of where they have been treated in the past, and are able to see relevant care plans.

We believe that – to maximise return on existing investments and mitigate against the risk of failure – the development of the UDHR should work from both directions simultaneously. Top down from the existing national patient record and bottom up from the local shared care record platforms.