Can the ‘have-nots’ overtake Exemplars in the interoperability stakes?

Can the ‘have-nots’ overtake Exemplars in the interoperability stakes?

Are exemplar programmes really the only answer to NHS interoperability? Felim McCarthy thinks otherwise and looks at how those not invited to bid to become a Local Health and Care Record Exemplar could become interoperability heroes. 

Without doubt the recently announced Local Health and Care Record Exemplars (LHCREs) programme will bring valuable attention to the pursuit of true interoperability across health and care providers.

Like all good NHS IT programmes, it focuses on improving the delivery of direct patient care, but intends to achieve this through five carefully selected regional sites. These will have to develop shared health and care records and demonstrate adoption of wider integration across care boundaries.

New digital health initiatives seldom arrive without questions around bidding criteria, funding allocations and anticipated results. Global Digital Exemplars (GDEs) are the most recent example of this. The reality is that we are still waiting on quantifiable benefits from them – over one year on.

The ‘have-nots’, those NHS organisations that were not invited to apply for funding, will face an anxious and even longer wait to see how they can benefit from the programme. And while the LHCREs hold promise for some good things, there will be question marks over how fast demonstrable results can realistically be delivered.

Don’t make clinicians wait longer  

Clinicians and carers are tired and frustrated with the over-promises of how IT systems can benefit them. They want better access and the ability to update patient information in real-time on the device of their choosing, and they want it now.

On announcing the LHCREs, Dr Simon Eccles, NHS National CCIO said safe and effective information sharing can “make care far more efficient and less frustrating”, and in some cases “lifesaving.” And he is absolutely right. So, with clear clinical benefits for interoperability, it’s no surprise that this initiative is being rolled out.

But sustainability and transformation plan (STPs) are still grappling with the ambitious delivery of full shared care records. They are massive, complex pieces of work that place further burdens on local care providers who are already shackled by bureaucracy, differing priorities and levels of digital maturity across multiple local organisations.

They need government guidance and funding to make it happen.

No more ‘big bang’

Some NHS and social care organisations want, and need, to achieve pockets of integration faster to deliver clinical, efficiency and financial benefits now, not in months or years down the line.

If nothing else was learnt from the National Programme for IT, it was that a ‘big bang’ approach is complex and too difficult to meet the needs of everyone.

One route to delivering shared care records is through portal technology. They take a more holistic approach to achieving as many interoperability goals as possible within one large project.

The concern here is that portals may add another level of complexity for system users, create more silos of data, and add burdensome information governance issues.

Also, larger projects require more stakeholders who are often seconded from other NHS roles. Juggling diaries, priorities and personalities adds to the lethal bureaucracy that sees projects like this scaled back and often not delivered on time.

Building blocks

An arguably better way to increase stakeholder engagement and build momentum around shared care records is to demonstrate what can be achieved with smaller, quicker interoperability successes and then scale up.

Rather than trying to solve all the problems with a single implementation, tackle the most urgent problem and then build on that success. Remove the pressures of delivering large, cumbersome programmes, and show people what good looks like, and they will be inspired to do the same, or more.

We know that if you show quantifiable delivered benefits to clinicians, then clinical engagement will follow. This approach can be applied more widely across organisations in a health and care economy where differing levels of digital capabilities and priorities are a common issue.

Lead by example and provide the NHS with a set of interoperability ‘building blocks’ which over time will address many of the current issues and if properly adopted may even avoid future issues as care moves ever closer to the patient and their home.

An example of one ‘building block’ could focus on managing end of life preferences more effectively. It supports the Recommended Summary Plan for Emergency Care and Treatment (ReSPECT) initiative that is building momentum and up to 12 sites will have implemented the process this year.

The process creates personalised recommendations for a person’s clinical care in a future emergency where they are unable to make or express choices; however for this to work the information needs to be readily available to a paramedic control room, NHS 111 or Out of Hours GP Services and relayed to ambulance staff.

But how, you ask?

Use existing APIs and interfaces through what some NHS IT professionals are now calling a ‘presentation layer’ (which is essentially a virtual patient record) to bring immediate benefits and not be bound by the aforementioned large interoperability roadmaps.

Plugging the interoperability gap

It’s encouraging to read that each regional LHCRE will build on the existing local work on shared care records to further develop joined up regional health and care information reference sites – we should leverage current systems and data to help meet integrated care aims. To do this, we need to address the current ‘interoperability gap’.

Currently Trust Integration Engines (TIEs) provide basic interoperability across NHS trusts, but have their limitations when faced with managing multiple messaging standards, through different APIs to different users, in different care organisations.

On the other end of the scale, enterprise-wide integration solutions such as electronic patient records and clinical portals are the first step towards a full shared record, but they require extensive resource to deliver.

We can bridge the gap between the two by leveraging the use of existing TIEs and APIs to view and share information about the same patient amongst themselves, but still within their main systems.

On a technical level this can be resolved with this ‘presentation layer’ that can interface with any care system and pick off projects one at a time.

The race to achieving interoperability maturity

Like the classic hare and tortoise tale, the race to deliver integrated care is not a forgone conclusion with the appointments of the three  LCHRE sites. Will the potential wait for funding, and alignment with larger integrated digital care record (IDCR) technologies increase timescales to achieve the promised outcomes?

The ‘have-nots’ hold an opportunity to deliver smaller, high-impact integration projects that build towards full interoperability maturity faster than their counterparts.

Felim McCarthy is a senior clinical consultant at ReStart Consulting Ltd.

Disclaimer: The opinions expressed in this article are those of the author and do not necessarily reflect the views of Digital Health Intelligence or its employees.

 

Subscribe to our newsletter

Subscribe To Our Newsletter

Subscribe To Our Newsletter

Sign up

Related News

Children’s Health Ireland to implement interoperability platform

Children’s Health Ireland to implement interoperability platform

Children’s Health Ireland is working with InterSystems to implement an interoperability platform at the new digital children’s hospital in Dublin.
The Health Foundation: technologies clinicians say can save the NHS time

The Health Foundation: technologies clinicians say can save the NHS time

Research from The Health Foundation has explored the technologies saving clinicians time right now, and those that have potential for the future.
Roundtable: How can APIs drive effectiveness and interoperability in the NHS?

Roundtable: How can APIs drive effectiveness and interoperability in the NHS?

Application programming interfaces (APIs) have a hugely important role to play in the sharing of healthcare data. However, too often they fail to gain traction…

2 Comments

  • Another issue is the technical layers supporting the LHRCRE/portal/presentation layer doesn’t produce much documentation. The following list should be a recognisable summary for techies, it’s a ‘fag packet’ summary for interop. Most of this already exists and doesn’t need to be re-documented.

    – Authentication – openid (intend to use NHS Identity Service openid when available, especially for external clinicians)
    – Authorisation – OAuth2 (server is SMART on FHIR enabled)
    – API (non GP) – Want to use a resource API, ideally with JSON payload. So we intend to use FHIR, following Care Connect API spec but it’s missing a few key resources.
    – API (GP) – hopefully use GP Connect when structured is available but we have the MIG.
    – Terminology – SNOMED, following NHS Data Dictionary and new valuesets from NHS Digital/CareConnect.
    – Messaging – continuing to use HL7v2 and TIE with local systems, may extend to local providers to support MPI work. Suggest standardising on ITK HL7v2 spec (not XML)
    – External Referrals/Care Plans (and other documents) – looking at how to send referrals to other care Providers, I think we should use FHIR messaging (XML) via MESH or direct RESTful probably linked to Master Document Indexes.
    – We should really look at adding a single Master Patient Index next and one or more Master Document Index (following the IHE XDS pattern)

    – Consent – the project teams are working on this

  • Excellent article – and I agree that focused quick-win small-step interoperability projects could be key to rapid progress in eHealth interoperability across the UK.

    However, there will be rapid and sustained progress only if the specifications are published so that others can adopt them.

    Publishing interoperability specifications and related documentation would be in line with Goverment Digital Services “share and reuse technology” guideline.

    It would be great if every Digital Health interoperability article such as this one included a link to the specifications that were used in the project.

    Could INTEROPen, HL7UK, BCS and/or NHS Digital maintain a library of specifications and conformance statements used by interoperability projects across the country? Just making the specifications available on the web would be great, adding to that some indexing / curation so that they can be found would be even better.

    If projects are using standards and existing APIs and infrastructure that’s great and it would be good to have that information publically available. If they are not, then publishing the specifications that they are using allows the standards developers and NHS Digital/England to see what is being used, to inform their analysis of what is needed. Open API specifications would also support innovation, by letting those developing eHealth solutions see where their products could hook in. There would be a patient safety benefit as open specifications can be reviewed by more eyes.

    There is already some such openness in the imaging world, with DICOM Conformance Statements routinely published.

    Everyone will move faster and more safely in the journey to full interoperability maturity when the technical specifications used in interoperability projects are open for review. Surely one of the lessons learned from NPfIT is that having interoperability architectures and specifications hidden for commercial/contractual reasons is bad for the NHS, its staff, patients, and eHealth ecosystem.

    Both “have-nots” and “Exemplars” have an opportunity to take the lead in establishing such open practice. It will be the ones that have the most open and easy to reuse specifications for developers who will become the de facto leaders in healthcare interoperability. Let the race begin…

Comments are closed.