INTEROPen FHIR Curation WorkFHIR Profile First of Type Implementation Sites GDEs TRUSTS + ACUTE EPRS...

3

INTEROPen FHIR Curation WorkDr. Munish Jokhani – FHIR Curation Clinical Engagement Lead, NHS Digital

Agenda

• Use cases(Transfer of Care & GP Connect)

• What is FHIR curation/Why do we need curation?

• How: Overall curation process• Examples

• Next steps and Summary

4

Transfer of Care

eDischarge Summary

Mental health eDischarge

Emergency Care eDischarge

Outpatient letters

GP connect vision

What is FHIR Curation/Why do we need it?• What :

• Mapping use cases to FHIR resources (with SNOMED CT bindings).

• Why: – The curation process will produce a FHIR profile that is fit for purpose as it has had

clinical, terminology, technical and vendor input.

– It helps those who will be implementing the headings understand the rationale and details behind the content. It also challenges the clinical requirements where they are insufficiently detailed, resulting in a more robust definition.

– Supports consistency in the FHIR profiles and the value sets used; this supports interoperability.

– Create a working group of clinicians, clinical informaticians, technical modellers , terminologists, clinical safety and vendors working together and sharing and best practice.

7

Key inputs

● Strategic Overview

● Use Cases including description of clinical workflows and key

interactions

● Clinically assured (e.g. PRSB) Information models/datasets

● Patient journeys with example clinical content

● Architecture overview

● Initial list of FHIR resources for use cases

● Initial plan including deployment approach

● List of engaged vendors and First of Type sites

How?

CLINICAL MODELLING

e.g. Allergies and adverse reactions

In eDischarge summary

CareConnect FHIR Profile

First of Type Implementation Sites

GDEs TRUSTS + ACUTE EPRS + GP Vendors

PHASE 1 mapping proposal

CLINICAL(PRSB)FHIR TECHNICALTERMINOLOGY

CLINICAL SAFETY

PHASE 2INTEROPen communityFeedback(e.g. Vendors)

PHASE 3 approvedINTEROPen webex call

or workshop

Maintenance

Vendors

• EMIS, Vision, Microtest

• Cerner, Epic, DXC, Stalis, IMS Maxims, OpenEHR

• Orion, InterSystems, Healthcare Gateway

Resources completed

Patient Medication Statement

Practitioner Medication

Encounter Medication Request

Practitioner Role AllergyIntolerance

Location Condition

Organisation Procedure

Composition

List

Example: Clinical Information Model :Allergies and adverse reactions

AllergyIntolerance

Active Allergies :Transfer of care

Allergies Negation:Transfer of care

Key outputs

● Design Decision Matrix (DDM) with agreed design decisions/actions

(e.g. FHIR extensions, cardinality restrictions, valusets etc.)

● Agreed SNOMED CT/dm+d value sets/refsets

● Implementation guidance

● Changes in the proposed information models

Design Decision Matrix

Published CareConnect Profiles

Next Steps

• Reasonable Adjustments

• Digital Medicines : Pharmacy to GP

• Digital Child Health

• Pipeline e.g. Maternity, Pathology

Links

• Lessons Learnt Presentation

• Full Feedback Results

• NHS Digital Recognition Award

Summary and Next steps

• Collaborative and constructive consultation process with wide & enthusiastic Participation.

• Transition to Business as Usual/Service with revised process and review tooling.

• Essential. No one organisation could do it with any hope of a workable outcome.

21

22

FHIR ReviewDr. David Hay – FHIR Strategist, Orion Health

About me

▸ Medical Doctor

▸ Chair Emeritus of HL7 New Zealand

▸ Co-chair FHIR Management Group

▸ Product Strategist Orion Health

▸ Blog: fhirblog.com

▸ Tooling: clinFHIR.com

FHIR review

• Review of FHIR Basics

• Exchange Paradigms

• Documents

• GDPR

• Associated standards

• Profiling

• Where is FHIR going

What is FHIR

‣ Fast Healthcare Interoperability Resources

‣ An HL7 Interoperability Standard

‣ For sharing clinical and administrative information

‣ 2 main parts

‣ Content Model (Resources)

‣ Exchange Specification

‣ Supported by a (very) large community

‣ Chat.fhir.org

Where does FHIR fit with other HL7 standards?

1980 1990 2000 2010 2020

FHIR

CDA

V3

V2

V2

1987

Start V3

1995

V3 CDA

2005

Fresh Look

2011

FHIR Release 3

2016

Resources: What are they?

‣ The Content model

‣ The Thing that is exchanged

- Via REST ( FHIR Restful API), Messages, Documents

‣ Informed by much past work inside & outside of HL7

- HL7: version 2, version 3 (RIM), CDA

- Other SDO: openEHR, CIMI, ISO 13606, IHE, DICOM

Clinical Resource types

General

AllergyIntolerance

Condition (Problem)

Procedure

ClinicalImpression

FamilyMemberHistory

RiskAssessment

DetectedIssue

Care Provision

CarePlan

CareTeam

Goal

ReferralRequest

ProcedureRequest

NutritionOrder

VisionPrescription

Medication & Immunization

Medication

MedicationRequest

MedicationAdministration

MedicationDispense

MedicationStatement

Immunization

ImmunizationRecommendation

Diagnostics

Observation

DiagnosticReport

ProcedureRequest

Specimen

BodySite

ImagingStudy

Sequence

Maturity model

Resource instance example

Resource Identity &

Metadata

Human Readable

Summary

Extension with URL to

definition

Structured Data:

• MRN

• Name

• Gender

• Birth Date

• Provider

XML and JSON

<valueString value=“jedi”/>

References between Resources

Patient

Diagnostic reportCondition

Subject

ReportReason

EncounterPerformer

Encounter PractitionerLocation

PROCEDURE

Location

Resource type structure in the spec

‣ Datatypes in resource type

definition

- Backbone element

- ‘choice’ data types

Data types: Primitive

Based on w3c schema and ISO data types

▸ Stick to the “80% rule” – only expose what most will use

– Simplified

instant

Value : xs : dataTime 0..1

time

Value : xs : Time 0..1

date

Value : xs:gYear [xs:gYearMonth | Time 0..1

dateTime

Value : xs:gYear [xs:gYearMonth | xs:date | Time 0..1

decimal

Value : xs : decimal 0..1

integer

Value : xs : int 0..1

Element

Extension : Extension 0..

boolean

value : xs:boolean 0..1

string

Value : xs :string 0..1

uri

Value : xs :anyURI 0..1

base64Binary

Value : xs : base64Binary 0..1

unsignedint positiveInt code id oid

Ratio

numerator: Quality [0..1]

denominator: Quantity [0..1]

Quantity

value: decimal [0..1]

comparator: code [0..1] QuantityComparator!

units: string [0...1]

system: uri [0..1]

code: code [0..1]

Range

low: Quantity(SimpleQuantity) [0..1]

high: Quantity(SimpleQuantity) [0..1]

HumanName

use: code [0..1] NameUse!

text: String [0..1]

family: String [0..*]

given: String [0..*]

prefix: String [0..*]

suffix: String [0..*]

period: Period [0..1]

Identifier

use: code [0..1] IdentifierUse!

type: CodeableConcept [0..1] IdentifierType+

system: uri [0..1]

value: String [0..1]

period: Period [0..1]

assigner: Reference [0..1] Organization

Address

use: code [0..1] AddressUse!

type: code [0..1] AddressType!

text: string [0..1]

line: string [0..*]

city: string [0..1]

district: string [0..1]

state: string [0..1]

postalCode: string [0..1]

country: string [0..1]

period: Period 0...1

Coding

system: uri [0..1]

version: string [0..1]

code: code [0..1]

display: String [0..1]

userSelected: boolean [0..1]

Elementextension:

Extension 0..*

Timing

event: dataTime [0..*]

code: CodeableConcept [0..1] TimingAbbreviation?

Repeat

bounds[x]: Type [0..1] Duration|Range|Period

dount: Integer [0..1]

dountMax: integer [0..1]

duration: decimal [0..1]

durationMax: decimal [0..1]

durationUnit: code [0..1] UnitsOfTime!

frequency: integer [0..1]

frequencyMax: integer [0..1]

period: decimal [0..1]

periodMax: [0..1]

periodUnit: code [0..1] UnitsOfTime

dayOfWeek: code [0..*] DaysOfWeek!

timeOfDay: time [0..*]

when: Code [0..*] EventTiming!

offset: unsginedInt [0..1]

ContactPoint

system: Code [0..1] ContactPointSystem!

value: String [0..1]

use: Code [0..1] ContactPointUse!

rank: PositiveInt [0...1]

period: Period [0..1]

CodeableConcept

coding: Coding [0..*]

text: String [0..1]

Attachment

contentType: Code [0..1] MimeType!

language: Code [0..1] CommonLanguages+

data: base64Binary [0..1]

url: uri [0..1]

size: unsignedInt [0..1]

hash: base64binary [0..1]

title: string [0..1]

creation: dateTime [0..1]

Period

start: dateTime [0..1]

end: dateTime [0..1]

SampledData

origin: Quantity(SimpleQuantity) [1..1]

period: Decimal [1..1]

factor: Decimal [0..1]

lowerLimit: Decimal [0..1]

upperLimit: Decial [0..1]

dimensions: Positivelnt [1..1]

data: String [1..1]

Data types: Complex

Signature

type:Coding [1..*] Signature Type?

when: Instant [1..1]

who[x]: Type [1..1] uri |

Reference(Practitioner|Related

person|PatientDevice|Organization)

onBehalfOf[x]: Type [0..1]

uri|Reference(Practitioner|RelatedPers

on|Pateint|Device|Organization)

contentType: code [0..1] MimeType!

blob: base64Binary [0..1]

Annotation

author[x]: Type [0..1]

Reference(Practitioner|Patient|

RelatedPerson)|string

Time: dateTime [0..1]

Text: string [1..1]

repeat

[0..1]

Complex datatype example: HumanName

Terminology: FHIR and SNOMED

Code System:

Defines a set of

concepts with a

coherent meaning

eg SNOMED

Value Set:

A selection of a set

of codes for use in a

particular context

Eg

Condition.verificationStatus

Coded Element

Core resource or

profileSelects Binds

Refers to

Conforms

Definition

Resource Instance

ValueSet

‣ Used in Coded elements

‣ A set of possible values for

a resource element

‣ Key component of

Terminology

‣ Similar to SNOMED refset

‣ Can be altered in profiling

(Curation)

‣ Eg:

Condition.verificationStatus

Terminology binding: Condition resource ▸ a

View in spec…

Exchange Paradigms

REST

DocumentsMessages

Services (Operations)

Sharing information – different paradigms

REST

Message

FHIR

Repository

Document

Documents in FHIR

What is a Document?

▸ Clinically

– Summary at a point in time

– Eg eDischarge. Mental Health, Emergency

Care eDischarge, Outpatient letters

▸ Contents

– Metadata

• Name, Author, Document type

– Sections with clinical data

• Eg Meds on Admission, Reason for

admission

– Can have signature

▸ HL7: What is a Document

– Persistence

– Stewardship

– Potential for

Authentication

– Context

– Wholeness

– Human readability

FHIR Document paradigm

‣ Technically a collection of

resources in a Bundle

‣ Can be signed

‣ Narrative in Composition

‣ Rendering rules in spec

Patient

Practitioner

Condition

List

AllergyIntolerance

Composition

• Subject

• Author

• Sections

• Admit Dx

• Allergy List

• … AllergyIntolerance

Document Bundle

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

GDPR (General Data Protection Regulations)

▸ FHIR is not a security standard, but…

▸ Discussions at the Connectathon last week:

– Existing privacy well aligned

(https://healthcaresecprivacy.blogspot.co.uk/2015/04/privacy-principles.html)

▸ Current FHIR support:

– AuditEvent, Provenance, Consent

– Any resource has security tags

– Authentication/Authorization

• SMART on FHIR, Pages in spec

– Identity resources

• Patient, RelatedPerson, Practitioner, Organization & others…

▸ Some gaps and areas for improvement

– White paper to come

https://healthcaresecprivacy.blogspot.co.uk/2018/05/gdpr-on-fhir.html

https://chat.fhir.org/#narrow/stream/111-Security-and.20Privacy

SMART

▸ Substitutable Medical Applications, Reusable Technologies

– http://hl7.org/fhir/smart-app-launch/

▸ History

▸ Originally limited to EHR external apps

– Becoming the ‘de-facto’ Authentication

▸ 2 aspects

– App launching

• Public & confidential

– Authentication ‘Profile’ on OAuth2 & OpenID Connect

• Endpoints and scopes

▸ Sandbox: https://sandbox.smarthealthit.org/#/start

▸ App Gallery: https://apps.smarthealthit.org/

CDS Hooks

▸ Clinical Decision Support (CDS)

– User Interface for display CDS

– ‘hooks’ to EHR activity

▸ Service can call back to EHR

– Or any other data store

▸ Discovery & endpoints

▸ Prefetch

▸ Security Model

– ‘out of band’ setup

• Key exchange

– TLS

– Encrypted JWT in call to

service

– Access token provided for call

back

http://cds-hooks.org/specification/1.0/

Blockchain

▸ Technology behind bitcoin

▸ Distributed list of transactions (blocks)

▸ Cryptographically signed

– Can’t change without detection

▸ What is relationship with FHIR?

– Unlikely actual clinical data

– Tamper proof audit records

– Provider Authentication

– Supply chain (eg medication

provenance)

Adapting FHIR to your needs: Profiling

‣ Many different contexts (ways of recording data) in healthcare, but want a single set of Resources

‣ Need to be able to describe ‘usage of FHIR’ based on context

‣ Allow for these usage statements to:

- Authored in a structured manner

- Published in a registry & Discoverable

- Used as the basis for validation, code, report and UI generation.

‣ 3 main aspects:

- Constraining a resource - remove element, change multiplicity fix values

- Change coded element binding

- Adding a new element (an extension)

‣ Profiling adapts FHIR for specific scenarios

‣ A Statement of Use

For example…

Limit names to

just 1 (instead

of 0..*)

Change

maritalStatus to

another set of

codes that

extends the one

from HL7

international

Require that the

identifier uses the

NHS number – and is

required

Don’t support

photo

Add an

extension

to support

ethnicity

Where is FHIR going

‣ More resources

‣ Moving resources to normative

‣ More implementation experience, Connectathons

‣ Moving beyond Interoperability

‣ Extending into Clinical Knowledge

‣ Decision Support, Quality Measures

‣ Also being used for persistence

‣ Definitional resources, Care planning & support

‣ Associated standards

‣ SMART

‣ CDS-Hooks

‣ FHIR Cast

UK approach: Building the community

▸ INTEROPen

– Clinical curation of profiles

– Clinician involvement

– Multi discipline

– Vendor involvement

▸ NHS Digital

– Technical expertise

▸ Standards being developed

– Transfer of Care

▸ Propose Connectathon

Reality Check

▸ Sounds wonderful!

▸ Managing Expectations

▸ Analogy of building house

▸ All this is the concept plan…

▸ What does FHIR really stand for?

Far Harder In Real life !

52

Clinicians on FHIR: Modelling the

Problem ListDr. Amir Mehrkar – GP | Co-Chair INTEROPen

A variety of views

Encounters with patientsEncounter 1

(Date/Time)

Encounter n

(Date/Time)

NOW 4 episodes “a Problem”As a problem, has own life cycle management:

● Start date as a problem

● End date as a problem

● Who said this is a problem

○ Clinician / Patient

○ Organisation

● Status - is it still a problem?

● Significance of the problem

○ Major Depression diagnosis but

might be a minor “problem” for

patient

● Associated data

● Nested, Merge, Evolving

When does it become a “Problem”

Status (active / inactive)

Significance (major / minor) Types of Problems

The actual Problem can have its own FHIR data model

● Gastro-oesophogeal reflux - Condition resource

● Fam History of Scleroderma - may not exist as a

simple pre-coordinated code

● Procedures (Left / Right - post-coordinated)

● What resource type would Dizziness sit in?

Nesting of Problems

Dizziness / Lethargy / Suicidal thoughts

are independent Problems for the patient

BUT

Clinician creating the Problem List believes they

are related to the patient’s “Marital breakdown”

“Merge/Combine” Or “Evolve” Problems

Merge/Combine

Evolve

List

Resource

Type

‘ProblemHeader Profile’ (a profile of Condition Resource)

Keep: onset; abatement; asserter/date; note; ClinicalStatus (active/inactive only for now)

Remove: evidence; bodysite; severity; stage; verification status

Reference any other Resource type:

● Diagnosis -> Condition

● obs/symptom/social -> Observation

● Family History -> FamilyHistoryMember

● Allergy -> AllergyIntolerance

● Issues -> Alert

Extension: Actual Problem

Extension: Related ProblemHeader

Valueset: Nest, Merge, EvolveReference another ProblemHeader Resource type

Extension: Problem Significance

Valueset: Major/Minor

Extension: RelatedClinicalContent Reference Any Resource type

List

Resource

Type

‘ProblemHeader Profile’ (a profile of Condition Resource)

Keep: onset; abatement; asserter/date; note; ClinicalStatus (active/inactive only for now)

Remove: evidence; bodysite; severity; stage; verification status

Code.text = Human readable rendering

Code.coding if unambiguous code

Reference any other Resource type:

● Diagnosis -> Condition

● obs/symptom/social -> Observation

● Family History -> FamilyHistoryMember

● Allergy -> AllergyIntolerance

● Issues -> Alert

Extension: Actual Problem

Extension: Related ProblemHeader

Code (Nesting, Merge/Combine, Evolve)Reference another ProblemHeader Resource type

Extension: Problem Significance

Code (Major/Minor)

Extension: RelatedClinicalContent Reference Any Resource type

62

ClinFHIR ConMan:

Clinicial Model ValidationDr. David Hay – FHIR Strategist, Orion Health

History of clinFHIR

▸ ClinFHIR Purpose

– Assist resource development (HL7 Working Group Meeting)

– Educational

– Clinician/Business Analyst tool for participation in FHIR projects

– Develop simple FHIR artifacts

• Eg simple Profiles, ValueSets, Extension Definitions

– 2 modules using today

• ConMan

– Developed to support technical Connectathon

– Extended to Clinicians On FHIR events

• Logical modeler

– Build ad-hoc ‘things’ to use in Scenario (eg representing a potential

Profile)

Connectathon

▸ What is a connectathon

▸ Technical and Clinical tracks

▸ Technical tracks

– Enhance specification

▸ Clinical tracks:

– Purpose

• Education

• Gather clinical requirements

• Validate artifacts

– Precursor to Profile, IG

– Clinical Track types

• Scenario

• Model reviewFocus for today: Education

ConMan structure

TrackTrack

(Problem List)

TrackScenario

(eg simple List)

TrackScenario

Instance Graph

Over to Amir…

http://snapp.clinfhir.com/connectathon.html?event=cofio