Embed Size (px)
Citation preview
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
