INTEROPen FHIR Curation Work Dr. Munish Jokhani – FHIR Curation Clinical Engagement Lead, NHS Digital 3
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? PHASE 1 mapping proposal PHASE 3 approved CLINICAL(PRSB) INTEROPen webex call CLINICAL FHIR TECHNICAL or workshop TERMINOLOGY MODELLING CareConnect CLINICAL SAFETY FHIR Profile e.g. Allergies and adverse reactions In eDischarge PHASE 2 summary INTEROPen community First of Type Feedback(e.g. Vendors) Implementation Sites GDEs TRUSTS + ACUTE EPRS + GP Vendors 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. • Essentia l. No one organisation could do it with any hope of a workable outcome. 21
FHIR Review Dr. David Hay – FHIR Strategist, Orion Health 22
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 ‣ F ast H ealthcare I nteroperability R esources ‣ 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? V2 Start V3 V3 CDA Fresh Look FHIR Release 3 1987 1995 2005 2011 2016 V2 V3 CDA FHIR 1980 1990 2000 2010 2020
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 Care Provision Medication & Immunization Diagnostics AllergyIntolerance CarePlan Medication Observation Condition (Problem) CareTeam MedicationRequest DiagnosticReport Procedure Goal MedicationAdministration ProcedureRequest ClinicalImpression ReferralRequest MedicationDispense Specimen FamilyMemberHistory ProcedureRequest MedicationStatement RiskAssessment NutritionOrder Immunization BodySite VisionPrescription ImmunizationRecommendation ImagingStudy DetectedIssue Sequence Maturity model
Resource instance example Resource Identity & Metadata Human Readable Summary Extension with URL to definition < valueString value= “jedi” /> Structured Data: • MRN • Name • Gender • Birth Date • Provider XML and JSON
References between Resources Patient Subject Reason Report Condition PROCEDURE Diagnostic report Encounter Performer Location Encounter Practitioner Location
Resource type structure in the spec ‣ Datatypes in resource type definition - Backbone element - ‘choice’ data types
Data types: Primitive dateTime instant time date Value : xs : dataTime 0..1 Value : xs:gYear [xs:gYearMonth | Time 0..1 Value : xs:gYear [xs:gYearMonth | xs:date | Time 0..1 Value : xs : Time 0..1 decimal Element boolean Value : xs : decimal 0..1 Extension : Extension 0.. value : xs:boolean 0..1 integer string uri base64Binary Value : xs :string 0..1 Value : xs :anyURI 0..1 Value : xs : base64Binary 0..1 Value : xs : int 0..1 unsignedint positiveInt code id oid Based on w3c schema and ISO data types ▸ Stick to the “80% rule” – only expose what most will use – Simplified
Attachment Data types: Complex Address SampledData contentType: Code [0..1] MimeType! Coding use: code [0..1] AddressUse! origin: Quantity(SimpleQuantity) [1..1] language: Code [0..1] CommonLanguages+ type: code [0..1] AddressType! period: Decimal [1..1] data: base64Binary [0..1] CodeableConcept text: string [0..1] Ratio system: uri [0..1] factor: Decimal [0..1] url: uri [0..1] line: string [0..*] version: string [0..1] lowerLimit: Decimal [0..1] size: unsignedInt [0..1] city: string [0..1] coding: Coding [0..*] code: code [0..1] upperLimit: Decial [0..1] hash: base64binary [0..1] numerator: Quality [0..1] text: String [0..1] district: string [0..1] dimensions: Positivelnt [1..1] title: string [0..1] display: String [0..1] denominator: Quantity [0..1] state: string [0..1] data: String [1..1] userSelected: boolean [0..1] creation: dateTime [0..1] postalCode: string [0..1] country: string [0..1] period: Period 0...1 Quantity ContactPoint value: decimal [0..1] comparator: code [0..1] QuantityComparator! system: Code [0..1] ContactPointSystem! units: string [0...1] value: String [0..1] system: uri [0..1] use: Code [0..1] ContactPointUse! code: code [0..1] rank: PositiveInt [0...1] period: Period [0..1] Range Element Timing low: Quantity(SimpleQuantity) [0..1] extension: high: Quantity(SimpleQuantity) [0..1] event: dataTime [0..*] Extension 0..* code: CodeableConcept [0..1] TimingAbbreviation? HumanName Repeat use: code [0..1] NameUse! bounds[x]: Type [0..1] Duration|Range|Period text: String [0..1] dount: Integer [0..1] family: String [0..*] dountMax: integer [0..1] given: String [0..*] duration: decimal [0..1] prefix: String [0..*] durationMax: decimal [0..1] suffix: String [0..*] durationUnit: code [0..1] UnitsOfTime! period: Period [0..1] Signature frequency: integer [0..1] repeat frequencyMax: integer [0..1] [0..1] period: decimal [0..1] type:Coding [1..*] Signature Type? periodMax: [0..1] Identifier when: Instant [1..1] periodUnit: code [0..1] UnitsOfTime who[x]: Type [1..1] uri | Annotation dayOfWeek: code [0..*] DaysOfWeek! Reference(Practitioner|Related use: code [0..1] IdentifierUse! timeOfDay: time [0..*] person|PatientDevice|Organization) Period type: CodeableConcept [0..1] IdentifierType+ author[x]: Type [0..1] when: Code [0..*] EventTiming! onBehalfOf[x]: Type [0..1] system: uri [0..1] Reference(Practitioner|Patient| offset: unsginedInt [0..1] uri|Reference(Practitioner|RelatedPers value: String [0..1] RelatedPerson)|string start: dateTime [0..1] on|Pateint|Device|Organization) period: Period [0..1] Time: dateTime [0..1] end: dateTime [0..1] contentType: code [0..1] MimeType! assigner: Reference [0..1] Organization Text: string [1..1] blob: base64Binary [0..1]
Complex datatype example: HumanName
Recommend
More recommend
