FHIR© UK Core Learnathon

INTEROPen Team

Introduction

• INTEROPen = Interoperability + Open Standards
• INTEROPen is an OPEN collaboration of Health and Social Care Providers, NHS Digital, NHS England, software suppliers – including techUK, standards organisations and individuals to define and drive adoption of open interoperability standards
• Has a Board with 2 Co-Chairs from the Service and the Vendor Community that Meets Monthly
• Uses a Collaboration Tool (Ryver) that all members can use and a YouTube Channel
• Runs Hackathons to test out new and emerging UK Interoperability Standards and those for which ISNs exist

Commercial interests are put to one side in the group’s activities.

Co-Production

362 Member Orgs

Today's Learnathon is brought to you buy....

Agenda AM

*formerly NHS Digital now merged into NHS England.

Agenda PM

*formerly NHS Digital now merged into NHS England

Throughout the day we will be using Mentimeter to gather your questions and feedback

• The full day will be recorded and will be placed on INTEROpen YouTube site.
• Teacher Strikes – please tend to your kids if you need to !
• Train Strikes - keep an ear out for any stranded family and friends. 
• Mentimeter – Please ask questions and vote on them via the mentimeter slide deck.

​

Housekeeping

An intro to HL7 UK

​

Rik Smithies

Technical Chair, HL7 UK - tcchair@hl7.org.uk, 

Independent Consultant, NProgram Ltd. - rik@nprogram.co.uk

​

​

HL7 UK and FHIR

​

Rik Smithies

Technical Chair, HL7 UK - tcchair@hl7.org.uk,

Independent Consultant, NProgram Ltd. - rik@nprogram.co.uk

​

​

�PO Box 7230, Hook RG27 9WX, UK�Tel (+44) (0)8700 112 866 Web www.hl7.org.uk �Registered in England no. 04026136 VAT Number GB 742 5286 29

What is HL7?

• The organisation that makes FHIR
• …so, what is FHIR?
• More on that later!
• (However, for the impatient
• a set of JSON (or XML) health data resources, plus a REST API for accessing them
• it’s a way to exchange healthcare data via HTTP
• it’s web servers for health data)

​

• A not for profit organisation

Who are HL7 UK?

• HL7^* is a standards body - like BSI, or ISO
• HL7 UK is the UK branch of HL7 International
• We are the UK “Affiliate”, as it is known. https://www.hl7.org.uk
• We are an organisation consisting of our members
• see https://www.hl7.org.uk/register/why-join :-)
• We have a Management Board�https://www.hl7.org.uk/register/about-hl7-uk/management-board-members
• All volunteers. We do pay our admin staff occasionally ;-)

​

�* Why is it called HL7? Back in the day exchange systems had 7 layers, from hardware, up to software, � hence we are Health Level 7

What do we do?

Promote the use of standard ways to do healthcare data

• Spread the word
• Speak at events, universities etc.
• Represent the UK at HL7 International (ensure UK needs are met)
• Organise FHIR training courses
• next week – see www.hl7.org.uk/training-online-courses (starts 8th Feb)
• Have webinars/forums
• Advise organizations and national bodies about interoperability

​

And we create UK Standards ("we" being our members)

HL7 Standards

• We create standard ways to exchange healthcare data
• An overall standard is defined e.g. HL7 Version 2 (commonly just called "HL7")

or FHIR (or CDA, or V3)

• These define the data items that can be exchanged, and say how they are to be exchanged
• But healthcare practice varies, so one size doesn't fit all
• They don’t say how to do that in a specific context e.g. UK general practice, or Welsh Laboratory Reports
• Because those have specific requirements that HL7 International cannot know about

​

Localised HL7 Standards

• Every country is different, and every specialty/setting is different
• So, while there is a lot of commonality, local needs differ
• The differences are more about which parts of the standard to use
• It's not the case that the standard has to be changed, it's more a case of selecting which parts you need
• It is also possible to add local “extensions”

​

​

​

​

Localised FHIR

• FHIR does - necessarily - have flexibility
• It lets you use any identifier, it lets you use different terminologies (codes)
• But in a given context you will probably want to lock these down
• Perhaps to mandate NHS number, or CHI number
• or perhaps to have no number at all - if you want an anonymous research database
• So you have to decide how to use FHIR
• FHIR calls this selection process "profiling"

​

​

​

​

​

​

FHIR Profiling

• When we do some profiling (chose what parts of FHIR to use), we create FHIR “profiles”
• UK Core is a FHIR “Implementation Guide” – which is a set of FHIR profiles
• An “IG” is just a document that advises, or perhaps mandates, what projects do:
• “Use this part of FHIR, in this way”. “Use these codes and these extensions”. “Don’t use these other parts”.
• It creates a local “flavour” of FHIR
• But it does not change FHIR itself, it is just a selection process (pic’n’mix).

​

​

​

​

​

​

Quick FAQ - 1

• So - I need profiles to use FHIR?
• In fact no, not necessarily
• FHIR exists regardless of any profiles. You can just use it now.
• But profiles help you, because they are someone’s idea of what specific bits of FHIR you need. Someone who knows about your context.
• They guide you to certain parts of FHIR
• But that FHIR is always there already, and so are the other parts, if you choose to use them

​

​

​

​

​

​

​

Quick FAQ – 2

• Are profiles all I need then?
• No, because they are just a set of choices on top of FHIR’s possibilities
• When you use profiles they are just a guide to FHIR
• You are still actually using FHIR, just with some choices made for you
• There will be other choices to make!
• Perhaps you make these while implementing your FHIR
• Perhaps you will make a new IG, for others, with your extra choices.
• (But you don’t have to make your own IG, or your own profiles.)

​

​

​

​

​

​

​

​

Where does HL7 UK fit in?

• HL7 UK authorise new FHIR standards in the UK
• We are not the only ones who can use FHIR (of course)
• and we don’t control FHIR
• it’s a free and open standard for you to use
• however HL7 UK decide what is the “standard” way to use FHIR in the UK.
• HL7 is its members

​

​

​

​

​

Why Standardise?

• Do you need to use a UK standard version of FHIR?
• Technically, no. You can use international FHIR, out of the box (and make your own choices). This does work.
• But we don’t want everyone in the UK to have to work out how to localize FHIR for the UK individually. This is a waste of time (and the choices will differ).
• We want to do it once and publish it for everyone
• But there must be consensus on how to make the standard

​

​

​

​

​

​

​

Balloting

• Consensus comes from a process called "balloting" :
• A proposed standard is accepted for review
• It goes out for formal comments by members
• Any and all comments received are reviewed.
• Aim to fix all negative issues. The standard is changed, improved.
• If enough positive vs. negative comments are received, it can progress to be a standard
• Normally this starts as a “Standard For Trial Use” (STU)
• Followed by a trial use period
• We don’t mandate standards on paper – only after experience from real implementation

​

​

​

​

​

​

Quick FAQ - 3

• What happens if I build FHIR and it changes later?
• Answer - Nothing :-)
• What you build with FHIR never stops working.
• All that happens is that you may not be on the latest version (which has no impact)
• There is no time out, or FHIR police that say your older version stops working

​

​

​

FHIR Community Process

• If I do want to create an IG (and maybe a "standard" one day, but even if not) is there any guidance to a process?
• For this we have the FHIR Community Process
• See https://fhir.org/community/process

and a draft UK flavour of it is here:

• https://confluence.hl7.org/display/HL7UK/HL7+UK+FHIR+Community+Process
• These are some ground rules (non-technical) for how to be a good FHIR citizen, when making profiles for others to use (around project visibility, publication, alignment with UK Core etc.)

​

​

​

​

What do Standards give us?

• A standard implies:
• a documented consensus
• a level of expert review
• some degree of quality
• Standards are not controlled by individual organisations (HL7 is not a "individual" organisation)
• They tend not to change constantly
• ideally they make a claim about how often they may change
• So are good for basing long lived implementations on

​

​

​

​

So what is a FHIR profile again?

• FHIR is set of data structures and exchanges
• Profiles are a way to document how to use FHIR in a given context
• UK Core is a set of FHIR profiles

​

​

​

​

​

​

Thanks for listening!

rik@nprogram.co.uk

Extras

HL7 UK Standards

• Do HL7 UK make the standards?
• Often no. HL7 UK are like the curators or publishers
• Anyone can bring a standard to HL7 UK for approval
• Typically it is large organizations that have some claim to speak for the UK in some way
• e.g. a set of NHS national bodies (representing the 4 nations), or perhaps a Royal College, or PRSB or a similar body.
• But anyone can put up something as a candidate national standard
• Once again, these standards are extra guidance to help you.
• Nothing* stops you from using any parts of FHIR that are not UK standards

*except perhaps contractual obligations, or good practice ;-)

​

​

​

​

​

UK Core Profiles

• Why “Core”?
• Because it’s just a core, that "you" can start with and can use in your own more specific guide.
• Who is "you"?
• Maybe a national level program e.g. NHS England Medicines Management. Maybe a regional level programme like YHCR (Yorkshire and Humber Care Record).
• Maybe you are a company that wants to make an interface on your gene sequencer to let the lab read the data in a consistent way.
• Or you can just use them out of the box – but you will need some more choices making

​

​

​

​

​

​

​

Do I need to create an IG or Profiles?

• Probably not. Find the resources or profiles that you need and just start to do FHIR.
• Don’t start up a big effort to create an IG or profiles of your own, unless you know you will want to give these to a range of other people.
• Start using FHIR, perhaps a prototype/proof of concept, for learning.
• Once you have some experience, decide if you need to document all your assumptions as a set of FHIR profiles. You probably don’t.
• If necessary iterate between making profiles and implementing them. Don’t do waterfall.

​

​

​

What is Fire FHIR®?

​

• A brief introduction to FHIR

​

• Adam Page, Tech Modeller, NHS England 

​

​

​

Fast

(it is quick and easy to learn and implement)

​

Healthcare

(looking after things)

​

Interoperability

(making things work together)

​

Resources

(the blocks of information)�

�

FHIR®… The Acronym…

​

• FHIR is the global industry standard
• Implementations are found across the world, such as UK Core and US Core
• Implementation of the standard provides a means of sharing healthcare information between providers and systems regardless of  the setting

​

• For example: GP surgery, A&E, hospital outpatients, pharmacy, care homes

But "WHAT" is FHIR?

Resources are the basic blocks of data that make up FHIR

They are the smallest, logical unit of interest and transaction to healthcare

They have a defined behaviour and meaning

They are human readable

• Resources, when referenced together, describe a complete healthcare scenario
• For example: Patient (Lee Goman) + Observation (high temperature) -> Appointment + Encounter + Practitioner -> Condition (flu) + Medication

Built out of Resource

A Patient on FHIR vs a Patient on Fire

• The base resources cover 80% of the use cases

​

• An element is only part of the standard if 80% of implementers will use it

​

• 20% added by Profiles, Extensions, and ValueSets

​

• Profiles allow you to customize a resource to be more suitable to your need

​

• Extensions add new data elements

​

• These can be country specific, such as complex name formats

​

• Or data that is not recorded in all countries, such as place of birth or mother's maiden name

​

• ValueSets define the lists of codes that can be used

​

Resources Aren't Perfect

UK Core Overview�This section gives a high-level overview of UK Core a lot of the content is covered in more detail in the "Technical Walkthrough" later today

​

Kevin Sprague, Tech Lead, NHS England

​

• As building blocks for API’s, FHIR profiles are part of the wider Interoperability healthcare ecosystem and should be classed as strategic assets
• FHIR has the fundamental concept of ‘Resources’ or ‘Profiles’, where a resource is the basic unit of interoperability – the smallest ‘thing’ that makes sense to talk about – such as a Patient, a Condition (Problem) or a Practitioner
• Engaging the right people, in the right way and the right time is critical for successful implementation

​

​

Why are FHIR Profiles so Important?

What is a FHIR Core?

A “core” is in simple terms an Implementation Guide that defines FHIR at jurisdiction wide level.

Netherlands Transversal Clinical Core 

Belgium eHealth Core Specifications 

Switzerland CH Core  

Austria Core

Australian Base   

US Core  

UK Core 

UK Core Vision

Brief History of UK Core (The Beginning)

• As part of NHS Digital's move to adopt FHIR R4, it was proposed to rethink the current way FHIR was developed and implemented
• CareConnect (STU3) had reasonable take up, but the approach was England specific
• The use of a "Core" approach was proposed by the NHS Digital Interoperability Standards Team (IOPS) as a way forward for FHIR R4 development. 

​

2019

Brief History of UK Core (Building on CareConnect)

• FHIR R4 work was based on the CareConnect work, but with more rigorous development and assurance  processes and with the scope to be UK (4 nations)
• Initial discovery and prototyping work carried out by IOPS with input from Wales which despite delays and interruption due to the pandemic delivered a prototype implementation guide in 2020 

​

2020

​

​

​

​

Brief History of UK Core (The Challenges) 

​

​

​

​

Brief History of UK Core (The Challenges) 

• People want to solve their problem, not those of others – tight timelines etc..
• Programmes not commissioned or funded to do interoperability in most cases
• Interoperability often seen as someone else's problem

​

• Community engagement required
• Suspicion of the centre intent
• Lack of interoperability  governance
• Central Funding 
• Impact of the Pandemic

Brief History of UK Core (MIlestones)

• In 2020 following discussions with HL7 UK and INTEROpen it was agreed that the UK Core would be developed in partnership. Ownership/Copyright would rest with HL7 UK and NHS Digital (IOPS) would be the leading development partner

​

• Work started with the Digital and Interoperable Medicines Program to create UK Core Medication implementation guidance with UK scope.  

​

2020

Brief History of UK Core (MIlestones)

​

• 31st January 2023 first Balloted UK Core officially published version 1.0.0 

​

2023

UK Core is being developed in collaboration with the following organisations

​

More info:​

http://hl7.org/fhir/profiling.html​

http://hl7.org/fhir/extensibility.html

FHIR has an 80 – 20 % approach

- FHIR attempts to supports  80% of use cases

Profiling for a use case is the approved approach

- Constraining out unhelpful or unnecessary parts

- Adding missing parts using Extensions ​

Not all the standard is required for the UK

Profiling at UK level allows for more validation for UK use cases

Why not use FHIR out the box?

FHIR is a “platform standard”

“FHIR is a platform specification that defines a set of capabilities use across the healthcare process, in all jurisdictions, and in lots of different contexts.” ​

“This specification is a common platform standard that must be adapted to particular use cases. Some particular use cases are common or important enough to be described as a part of the specification itself.” 

Why use a “core”?

FHIR is normally implemented using an (IG) implementation guide for the specific jurisdiction and context (use case). The IG may use the Core approach

Encourage re-use of standard patterns for exchange of information

Stable standards can be enshrined in future commercial contracts

Design once, 

implement many times – reduce development time

Aid to development to enable patient information flow across borders

Consistency and standardisation is important for interoperability

Reduces siloed working – 4 Nations

Enables definition of UK wide search parameters for queries

Facilities creation of standard APIs for standard business functions and requirements

UK Core 

approach 

advantages 

Previous Approach (STU3)

FHIR STU3

Derived from

Care Connect

GP Connect

Derived from

Level 1

Level 2

Level 3

Transfer of Care

Child Health

Etc…

• Developed on a platform which was not FHIR aware
• Limited validation and derivation not readily testable
• All FHIR assets draft
• CareConnect Profiles cloned and derived multiple times
• Assured at a very specific English use case
• No clearly defined change control
• Never balloted

UK Core Approach Overview

FHIR R4

Derived from

UK Core

Use case IG

UK Core

Package

Use case

Package

Derived from

Valid Constraint

• Developed on a platform which is FHIR aware
• Derivation is testable
• Validation built into development 
• Validators available for implementation 
• Change control is in place for UK Core
• Packages allow for relatively easy upgrade to newer versions
• Assurance using multiple UK wide use cases
• Balloted by HL7 UK

Although technically the UK Core could be implemented as is, in  reality, implementers will use an IG derived from the UK Core for the specific use

How Content is added to UK Core

Use Case

Develop

Draft Profiles

Clinical and Technical Assurance

HL7 UK Ballot

Mainly lead by NHS Digital use cases but can be anyone's  

Proposed to be a virtual team

Anyone can get involved

Members can get involved 

Is Core the full answer....?

The UK Core is not the answer to all our interoperability problems but can be a key component by providing the resources and guidance at a UK level.

The more collaboration and  input from the wider community the better and more applicable the UK Core content will become. 

Interoperability is not just a technical thing it requires cultural or process change too. 

How is this done? – The UK Core is:

55

Profiles

Extensions

Examples

Guidance

ValueSets, CodeSystems and  ConceptMaps

Profiles

Extensions

ValueSets, 

CodeSystems and conceptMaps

Examples

Content Produced to Date

active = have been assured either by HL7 UK Ballot and/or C&TA

43 Profiles

39 Extensions 

 30 (active)

13 (draft)

38 (active)

1 (draft)

draft =  created to allow First of Types and other programs to progress 

A Clinical View of the UK Core

​

Katy Lockhart, Clinical Informatics Manager, NHS England

​

A clinician on FHIR

HL7 interoperability standard for sharing clinical information 

• content model (resources)  aka building bricks 
• exchange specification – which postal system 

​

Extending into clinical knowledge 

• decision support 
• quality measures 

​

Community support across 4 nations 

• collaboration 
• differing needs 

What is a clinical informatician's role?

Different agendas

Find commonality

Clinical risk management

Provide clinical assurance

Clinical safety

Two clinical risk management standards: 

• DCB0129 is for organisations building software 
• DCB0160 is for care organisations that are deploying and using software 

​

New UK Core hazard log on Simplifier records generic hazards: 

• UK Core Development Hazards for NHS Digital 
• UK Core Implementation Hazards for vendors

​

Clinical Safety Officer (CSO)

Development hazard example

Inconsistency with data/professional standards

​

• Lack interoperability
• Inappropriate care or delay in delivery of care

​

Mitigated by:

• C&T assurance and collaboration
• UK Core reference sets
• Appropriate use cases
• Alignment with UK Core and standards

Implementation hazard examples

Unclear headings

​

• Clinical data transfer
• Incorrect data transfer
• Critical clinical info omitted
• Incorrect info under inappropriate heading

​

Mitigated by:

• Use of current headings available in local or national systems.
• Design and testing

Clinical Benefits

 Structured Data / Standardised

Patient journey improved

Better data management to avoid duplication

Improvement in clinical treatment as information shared between providers 

Early Warning Scores

​

​

​

Early Warning Scores (FoT)

NHS Digital in partnership with two vendors in Manchester was involved in a first of type (FoT) for PEWS and NEWS2

​

• UK Core profiles 
• Generic EWS Implementation Guide
• Built and in use in less than eight weeks
• UK Core provided standardisation

​

​

Early Warning Scores

This guide is available in Simplifer  and could also be used for exchanges such as:

​

• Hospital to hospital patient transfer
• Remote monitoring
• Ambulance to Emergency Department
• Hospital look up of observations in GP systems
• Ambulance recording
• GP to Ambulance

​

​

​

The Future

Existing diagnostics draft profile 

​

New imaging profile study 

​

All radiology imaging and reports for patients across England 

• Access patient data quickly and easily 
• Improved communication with referrals 
• Efficiency 

​

Engagement with clinicians

​

Using the UK Core in Wales

​

Mark Frayne, Assistant Chief Architect, DHCW 

​

Wales Health and Care Organisations

• Population: 3.136 million 
• 391 GP Practices
• 22 Local Authorities
• 7 Health Boards
• 2 NHS Trusts

​

​

So far, for the 2022/23 financial year there have been 55350 consultant episodes recorded by English NHS Trusts for Welsh residents

Wales Single Record Architecture

Wales Single Record Architecture

Wales Single Record Architecture

How do Health Boards access this data without going through WCP?

Wales and UK Core

• NHS Wales recognises the importance of aligning standards with existing and provisional standards proposed by national and international bodies where possible.
• NHS Wales is formally adopting HL7 FHIR standard as a foundational interoperability standard where appropriate.
• In order to align NHS Wales with partners across the UK this open architecture will be aligned with the UK Core.

UK Core Patient – Wales Example

NHS Wales FHIR Implementation Guide

• To reflect Wales Data Standards, we are developing an NHS Wales FHIR Implementation Guide, derived from UK Core.
• The guide will contain additional Wales-specific extensions that reflect Wales Data Standards, and that support local and national architecture.
• The guide will contain examples FHIR resources that  reflect UK Core and Data Standards Wales FHIR profiles.
• The guide is currently in development, but proposed roadmap sees v1.0 STU 1 available March/April 2023.

​

https://simplifier.net/guide/fhir-standards-wales-implementation-guide?version=current

Break back @ 11am

Reminder to add and vote on any questions so far to Mentimeter for the morning Q&A session 

UK Core Assurance Governance and Endorsement

​

Kevin Sprague, Tech Lead and Dave Crampin, FHIR Product Owner both NHS England

​

UK Core Learnathon 23

Assurance 

​

Clinical and Technical Assurance (C&TA) Presented by Kevin Sprague

• What it is 
• Why do it 
• Detailed walkthrough of the process 
• How to get involved

​

What is C&TA and why do it ?

An NHS England (NHS Digital) process run as a precursor to the HL7 UK Ballot process. It replaces the "Curation" process used for CareConnect and is a process to assure the content of a UK Core IG for a set of example use cases to ensure its content is: 

​

• Clinically correct and safe to implement  
• Technically correct in design and aligned to the FHIR Standard and other standards where appropriate 
• Aligned with the common understanding of the example use cases across the UK 

​

​

Anyone involved in 

FHIR implementations 

​

Who should be involved?

Anyone who is a

SME in the scope of the C&TA 

​

Anyone who has any interest in shaping the UK Core 

 Numbers are not limited

How to get  involved in C&TA Sprints 

Submit a use case for consideration (which is applicable to scope of the sprint) 

AND/OR 

Join the C&TA Calls 

AND/OR 

Take part in the 3-week C&TA review 

​

The higher the level of engagement the better the outcome!

Detailed walkthrough of the C&TA process

Open

Engagement 

Limited

Engagement  

Internal Process 

External Process 

Limited

to the UK Core Development Team, certain organisations, and  public bodies 

Open to anyone, currently no limits on  

numbers or attendee roles  

Open 

Engagement 

Open 

Engagement 

Open 

Engagement 

Summary

C&TA is a way of influencing the UK Core development and the higher the participation and wider the diversity of participants, the better the outcome for all.

Governance and Endorsement 

​

Dave Crampin, FHIR Product Owner, NHS England

​

​

​

​

​

Governance and Endorsement

UK FHIR Board

UK FHIR Delivery SLT

(Data Alliance Partnership Board)

DAPB 4020

HL7 FHIR® UK Core Design and Development Approach (simplifier.net)

UK FHIR Board

(Policy and Strategy)

UK FHIR Board - Guiding principles

​

​

• The Board sets the strategic direction for, and encourages the development of, FHIR artifacts for use in the UK.
• The Board takes into account the views of significant representative bodies with a legitimate interest in the use of FHIR in the UK.
• The Board does not directly fund, or control the funding of, development work.
• The work of the Board is consistent with the aims and objectives of HL7 UK.
• Artifacts generated by the Board, or its member bodies will, if suitable, be submitted to HL7 UK to be approved as balloted and approved as HL7 UK Standards.

​

UK FHIR Delivery

 Senior Leadership Team

(FHIR Development)

UK FHIR Delivery SLT – Main functions

​

​

• Implementing the direction and instructions set by the UK FHIR Board
• Advise on setting the prioritisation and roadmap of the FHIR UK Core
• Approval of changes to UK Core FHIR assets as part of the change control process
• Setting the prioritisation of changes to previous versions of FHIR assets
• Approval of changes to previous versions of FHIR assets (e.g CareConnect), as part of the change control process
• Overseeing the migration path of previous versions of FHIR assets to the UK Core FHIR assets

​

… (continued)

​

​

​

UK FHIR Delivery SLT – Main functions �...(continued)

​

​

• Making decisions where consensus cannot be reached as part of the change control process
• Assure that engagement and consultation with the wider FHIR community has been correctly facilitated, so that the UK FHIR Core and changes to previous versions of FHIR assets meets the requirements of the FHIR community
• Escalate issues to the UK FHIR Board as required based on level of risk

​

​

Data Alliance Partnership Board (DAPB4020)�and the DSAS process (Data Standards and Assurance Service)

​

An endorsement of the UK Core approach, as a "fundamental standard" for England

​

• This means that it's not the content of UK Core that is covered by the standard, but the governance and development approach used
• Care Settings, Software, and system suppliers do not need to deliver anything based on this standard*

​

* Note there may be other processes or contractual agreements that mandate use of UK Core for some programs or implementations

​

More Information about DAPB4020 Data Standard

​

​

Why do it?

• The Data Standards and Assurance Service sits in the unusual position of seeing all the information proposals in place or planned, and can assist in ensuring dependencies are considered and managed
• We took the UK Core Governance through this process to: 
• ensure the governance of UK Core development, takes account of all the requirements of an information standard, such as consultation, clinical risk, interdependencies, other information standards
• ensure the baseline standard is fit for purpose (i.e., the solution fits with all the other areas of the NHS and the wider service, and hasn’t missed any points that could cause conflict later)

​

In short, to ensure it is a standard where implementation can be successful in a wide variety of situations and circumstances.

​

DAPB and UK Core Development Team

​

​

​

​

​

The DAPB standard mandates that the UK Core Development team: 

• Follow the guidance and rules detailed in the UK Core Design and Development Guide  when creating and maintaining UK Core content   
• Carry out and maintain (update) the processes documented within the UK Core Design and Development Guide as required in line with new or changes to existing tooling
• Update the content of UK Core Design and Development Guide in an appropriate way as and when required
• Provide proof (audit logs etc) of adherence to the UK Core Design and Development Guide guidance and processes
• Engage with the FHIR community (both UK and International)

​

Q&A

​

​

​

​

Using the UK Core in major NHS England programmes

Dave Crampin - Host

BARS – David Ruddy, Adnan Riaz

EPS – Ameya Krishnamoorthy, Matthew Popat, Anthony Brown

Digi Meds – Chris O Brien

​

UK Core Learnathon 23

• BaRS offers a universal standard way to digitise booking and referral workflows everywhere

​

• BaRS is based on FHIR R4 and uses UK Core

​

• It is a set of instructions, rules and guidance on how to use the building blocks of FHIR to digitise workflows

​

• It is policy in England for BaRS to be adopted as the ubiquitous standard for wherever booking or referral type of flows happen

​

• This provides a framework for all vendors to build solutions in a way that guarantees compatibility

The Booking and Referral Standard (BaRS)

The Booking and Referral Standard (BaRS) cont.

• BaRS has a “dynamic payload” philosophy utilising “on-the-fly” content negotiation and can support any information that is required, the only boundary that is set, is that the information must be compliant with UK Core and all profiles are dependent children of UK Core.

​

• UK Core has enabled BaRS to standardise the way information is encoded whilst maintaining the necessary flexibility

​

• Lack of adoption of UK Core in the supplier community has been the main challenge

​

• Wider adoption of UK Core based standards like BaRS should help to drive the standardisation of healthcare systems data towards UK Core

​

• BaRS is currently live with 111 Online referring (with bookings) into ED’s and BaRS is being actively worked on by at least 16 different vendors across several different care settings

​

• Greater direct engagement between the UK Core project and supplier communities to raise awareness, understanding and encourage adoption would greatly improve healthcare interoperability in the UK

​

  Further information

BaRS Programme :

​

https://digital.nhs.uk/services/booking-and-referral-standard  

​

Implementation Guide and Technical Documentation :

​

https://simplifier.net/nhsbookingandreferrals 

111

Electronic Prescription Service (EPS)

Where it’s used

• FHIR Façade, based on UKCore, sitting in front of v3 interface
• Includes Prescribing, Dispensing and Claims for Primary/Secondary care and Acute, Repeat and eRD prescriptions

​

Advantages to using UKCore

• Allowed EPS to ensure our FHIR resources conformed to UK standard and are interoperable with other services, if needed – e.g. CommunicationRequests and NHS App
• Including MedicationRequest, MedicationDispense, PractitionerRole, Practitioner, Organization etc. 
• Implementation Guides helped with understanding models

​

First of Type examples

• Medicus, Apotec, IC24 in beta with prescribing API
• Work started to expand to Welsh prescribers and integrate with NHS App

​

Electronic Prescription Service (EPS) cont.

Challenges we’ve had using UKCore within the NHS/EPS

• Canonical URLs not resolving meaning links to StructureDefinitions cannot be followed
• Not easy to correlate examples to EPS use cases
• Having multiple sources of truth (i.e. NHSD IGs and UKCore IGs) can sometimes lead to confusion
• Complex messages result in Bundles of Bundles making them hard to traverse (batch release) – complexities of a facade
• V3 mapping guidance missing (essential for a façade), some v3 interactions don’t sit neatly in FHIR resources without refactoring

​

Possible Contributions

• Help set up Reverse Proxy for fhir.hl7.org.uk and fhir.nhs.uk domains for UK Core and NHS IG assets
• Provide broader range of examples which match Programme use cases
• Provide clearer guidance on how derivative IGs should be used
• Provide guidance on use of messages and v3 mappings in IGs

​

What we’d like to see

• Full day Learnathon for Developers
• Additional programme specific presentations on how FHIR is used within NHS Digital/England

​

  Further information

EPS Programme​:

​

https://digital.nhs.uk/developer/api-catalogue/electronic-prescription-service-fhir

​

Implementation Guide and Technical Documentation​:

​

https://simplifier.net/guide/nhsdigital-medicines

114

​

FHIR UKCORE to support medicines interoperability

Digital and Interoperable Medicines

Medicines Interoperability Vision 

“Safer, more joined up care through the seamless, digital flow of patient medicines information across health and care;

​

improving patient experience, reducing burden for health and care staff and increasing opportunities for research.”

Medicines touch every aspect of care

Medicines Interoperability Standards

Primary care: Product based prescribing for item specific Dispensing & Patient administration instructions

Secondary care: Dose based prescribing – flexibility of Supply options and Nurse administration timing

Integrated Care System

Why we need medicines interoperability

Developing the standard

Building the reusable Puzzle Pieces

Foundation Standards

+ Other FHIR Resources

FHIR Medication Resources

& Instructions / Guidance

HL7 Fast Healthcare Interoperability Resources (FHIR) is the recommended standard for NHS clinical interoperability, i.e. “messaging”

UKCore-Medication

UKCore-MedicationRequest

UKCore-MedicationRequest

UKCore-MedicationAdministration

UKCore-Immunization

UKCore-MedicationStatement

Why FHIR UKCore

HL7 FHIR is an international standard, which improves on previous HL7 standards (e.g. HL7v2 and HL7v3) with more comprehensive data models (known as Resources) plus Application Programme Interfaces (API) within the standard,

i.e. what data is shared and how to share it.

​

A significant feature FHIR provides for medicines interoperability is a comprehensive and understandable data structure to express a machine-readable dosage instruction.

​

FHIR UKCore provides a standard tailored to fulfil specific UK service needs, whilst supporting international interoperability

​

​

​

​

“Consolidated” or “Summary”

Clinical System

“Shared”

Electronic Patient Record

Consolidated / Shared Record

Electronic Patient Record

Electronic Patient Record

Clinical System

Clinical System

Local data, where no use case to share

“Integrated”

COPY / SYNC

COPY / SYNC

MASTER

Electronic Patient Record

MASTER

MASTER

“Federated” or “Virtual”

Clinical System

Electronic Patient Record

MASTER

Shared Record

QUERY

• EPR resides with the clinical system vendor
• Relevant summary of the record is copied to the consolidated or summary shared record on specific trigger events, e.g. acute discharge, clinical consultation, etc.

• EPR resides with to the clinical system vendor
• The majority of the EPR is copied to the shared EPR on specific trigger events, e.g. acute discharge, clinical consultation, etc.

• EPR resides with the shared record vendor
• Clinical system vendor local data reduced to just that where no use case to share with the wider NHS

• EPR resides with the clinical system vendor
• Records are not copied or persisted
• The shared record queries for data on demand

UKCore supports varied approaches

Scotland and Wales are planning 

single instances 

of shared records.

Changing care models mean there will be a

greater need for information to flow between clinical systems both within a locality as well as across regional borders

​

The use of FHIR UKCore, with supporting implementation guidance and technical specifications will provide a foundation for

Interoperability to be achieved 

at both Local and National levels 

We need to support joined up care

England is planning 

X 42 

Integrated Care Systems (ICS)

Further Information

​

​

Digital and Interoperable Medicines Programme:

​

https//digital.nhs.uk/services/digital-and-interoperable-medicines

​

​

Implementation Guide and Technical Documentation:

​

https://simplifier.net/guide/ukcoreimplementationguideformedicines

Lunch back @ 1pm

UK Core Technical Walkthrough

​

Kevin Sprague, Tech Lead, NHS England

​

What we will cover

​

• Development Platforms (Simplifier & GitHub) 
• Documentation Overview
• Versions and Sequences
• The Implementation Guides
• Packages

​

Simple sign up option

• Simplifier is FHIR aware as it is based on a FHIR server 
• Interfaces directly with the FHIR profiling tooling 
• Gives an audit trail with diffing 
• Subscribers can track development progress, news items, and can leave feedback
• Subscribers 

Why use Simplifier?

• Validation  and Quality Control is built in 
• Dependencies, Supports multiple dependences for projects and IGs  

Which enables an IG that is derived from UK Core to be validated for correct derivation

• "FHIR Query Language" (FQL) 
• Supports multiple FHIR versions 
• NPM Package Management

Why are the benefits of using a FHIR Based Platform? 

FHIR Query Language

• Supports the use of “FHIR Query Language” (FQL) for rendering and embedding content in IG

​

• For example, this allows you to query a profile for all the elements that use reference datatype and display in a table of a page. 

​

• https://simplifier.net/fql for more detail 

NPM Package Management

• Full support for packages with versioning (using Semver)
• Includes maintenance (deprecation etc) and download

​

For more on Semver see https://semver.org/ 

For more on NPM see What is NPM

Style and Accessibility

• Supports multiple stylesheets with easy switching
• Supports a team of developers with access level management
• Has some built in accessibility and supports more with stylesheets etc. Interfaces with /supports/promotes https://wave.webaim.org/

https://registry.fhir.org

FHIR Standard Releases 

The FHIR standard uses the following release designations: 

​

• DSTU – Draft Standard for Trial Use (for example DSTU2)
• STU – Standard for Trial Use (STU3)
• R – Release (R4)

​

• The number indicates the FHIR major version.

UK Core Sequences and FHIR Releases 

UK Core sequences use FHIR releases too, which should not

be confused with FHIR standard releases.

​

​

• UK Core uses STU(n) where n is the number of the sequence not the major version of the FHIR standard
• i.e. STU1, STU2, STU3 etc.. but they are all FHIR R4 (FHIR full version is 4.0.1)

?

?

?

?

?

?

?

?

?

UK Core Version History

• The best place to start for UK Core versions 
• This is where you should hyperlink to as the URL is stable. 

​

UK Core Hazard Log

Catalogues potential clinical safety issues and hazard that implementers of UK Core need to be aware of and mitigate in their implementations 

​

​

UK Core Design and Approach

• Explains how and why the UK Core development is done the way it is
• This is a ISN for England see previous slides  

​

​

UK Core Implementation Guidance Directory

• List of other documentation you might need or find useful if implementing the UK Core

​

​

A UK Core Implementation Guide

Breakdown

• Guidance: information about DataTypes etc..
• Profiles and Extensions: details all the profiles and extensions in scope for this release
• Terminology: All about ValueSets , CodeSystem and ConceptMaps used in the profiles and extensions
• Examples: An index of the included examples
• Downloads: provides a link to the latest package for this IG

​

​

​

​

A UK Core Profile Page

• SnapShot: The normal profile view
• Differential: Shows only the changes to the base resource
• Hybrid: A mixed view of the first two
• Table: A table style view of the profile
• XML: An xml view
• JSON: A JSON view
• Examples: Link to example 
• Instances

​

The LHS links are to bookmark further in the page where there is more guidance. Only appear if there is additional guidance to the base Standard provided

​

​

​

​

A UK Core Profile Page

Example changes to base include:

• Extensions have been added
• Bindings changed ( constrained further)
• References changed from base resources to UK Core profiles
• Note: UK Core never removes elements unless agreed as clinically not safe or useful for UK use

​

​

​

​

UK Core Versions and Sequences 

See UK Core Version History

​

Implementation Guide (IG) Versioning

• Format is - n1.n2.n3.
• n1 = Only used for a version which contains content which has been balloted
• n2 = A version in development 
• n3 = A patched version ( currently not used)

For example, 1.1.0 contains some previously balloted content but is still in development  

Sequences

• A sequence is a UK Core development cycle, there will be multiple (potentially parallel) sequences
• Currently the UK Core has 3 cycles in development:
• STU1 - Balloted
• STU2 – In development (Preparation for Ballot 2)
• STU3 – In development (Preparation for C&TA Sprint 6) 

Implementation Guide (IG) Development Cycle

​

• Current Build – the latest development build of the UK Core, may be incoherent and change rapidly
• Pre-release – a build for external review or approval
• Current Release – a version which has been balloted by HL7 UK 
• Historic – A old version(superseded) which should not be implemented kept for audit purposes etc.

Sequences

Implementation Guide Versioning

Implementation Guide Versioning

Early prototyping done by NHS Digital

Progress to Date

STU1 Progress to Date

STU1 Content

STU2 Progress to Date

STU2 Content

STU3 Progress to Date

STU3 Content (Planned)

Packages and Implementation Guide Releases

Packages Contents

We currently issue two types of Packages:

​

1. A Package tied to a particular IG release – allows testing for conformance to a particular release of UK Core such as 1.0.0 
2. A Package tied to the latest development of Core – allows validation of implementations that do not conform to a particular release of UK Core for examples First of Type(FoT) use

​

Note: Examples may be included in the second type.

​

Package Versions Tied to a Release

Package Names for Packages Tied to a Release

Package Names for Packages not Tied to a Release

• These UK Core packages contain all UK Core FHIR assets (active and draft)
• These are used for wider validation against the latest UK Core development
•  Available/linked from a page in the Version History and clearly identified
• As the current build is not part of an actual release it is marked as a pre-release to indicate the fact in the version within Simplifier. 

• Old packages are unlisted (deprecated) hidden but never deleted and are findable with URL
• UK Core packages contain all UK Core FHIR assets (active and draft)
• Best place to get the correct package is from the Version History pages 

Package Cycle for Packages

Version

Description, i.e. which UK Core IG release is it for 

Project, which sequence it is for 

FHR Version R4 v4.0.1

Release Notes : The only editable part of a released package

Version

Description, in this case it's not a release

Project not a sequence just the base project 

FHR Version R4 v4.0.1

Release Notes : The only editable part of a released package

Claiming Conformance to UK Core (Proposal)

• Claiming UK Core conformance is done on a self-claim basis by creators of derived IGs claiming conformance to UK Core.
•  Implementers of derived IGs may also claim conformance to UK Core  
• The claim to conformance to UK Core is not tested by HL7 UK or the UK Core Development Team, however a list of  Implementations and IGs claiming conformance is proposed to be published in the public Domain

​

Example entry in proposed registry

Why Claim Conformance

​

• Allow for the identification and depreciation of packages / or IGs that are not used by any implementation
• Provide an indication of the number of implementations of the UK Core
• Provide contact points for UK Core implementers
• Allow for tracking and impacting of changes to UK Core on known implementations
• Provide a registry of all UK Core implementations
• Illustrates and promotes the derived implementation
• Provides a means of showing use cases for UK Core for sharing and collaboration.

​

​

​

​

Use Case

Mapping to FHIR

Create /  Update FHIR Profiles and Other Assets

Create /Update Implementation Guide 

C&TA

HL7 UK Ballot

UK Core Release

Update FHIR Profiles and Other Assets

Update Implementation Guide 

Update FHIR Profiles and Other Assets

Update Implementation Guide 

UK Core Maturity 

Implementations should track and align with UK Core Maturity 

UK Core the Future Roadmap

​

Kevin Sprague, Tech Lead, NHS England 

​

Clinical and Technical Assurance Sprint 6

Scope is Diagnostics

Current use cases include:

• NHS England - Pathology
• NHS England -  Genomics
• NHS Wales - Diagnostics – lab and imaging data

​

​

​

Goals for Sprint 6

Assurance of Profiles

•ImagingStudy

•FamilyMemberHistory 

•Specimen

•DiagnosticReport*

•Observation*

•Consent

•Service Request**

​

* Some sub-profiles may be required.

** Previously went through C&TA for (BaRs) use case in Sprint 5.

​

​

Determine whether Profiles are required for:

•Endpoint

•Subscription

​

Build on the release development of the FHIR UK Core Implementation Guide R4 Versions:

​

1.0.0 Ballot 1 (Completed) 

1.1.0 Ballot 2 (In Development)

​

Other Profiles

Build on HL7 UK Ballot release

Sprint 6 Dates

• Sprint 6 Development and Preparation -1^st Jan-15^th Feb
• First kick off call -15^th Feb 11:00-13:00 
• Second call -16^th Feb 11:00-13:00
• Third call - 21^st Feb  11:00-13:00 
• Review period (3 weeks) -27^th Feb-20^th Mar
• External consultation call -28^th Mar 09:30-11:30
• Retro/Lessons Learned call -4th May 10:00-11:00

​

Sprint 6 Estimated timeline

​

Jan 2023

Feb 2023

Mar 2023

Apr 2023

May 2023

IG and Sprint Document Pack Development work

Sprint Calls X3

3-Week Review

IG Rework and Pre-release

Consultation Call

2 Week Review

Rework of Pre-release

HL7 UK Ballot

To Get Involved in Sprint 6 

Contact us

​

​

ukcore@hl7.org.uk 

or

interoperabilityteam@nhs.net

​

to get the invites to the calls etc.

​

​

See news items on Simplifier 

​

Subscribe to UK Core in Simplifier

​

Sign up to RYVER

More Information

UK Core: How to get involved with the future development 

The Future RoadMap Current Thinking  

Tooling & APIs

​

• Tooling for testing and validation

​

• Reference Implementations

​

• APIs

​

• HL7 UK Core Patient FHIR access

​

​

​

Support for other Clinical processes such as:

​

• Admission and discharge 

Notifications

​

• Care plans 

​

• Remote patient monitoring

​

​

​

​

​

Technical Implementation Group.

​

​

​

​

Clinical Focus 

Forums/Interaction

​

More Information We Would Like From You

​

Technical Implementation Group.

​

A proposed new group that is vendor / developer / implementation focussed and allows anyone to raise points of interest, challenges etc.. related to implementing UK Core 

​

​

Forums/Interaction

​

Tooling Examples

Creating validation tooling for use by developers for testing FHIR implementations 

​

FHIR test servers with UK Core test data on to allow testing of RESTful operations , queries etc..

​

Common APIs based on UK Core

​

​

​

​

​

​

Clinical Processes 

Notifications when a patient is admitted to or discharged from secondary care

​

Care Plans is a big area so need to have a focus such as Personal Care and Support Plans

​

Monitoring a patient's vital sign at home after discharge from hospital, virtual wards, Telehealth etc..

​

​

​

​

​

​

Ready to get involved ?

Tooling to Assist Implementers

What tooling would you like to see developed to assist implementation of UK Core?

​

• Validation and Testing tools
• APIs
• FHIR test servers with UK Core test data
• Other (please specify)
• Don't need any

Clinical Processes

1. Is using clinical processes as a  basis for the UK Core development a good approach?
2. Which if any of this list would  you like to be supported in the UK Core?
1. Admissions and discharge notifications 
2. Personal Care and Support Plans 
3. Remote Patient Monitoring
4. Other
3.  Which other would you like? 

Technical Implementation Group

1. Is there a need for a technical implementation group? (Yes or No)
2. What format would be best
1. Monthly workshops
2. Regular calls
3. Lunch and learns
4. Forums
5. Other (please specify)

​

​

​

​

Intro to the Hackathon

​

David Hancock, Digital Health Strategist, New Found Consulting Services Ltd 

UK Core Learnathon 23

Introduction to the Hackathon

David Hancock, Digital Health Strategist, New Found Consulting Services Ltd

​

2021

MEDICATIONS

TERMINOLOGY SERVER

​

MATERNITY & PHR

​

MEDICATIONS

SHARED CARE PLANS

SOCIAL CARE 

IDENTITY/�WORKFORCE

BOOKINGS & REFERRALS

​

UK CORE

​

NON-TECH LEARNATHON

�LEARNATHON ONLY��HACKATHON ONLY

2021 Activities

2022

SOCIAL CARE

IDENTITY/�WORKFORCE

BOOKINGS & REFERRALS

​

​

NON-TECH LEARNATHON

�LEARNATHON��HACKATHON

MEDICATIONS

2022 Activities

2023

MEDICATIONS

IDENTITY/�WORKFORCE

NON-TECH LEARNATHON

�LEARNATHON��HACKATHON

UK CORE

Timeline – Planned Events

Introduction to the Hackathon

▶In Person at Digital Health Rewired at the Business Design Centre in Islington on 14^th – 15^th March

▶You do not need to pay to attend the Hackathon

▶Once we have agreed the use cases and scenarios we are going to Hack against you decide which use case and scenario you want to do.

▶We will have weekly calls to plan the Hack which you would find it very helpful to join.  Find details on Ryver

▶Before the event or at the event you agree with what other organization(s) you want to work with on the Hack

▶You have around 1.5 days of Hacking with presentations of your Hack at the end and prizes are awarded to the winners.

▶There are spaces for 80 people

​

Reasons to Come to the Hackathon

▶Use it to understand what it will take to deliver product-ready functionality so you can more accurately plan it into roadmap and understand changes required in your solutions

▶Integration with National Systems that use UK FHIR Core

▶Use it as a spike to solve a specific customer problem so you can solve it more quickly and implement it faster for a customer

▶Meet those people responsible for developing UK FHIR Core and applying it in National Systems

▶Learn from and with other Developers on how to make this all work

​

​

​

Use Case Definition for the Hackathon

What would you like to Hack with UK FHIR Core?

Use Case Definition

Gathering use cases to Hack

​

David Hancock, Digital Health Strategist, New Found Consulting Services Ltd

​

Kevin Sprague, Tech Lead, NHS England – Clinical Observations (Early Warning Scores)

​

What's in the UK Core that you can use?

This UK Core based guide around Clinical observations (Early Warning Scores) is available in Simplifier.  This IG was used for a First of Type (FoT) using UK Core profiles with some detailed guidance and could also be used for exchanges such as:

​

• Hospital to hospital patient transfer
• A vital signs app to an Electronic Patient Record in a hospital
• Hospital look up of observations in GP systems. This will enable hospitals to import the Vital Signs observations from GP Systems to build a single record of observations around a patient, to provide a baseline and trends available to all.
• Ambulance recording on remote devices and communicating to central ambulance record
• GP to Ambulance

​

​

Clinical observations - Use Cases for hackathon 

​

1. A Patient is discharged from hospital and remote monitoring is set up for some vital signs with early warning scores calculated to raise alerts if the patient suffers a relapse of their condition deteriorate. This could be for several conditions such as COVID, Asthma, Hypertension etc..

​

• A child has a chronic illness and is sent home for a weekend with family, with remote monitoring which could alert the hospital using PEWS early warning scores if their condition deteriorates while away from hospital. 

​

​

Engagement with you 

​

​

​

​

​

We want to hear your thoughts on the cases :

​

​

1. Vote on your favorite use case

​

• Are there any additional use cases to hack that haven't been suggested?

​

• What would be needed for you to hack these use cases at the hackathon? e.g. Reference FHIR server, validator, suggested standard.

Wrap

​

David Hancock and Dave Crampin 

​