UK Core FHIR Technical Implementation Group

Presented by:�NHS England and HL7 UK

February 22nd 2024

Housekeeping

We will be recording the call

We will be having discussions, hand raised please

Add unrelated questions or questions we can respond to later into the Teams chat

2

Agenda for today

 - Sprint 8 Proposal – Interoperability Medicines (Ryan May, NHS England)

UK Core STU2 Ballot Update (Adam Page, NHS England)

- Sprint 9 Proposal – Care Plans (Ryan May, NHS England)

Digital Signing of Medication Resources (Adam Page, NHS England)

- Highlighting Breaking Changes? (Adam Page, NHS England)

UK Core Roadmap (Ryan May, NHS England)

Uses of UK Core (Ryan May, NHS England)

3

UK Core STU2 Ballot Update

Adam Page (NHS England)

​

STU2 Ballot Update

83 comments submitted, 40 negative

8 resolution calls between October – December

69 actions agreed

4 comments marked as Not Persuasive

​

Currently:

HL7 UK have reached out to commenters and asked them if they are happy to withdraw their negatives in light of the agreed resolutions (2 week window)

2 remaining actions on the UK Core development team

​

Next Step:

Package and Publish for HL7 UK review (2 week window)

5

Breaking Changes

Changes from balloted STU1 Sequence to STU2 Sequence:​

​

• Minimum Viable Content are now MustSupport flags​
• Renamed ukcore-imm-1 constraint to ukcore-imm-001, to align with design approach​
• Reset minimum cardinality on UKCore-Practitioner.identifier from 1 to 0​
• Updated the following extensions datatypes from Code/Coding to CodeableConcept​
• UKCore-AddressKey, ​
• UKCore-BirthSex, ​
• UKCore-OtherContactSystem ​
• Updated binding strength in extension UKCore-EthnicCategory, due to a codified design approach to bindings​
• Reset UKCore-Patient.communication.language to base binding, and increased the strength to Required, ​this is to bring this element in line with future FHIR versions

​

6

Breaking Changes

​

Changes from Ballot Review copy of STU2 Sequence: 

​

• Changed ukcore-diag-lab-001 constraint from 'effectivetime' to 'issued' 
• Renamed UKCore-Observation-LabGroup to UKCore-Observation-Group-Lab 
• ValueSet UKCore-UnifiedTestList has been retired, and replaced by two new valusets, with new SNOMED CT reference sets 
• Updated the following extensions datatypes from Code/Coding to CodeableConcept 
• UKCore-ConditionEpisode, 
• UKCore-DeliveryChannel, 
• UKCore-ListWarningCode 
• Updated binding strength in extensions UKCore-AdmissionMethod, UKCore-DischargeMethod, UKCore-LegalStatus, UKCore-OutcomeOfAttendance to extensible 
• Removed 'issue' from CodeSystem UKCore-ConditionCategory

​

​

​

7

Breaking Changes

Additional Changes for STU2 Sequence:

​

• Reset the following profiles to draft status,: UKCore-Consent, UKCore-EpisodeOfCare, UKCore-Flag, UKCore-ImagingStudy, UKCore-MessageHeader, UKCore-OperationOutcome, UKCore-Questionnaire, UKCore-QuestionnaireResponse, UKCore-Task  ​
• Reset the referencing on all profiles to base resources, with an intelligent redirect within the IG to the UK Core profile guidance page

​

Please note that although these profile have been reverted to draft they can be used.

8

Breaking Changes

How should we inform you of these breaking changes?

​

Currently:�- Version History IG

- Call out box on front page of UK Core IG

- Call out box on affected asset

- In these calls

9

Digital Signing of Resources

Adam Page (NHS England)

​

Business Need

England and Wales NHS prescribing legislation requires the use of Advanced Electronic Signatures (AES) on electronic prescriptions going through the Electronic Prescription Service (EPS). An implementation of AES using the HL7v3 standard has been live since 2007.

​

We expect England and Wales NHS prescribing legislation to change for controlled drug prescriptions to permit the use of AES for all electronic prescribing. This means in addition to prescriptions going through the Electronic Prescription Service (EPS), also inpatient and outpatient prescribing using Trust pharmacies, contracted Outpatient pharmacies and Homecare services.

​

The EPS still retains the legacy HL7v3 back-end, so prescriptions going through the EPS must still be signed and persisted using the HL7v3 standard. At some point, EPS will remove the legacy dependency on the HL7v3 data model.

​

Prescribing that does not go through EPS can move directly to HL7 FHIR.

​

Therefore, we need an agreed solution for using AES with HL7 FHIR, and specifically for use when using the HL7 FHIR UK Core standard.

11

Management Summary

Proposal that UKCore implementation guidance states the following:

• If the resource to sign in represented in XML, construct a signature using the XML-DSIG standard.
• If the resource to sign in represented in json, construct a signature using the JWS standard.
• The entire resource should be signed, opposed to marshalling a subset of the resource data. This differs from the legacy HL7v3 implementation where a subset of the XML payload including all data elements legally required for a signature are marshalled for signing. Where a Resource.status value may change during workflow, manage workflow with the FHIR Task resource and keep the Resource.status static. Any change to the resource data will invalidate signature integrity. Where business processes require, content updates to signed resources would require the resource to be re-signed.
• Signature validation must be performed against the resource in the notation format from which is was signed, e.g. if signed as json, must be validated as json. The FHIR $convert operation must not be used as part of the signature validation process.
• Once a signature has been verified as valid, the FHIR resource can be converted between notation standards using the $convert operation.
• A single signature within a single Provenance resource should be based on a single Resource. This will ensure signature integrity between FHIR Messaging and FHIR RESTful implementations.
• Avoid applying a single signature across a Bundle of resources, unless the purpose of the signature is solely for message transport integrity. This differs from the legacy HL7v3 implementation where one signature covers the logical collection of data elements that form the legal prescription entity.

12

Implementation Options

Which signing standard(s) to use?

• PROPOSED Allow JWS or XML DSIG leaving the choice with each signing implementation
• Mandate only use of JWS and mandate use of only JSON payloads
• Mandate only use of JWS and allow either JSON or XML payloads
• Mandate only use of XML DSIG and mandate use of only XML payloads
• Mandate only use of XML DSIG and allow either JSON or XML payloads
• Mandate use of both and require two signatures for all signing implementations; the provider system creates and signs both JSON and XML content
• Allow JSW or XML DSIG leaving the choice with each signing implementation, and allow JSW inside XML payloads and/or XML DSIG inside JSON payloads.

​

How to marshal data to bind with a signature?

• Replicate the HL7v3 implementation, marshalling business data required by law, as XML, excluding data that could change, e.g. status attributes
• Replicate the HL7v3 implementation, marshalling business data required by law, as json, excluding data that could change, e.g. status attributes
• Marshal only the business data, excluding notation mark-up, i.e remove XML or json mark-up, to allow multi-notation format compatibility, allowing implementors to choose between working with XML or json
• PROPOSED Marshal the complete FHIR resources in the format presented (e.g. XML or json) and use the FHIR Task resource to manage prescription status workflow

​

Where to add signatures into FHIR payloads?

• Extend resources such as MedicationRequest with a signature element
• Create a single Provenance resource, containing a signature, for each "prescription" represented as a number of FHIR resources
• PROPOSED Create a single Provenance resource, containing a signature, for each individual resource, that collectively represent the "prescription"

13

Putting It All Together…

14

UK Core Roadmap

Ryan May (NHS England)

​

Sprint 8 Proposal

It has been proposed that the Clinical and Technical Assurance Sprint 8 is a maintenance sprint for the Interoperable Medicines work

​

Specifically, this would focus on adding assets and guidance for the 3 previously discussed items:

• Digital Signing
• A “dispenseTo” location on MedicationRequest
• A “courseOfTherapyType” extension on MedicationStatement

​

Other possible outcomes could be:

• Incorporating Interoperable Medicine specific guidance for dosage into UK Core
• Incorporating Interoperable Medicine specific guidance for RequestGroup into UK Core

16

Sprint 9 Proposal

It has been proposed that the Clinical and Technical Assurance Sprint 9 is focused on Care Plans. These may include:

​

• Community care
• Mental health
• Maternity
• Cancer
• End of Life
• Return to Work

​

If you have any request or examples, or want to be involved with either of the sprints please contact the Interoperability Standards team.

​

17

Looking Ahead?

Questions we’ve been asked / that are on our radar:

​

Workflows – UK Core Task was made a draft resource as it was deemed immature and not fully modelled. Defining a standard for task management and workflows could be somewhat essential for the digital signing, and we’re hearing similar from various aspects of the diagnostics domains, but specifically pathology and radiology.

​

IPS – An ongoing query we are asked about regularly, and don’t have a concrete answer on from an NHS England viewpoint, yet alone a UK Core one, is around International Patient Summary.

​

Questionnaires / Structured Data Capture – UK Core Questionnaire was made a draft resource as it was deemed immature and not fully modelled. We know that work with PRSB and Care Plans is likely to revisit these resources.

​

Additional Profiling – Most resources that were modelled within CareConnect were modelled during the early days of the UK Core. Some of these have been found to be outdated designs, and need remodelling, and there are additional resources that have been identified as being useful to do some investigation.

18

Uses of UK Core

Ryan May (NHS England)

​

New IG for Example Uses

20

Add your agenda topics to the Teams Chat

Or email us at interoperabiltyteam@nhs.net

Next meeting

21

Useful links

Simplifier

Projects

​

UK Core IGs

Other Guidance

Further Reading

Project for UK Core

UK FHIR Community Assets

CareConnect Baseline

​

​

​

UK Core 1.0.0 – STU1 ballot complete

UK Core 2.0 for STU2 ballot in progress

UK Core version history

​

​

​

​

UK Core Hazard Log

UK Naming Systems

CareConnect Baseline

​

​

UK Core Implementation Guidance Directory

​

22

interoperabilityteam@nhs.net

​

23

Thank You

digital.nhs.uk