Post on 19-Feb-2017
FHIR in New Zealand:A Clinicians perspective
HL7 New Zealand, October 2015
Page 2
Agenda
• Morning– FHIR background – David hay
• Benefits and value• Tooling• Fundamentals• Profiling
– A practical example: Adverse Drug Reactions (ADR)• The clinical problem – Matt Doogue• The AllergyIntolerance resource – Peter Jordan
• Afternoon– Stream 1 (Clinical) : Profiling AllergyIntolerance for ADR– Stream 2 (Developer): Mini-hackathon
Page 3
Objectives of day
• Provide a base level knowledge of FHIR• Give familiarity of tooling
– On-line specification– clinFHIR
• Example of creating a real profile• Generate interest from Clinicians & Business Analysts
– Techies already on board• Next steps in New Zealand
Page 4
• Name: David Hay• Company: Orion Health (Product Strategist)• Background:
– Ex Clinician– Involved in FHIR almost from beginning– Co-Chair FHIR Management Group– Chair HL7 New Zealand– Member HISO Committee– Blog: FHIRBlog.com
Who am I?
Page 5
Why Standards
Why FHIR
Page 7
OVERVIEW OF FHIR
• Fast Healthcare Interoperability Resources (FHIR)• Consistent, simple to use resources
– Domain knowledge is not required• Well thought out, standardized APIs• Controlled extensibility• Familiar tools and technologies for implementers• Improves healthcare information exchange
– Designed with implementers in mind– Detailed spec for real time APIs
• Strong endorsement and support from vendors and regulatory community (NITB, ONC, Project Argonaut).
Page 8
Where it can add value: INTEROPERABILITY
• Resources and profiles standardize input:– Less source system variation leads to faster integration– Simplified validation and error detection
• Structured approach to extension & profiles improves understanding
• Adds well defined API standards to traditional messaging and document based exchange paradigms:– Critical to support standards based app innovation.
Page 9
Where it can add value: Application innovation
• Provision of predictable interfaces – both transport and content
• Using industry standard technologies (REST, JSON) lowers the barrier to entry
• Discoverability of services through conformance statements and profiles.
• Increases commercial viability of app development:– FHIR compliant apps should will work with different FHIR Servers
(EMRs, HIEs)
BENEFITS TO IMPLEMENTERS AND HCOS
Page 11
Benefits to Implementers
• Familiar tooling and technologies – XML/JSON, HTTP, REST, SSL, OAuth
• Predefined resources and APIs - allows implementer to focus on the core application functionality
• Extensive documentation, samples and reference server implementation
• Active and supportive community
• Open Source code libraries: HAPI (Java) and Furore (.Net) and test servers
• Mobile friendly
Page 12
Benefits to HCOS
• Well supported by the vendor community
• Standards based APIs– Connect systems– support internal application development
• Will lead to:– faster interoperability– lower cost interoperability– reduced vendor lock inas FHIR is adopted by source systems
BENEFITS TO CLINICIAN AND PATIENT
Page 14
Benefits to Clinician
• Improved access to higher quality, patient information
• Greater choice and variety of applications to support clinical workflow.
Page 15
Benefits to patient
• Care team has access to a more complete patient record and improved decision support tools:– Better decision making– More efficient diagnosis and treatment
• Prospect of improved patient engagement apps, enabled through FHIR APIs to clinical systems.
Page 17
Small Print
• Current status DSTU-2• Implementer experience starting• Health IT is hard!• Local expertise growing• Suggests pilots are a good approach…
Tools
Page 19
Tools
• Specification• clinFHIR
– Visualization– Link to spec – Resource Builder– Profile Builder
• Forge
Fundamentals: Resources
Page 21
Resources
• “Resources” are:– Small logically discrete units of exchange– Defined behaviour and meaning– Known identity / location– Smallest unit of transaction “of interest” to healthcare
21
Page 22
Resources – sample list
Page 23
Resource anatomy
• Resources have 4 main parts
23
StructuredData
Extensions
Narrative(text)
Metadata
Page 24 24
Page 25
Comprised of elements
• Each element has– Name– Description– DataType
• Reference, Coded, Standard• Can be more than one per element (the [x] in the spec)
– Terminology Binding• If coded
– Multiplicity• How many
MD
Page 26
References between resources
A web of resources that can tell any story
Page 27
Clinical Scenario
• First consultation– Complaining of pain in the r) ear for 3 days with an elevated
temperature. On examination, temperature 38.5 degrees and an inflamed r) ear drum with no perforation. Diagnosis Otitis Media, and prescribed Amoxil 250mg TDS for 5 days
• Follow up consultation– 2 days later returned with an itchy skin rash. No breathing difficulties.
On examination, urticarial rash on both arms. No evidence meningitis. Diagnosis of penicillin allergy. Antibiotics changed to erythromycin and advised not to take penicillin in the future.
Condition
Observation
Med
Allergy
Encounter
5 year old boy Patient
Page 28
Resource view
(All refer to patient)
Page 30
Screen dump
Fundamentals: Exchange Patterns
Page 32
Exchange Patterns
32
REST
Documents Messages
Services(API)
Page 33
Document
33
Bundle
Resource 1
Resource 2
Composition
Use for ‘point in time’ record Discharge Summary Referral
Analogous to CDA Collection of resources bound
together Root is a “Composition”
resource (Just like CDA header) Explicit context
Page 34
Message
34
Bundle
Resource 1
Resource 2
MessageHeader
• Used to inform or instruct– Patient Admitted– Lab result available
• Analogous to v2 messaging• Also a collection of resources
as a Bundle
Page 35
REST
• Use for simple ‘Real time’ interactions– Current Medication list– Update Problem list
• “Representational state transfer” – an architecture for how to connect systems
• Used by Google, Facebook, Amazon• Simple interfaces• Easy to build / debug / support• Especially good for mobile
35
Page 36
Services & Operations
• More complex real-time interaction– Eg Prescription with Decision support – Suitable for workflows– Only constraint is that you’re passing around FHIR resources in some
shape or manner– Examples in spec
• Get Patient record• Expand ValueSet• Fetch Encounter data
36
Page 37
FHIRRepository
Regardless of paradigm, the content is the same
Lab System
FHIR Message
FHIR Document
NationalExchangeREST
Page 38
Re-visiting the consultation…
Page 39
As a document…
Page 40
…or a Message
Fundamentals: Terminologies
Page 44
Terminology
a discipline that systematically studies the “labeling or designating of concepts” particular to one or more subject
fields or domains of human activity
Wikipedia
Page 46
FHIR Resource Datatypes
• Resource element datatypes of different ‘categories’– References to other resources– Non-coded data – Coded data
• Coded data– Code– Coding– CodeableConcept– (Quantity)
Page 47
Coded data: Examples
• Code: "status" : "confirmed"• Coding: {
"system": "http://www.nlm.nih.gov/research/umls/rxnorm", "code": "C3214954", "display": "cashew nut allergenic extract Injectable"}
• CodeableConcept: { "coding": [{ "system": "http://snomed.info/sct", "code": "39579001", "display": "Anaphylactic reaction“ }], "text" : "Anaphylaxis"}
Page 48
Terminology Sub-system
• SNOMED CT • LOINC • ICD• NZ-ULM• Iwi & Hapu• New Zealand DHB
Code System:Defines a set of concepts with a
coherent meaning
CodeDisplay
Definition
Page 49
Terminology Sub-system
Value Set:A selection of a set of codes for
use in a particular context
Code System:Defines a set of concepts with a
coherent meaning
CodeDisplay
Definition
Selects
Page 50
Terminology Sub-system
Code System:Defines a set of concepts with a
coherent meaning
CodeDisplay
Definition
Element Definition: Type and Value set reference
Value Set:A selection of a set of codes for
use in a particular context
Selects Binds
Page 51
Terminology Sub-system
Code System:Defines a set of concepts with a
coherent meaning
CodeDisplay
Definition
Element Definition: Type and Value set reference
Value Set:A selection of a set of codes for
use in a particular context
Selects Binds
Element: code/
Coding/CodeableConcept
Refers toConforms
Page 52
Binding Strength
• How closely the options in the value set should be followed• Values
– Required (must come from set)– Extensible (may use alternate if have to)– Preferred (don’t have to, but should)– Example (set isn’t specified)
• Can use extension to vary– (Make stronger not weaker)
Page 53
ValueSet resource
• Defines list of possible values for a particular context– Eg Medication codes in New Zealand
• Can reference external Terminology/s– Or define own sets
• Why?– A common valueSet improves recording consistency – Improves user experience (pick lists)
• Examples in New Zealand– ED diagnoses (derived from SNOMED)– NZ POCS (Pathology Observation Code Set) (derived from LOINC)– List of NZ Iwi (defined in ValueSet)
Page 54
ValueSet for condition.code
{ "resourceType": "ValueSet", "id": "valueset-condition-code", "meta": { "versionId": "1", "lastUpdated": "2015-05-08T16:18:23Z", }, "text": { "status": "generated", "div": ”Condition.code sample ValueSet" },"url": "http://hl7.org/fhir/vs/condition-code", "version": "0.5.0", "name": "Condition/Problem/Diagnosis Codes", "publisher": "FHIR Project team", "contact": [ { "telecom": [ { "system": "url", "value": "http://hl7.org/fhir" } ] } ],
"description": "Example value set for Condition/Problem/Diagnosis codes", "copyright": "This value set includes content from SNOMED CT, which is copyright © 2002+ International Health Terminology Standards Development Organisation (IHTSDO), and distributed by agreement between IHTSDO and HL7. Implementer use of SNOMED CT is not covered by this agreement", "status": "draft", "experimental": true, "compose": { "include": [ { "system": "http://snomed.info/sct", "filter": [ { "property": "concept",
"op": "is-a", "value": "404684003" } ] } ] }}
Page 55
Terminology Server
• Provides ‘services’ for consumers to access terminology– Hide the complex stuff from a consumer
• Uses Operations framework– Get definition for a concept– Find a concept
• Within a ValueSet • Find Terms• Get Term
Definition
Profiles: An overview
Page 57
The need for Profiles
• Many different contexts in healthcare, but a single set of Resources• Need to be able to describe restrictions and extensions based on use
and context• Allow for these usage statements to:
– Authored in a structured manner– Published in a repository– Used as the basis for validation, code, report and UI generation.
• 2 main aspects:– Constraining a resource– Adding an extension
• Profiling is going to be very important
57
Page 58
Examples of Profiles in New Zealand
• Patient– Fix identifier to NHI– Add Iwi, Hapu ?Usual GP
• Condition (Problem)– Code is SNOMED– Different disciplines could have different profiles
• MedicationOrder– Use ULM– Fix identifier to HPI
Page 60
Profiling a resource. For example...
60
Require that the identifier uses the NHI – and is required
Limit names to just 1 (instead of 0..*)
Limit maritalStatus to another set of codes that extends the one from HL7 international
Don’t support photo
Add an extension to support “Iwi”
Note: hardly any mandatory elements in the core spec!
Profiles: Constraining Resources
Page 62
When constraining you can:
• Remove an element completely• Make an optional element required• Change ‘many’ to one• If ‘many’, specify the permissible values
– Slicing (e.g. BP Observation)• Specify a different ValueSet• Change the possible datatype
– Not add new ones
• Overall, a recipient can still understand a constrained resource– Still ‘wire’ compatible.
Profiles: Extending resources
Page 64
Why are there extensions?
• A consequence of keeping resources small– Lesson of HL7 v3
• The 80% guideline• Allow new information to be added
– In a discoverable way• Extensions are normal
Page 65
Key features of extensions
• Used to add a new property, or refine existing• Any element can be extended
– The path• Normal or modifier• Same capability as ‘core’ properties • Properties defined in an ‘Extension Definition’ resource • Instance points to definition
– Recipient can always find out what an extension means
Page 66
Governing Extensions
• Extensions are not a silver bullet• FHIR has a sliding scale governance for
extensions– HL7 published extensions– National Standards (e.g. New Zealand Extensions)– Domain standards (e.g. Best Practice Cardiology)– Local Projects
66
Page 67
The ‘Conformance Server’
• Where extension definitions stored– (and other stuff)
• It’s a resource like any other– Can be queried/located like any other resource– Profile registries easy
Resource Profile
Extension
The extension in the instance points to its definitionCan be (and probably are) on different servers
HTTP://server/StructureDefinition/nzpatientwi
Page 68
Example: AllergyIntolerance
• Use clinFHIR to profile AllergyIntolerance– Extension for Encounter reference– Change other elements
• Then show in resource builder– Patient ‘encounter HINZ’– Note:
• Resource ‘claims conformance’ to Profile
Page 71
Establishing the ecosystem
Terminology
Security
Identity Data
FHIR API and Resources
Conformance
Page 72
Wrapping up
• FHIR enables innovation by standardizing interoperability• It can be understood by Clinician and Techie• It is being widely adopted internationally
– (early days)• It offers a real opportunity to revolutionize health IT in New
Zealand if we work together.• What should we do next?