EPR divergence in a local area ‘will not be supported’ under HSLI

EPR divergence in a local area ‘will not be supported’ under HSLI

Sustainability and transformation partnerships will be expected to standardise clinical IT systems across the local health economy as part of the £412.5m Health System Led Investment programme.

A prospectus for the programme, which was shared exclusively with Digital Health News last week, reveals that projects which risk increasing the diversity of IT systems within an area will not be favoured within the NHS England-led initiative to bolster provider digitisation.

It specifically states that sustainability and transformation partnerships (STPs) will be expected to support a move to a standard electronic patient record (EPR) system across all organisations in a geographic patch.

The document reads: “Investment in solutions that would result in the divergence of services, systems or infrastructure across the local health and care system should be avoided, unless a compelling rationale can be made. Specifically, EPR divergence in a local healthcare system will not be supported.”

It emphasises “there should be a focus on standardising IT solutions across health systems to simplify data sharing, ease staff movement between providers and reduce the total cost of ownership”.

Under the Health System Led Investment (HSLI) programme, STPs will be allocated a set amount of cash for developing local provider digitisation plans.

While the investment agendas will be set by STPs, it will be down to individual health and care organisations to spend the funds.

The requirement of EPR standardisation suggests something of a departure from the ‘national support, local decisions’ attitude which became more prevalent following the disastrous National Programme for IT (NPfIT).

Push for open APIs

Interoperability standards will also be a key requirement of STPs and Integrated Care Systems (ICSs) under the Health System Led Investment (HSLI) programme.

Health systems will be expected to “ensure provider organisations comply with national interoperability standards designed to enable the effective sharing of data across care settings.”

This includes the promotion of open APIs that enable the sharing electronic patient health records, and the use of consistent sets of terminology and diagnostic codes such as SNOMED CT.

By December, STPs will need to ensure that providers have enabled delivery of Open APIs using CareConnect profiles, “or have locally agreed plans in place to do so.”

The prospectus, which also revealed plans for fresh waves of GDEs, goes on to suggest that NHS England will provide key interoperability priorities that provider organisations will be required to work towards, under the direction of STPs and ICSs.

This includes the sharing of structured basic observations; sharing of structured dates and schedules; sharing of structured basic pathology information; sharing of medications that are machine readable and interoperable; and use of the NHS number at the point of care.

HSLI funding will be doled out to the 44 STPs in phases, with 25% given in 2018/19, another 25% given in 2019/20 and then the final 50% handed over in 2020/21.

At a national level, £104m is available in 2018/19, £92.4m in 2019/20 and £261.1m in 2020/21.

STPs have between 1 September and 5 October to submit their final investment proposals.

Subscribe to our newsletter

Subscribe To Our Newsletter

Subscribe To Our Newsletter

Sign up

Related News

NHS North West London ICB cuts virtual ward capacity

NHS North West London ICB cuts virtual ward capacity

The end of ring-fenced funding for virtual wards has contributed to the fall in bed virtual ward bed capacity at NHS North West London ICB.
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.
BMA advises GPs not to share cloud-based telephony call data with NHSE

BMA advises GPs not to share cloud-based telephony call data with NHSE

The BMA's GP Committee England has warned that NHS England could use cloud-based telephony data to ‘performance manage’ GP practices.

9 Comments

  • Good. And about time, too.
    It will be extremely challenging for some, it will take longer than we’d like to think it should take, and there will be a lot of resistance in some quarters, but it’s the right approach.
    The money. Needs to take account of more than just capital. Will the STPs be expected to handle all revenue consequences of getting providers onto the same core EPRs and, if so, how will that be balanced between the EPR changers and changees?

  • ” … the divergence of services, systems or infrastructure across the local health and care system should be avoided, unless a compelling rationale can be made. ”

    Plenty of wiggle room there 😉

    Given the different requirements of Acute, Community, Social Services and Mental Health services, never mind the opportunity costs incurred when changing an EPR supplier (data migration, end user training, re-configuration, acceptance testing, process mapping etc.) that wiggle room is going to be needed!

    • NHS England seem to be trying to deny the different requirements (not to mention the privacy issues) by attempting to push GPs into “housing” Social Services and Mental Health within their practice and integrate them into the practice team, where all clinicians have access to all patients’ records. Clearly this is an attempt to to achieve integration not only between providers but within providers, and probably also an attempt to drive the move towards federations and super practices. All of this is surely built on the assumption of interoperability between different record systems, and the willingness of patients to have their personal confidential information accessible to half the world. What we need is room to wriggle out, sharpish.

  • This sounds a sthough there will need to be both organisation and technical change – and plans – made by bodies with no legal existence (don’t know whether they have any secretariat) – & to be submitted within 6 weeks?
    What could possibly go wrong?

  • Can we have some techies and technical informatics experience involved in these decisions?

    To get medications safely shared your EPR/dispensing systems needs to support SNOMED (be able to support the same coding system).
    You can never do this with a shared system, someone will allways be outside this EPR.

    The cost to change systems is huge and takes time (over a year).
    I honestly can’t believe we are still trying to do a new version of NPfIT, CfH.. Haven’t we learned anything??

    • I may have misread this a little.

      Let’s be clear open API/care connect means a set of FHIR API’s. The core of these api’s is pretty simple to implement (the SNOMED element isn’t, that’s a lot of work to be done in hospital systems).

      I would say the fhir api should be implemented within a few months (max one year) but you are allowed to defer SNOMED coding for 1-2 years.

      The reason for the push on the basic core FHIR api is it’s a building block, from this you can build more advanced functionality. Wether that’s a custom app for a nurse, document endpoint for NRLS or workflow such as transfer of care, etc.

      If your system or app supports this, then for me you’ve got a defence against this EPR standardisation idea.

  • NHS England Glossary:

    Information and Transparency = Obfuscation and Duplicity

    • Don’t understand why SNOMED should be difficult to implement. It was designed to be used at the point of care. I have been using SNOMED in my office for 10 years and it is very unusual for me to not find exactly what I am looking for.

  • Surely nobody actually believed the “National suoport, local decisions” propaganda? That was all about fooling the public into thinking that their personal data was in the hands of local institutions that they (supposedly) could trust. The plan has always been, sooner or later, to pipe the data from local systems into “National Data Lakes”. For that there has to be interoperability at a national level. “National support, local decisions” means, “you can do whatever you like as long as you do what we say”.

Comments are closed.