INTEROPen FHIR Curation Work Dr. Munish Jokhani FHIR Curation - - PowerPoint PPT Presentation

3

INTEROPen FHIR Curation Work

• Dr. 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 TECHNICAL TERMINOLOGY CLINICAL SAFETY

PHASE 2 INTEROPen community Feedback(e.g. Vendors) PHASE 3 approved INTEROPen webex call

• r 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 Review

• Dr. 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 report Condition Subject Report Reason Encounter Performer Encounter Practitioner Location 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

• id

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]

Element

extension: 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!

• ffset: 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

• rigin: 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)

• nBehalfOf[x]: Type [0..1]

uri|Reference(Practitioner|RelatedPers

• n|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

• f codes for use in a

particular context Eg Condition.verificationStatus Coded Element Core resource or profile

Selects 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 Documents Messages 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

• f 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 List

• Dr. Amir Mehrkar – GP | Co-Chair INTEROPen

A variety of views

Encounters with patients Encounter 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
• bs/symptom/social -> Observation
• Family History -> FamilyHistoryMember
• Allergy -> AllergyIntolerance
• Issues -> Alert

Extension: Actual Problem Extension: Related ProblemHeader Valueset: Nest, Merge, Evolve Reference 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
• bs/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 Validation

• Dr. 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 review

Focus for today: Education

ConMan structure

Track Track (Problem List) Track Scenario (eg simple List) Track Scenario Instance Graph

Over to Amir… http://snapp.clinfhir.com/connectathon.html?event=cofio