Introduction to FHIR - New Zealand Seminar, June 2014
-
Upload
david-hay -
Category
Healthcare
-
view
1.457 -
download
3
description
Transcript of Introduction to FHIR - New Zealand Seminar, June 2014
HL7 FHIR What is it, and why should we care
David HayAlastair Kenworthy
Koray AtalagPeter Jordan
Page 2 • HL7 New Zealand
Welcome
• Purpose of Seminar• Agenda
– Around the room– Introduction to FHIR – Specialized Vignettes
• Models and FHIR• Terminology (SNOMED)• FHIR in New Zealand
– Lunch– Deep dive
• FHIR for Architects and Developers– Wrap up and next steps
• Looking forward to the HINZ conference
Page 3 • HL7 New Zealand
Around the room
• Quick intro– Who are you– What company do you represent (if any)– What’s your experience with FHIR so far– What do you want to get out of this seminar
• Half a minute (max) only!
Introduction to FHIR
Acknowledgements• Lloyd McKenzie• Ewout Kramer• Grahame Grieve
Agenda
• Background• Business Case• Resources, Profiles & Bundles• Paradigms
• REST• Documents• Messages
• The Specification
David HayChair HL7 New Zealand
Co-Chair FHIR Management GroupMember HISO
Product Strategist Orion healthwww.fhirblog.com
Page 5 • HL7 New Zealand
The acronym
• F – Fast (to design & to implement)– Relative – No technology can make integration as fast as we’d like
• H – Health– That’s why we’re here
• I – Interoperable– Ditto
• R – Resources– Building blocks – more on these to follow
5
Page 6 • HL7 New Zealand
Why Standards
• The Great Baltimore fire February 7th & 8th 1904
• Standards enable Interoperability– Power voltages– Internet– Cell phone
• In Health Interoperability, standards save money and time– Maximizing reuse
Page 7 • HL7 New Zealand
Paradigms of Interoperability
REST
DocumentsMessages
Services
Page 8 • HL7 New Zealand
Timeline: Where does FHIR fit?
1980 20001990 2010 2020
V21987
FreshLook2011
V3CDA2005
FHIRDSTU2014
Start V31995
10 years 3years
Page 9 • HL7 New Zealand
FHIR Manifesto
• Focus on Implementers• Target support for common scenarios• Leverage cross-industry web technologies• Require human readability as base level of interoperability• Make content freely available• Support multiple paradigms & architectures• Demonstrate best practice governance
Page 10 • HL7 New Zealand
Business Case for FHIR
• Simple to understand• Developer friendly
– Familiar tooling– Familiar technologies – XML/JSON/Atom, HTTP, SSL, OAuth
• All paradigms• Many Architectures• Many Clients
– Thick client, browser, mobile, devices
• Already in use– HAPI Library– 70 Organizations, 20 Countries
• US (ONC, SMART), UK (referrals), NZ (Orion Health)
Results in faster, cheaper deployments that are more re-usable
Page 12 • HL7 New Zealand
Supporting an ecosystem
NHI RLS Éclair GP LWHC
Authentication & Auditing (eg RealMe) + Privacy
TrustedApp
Store
Resources
Page 15 • HL7 New Zealand
FHIR Overview
• Has concept of ‘resources’– E.g. Patient, Problem, Prescription, Allergy
• Each resource has a base structure of commonly used data– Build-in extensibility mechanism– Profiles for local specific requirements
• Specification built like a software product– Automatic generation of artifacts apart from static files– Massive improvement in quality
• Uses simple XML, and supports JSON• Each resource has specific validation schema
– Automatically generated from resource definition files
• Defines terminologies/code sets for specific elements– But can be altered in different domains
• All resources can be versioned• Developed in conjunction with community
– All work on the web and freely available - www.hl7.org/fhir– Lots of samples– “Connectathons” to test that interoperability really works – Test servers available on-line now
• Currently DSTU (Draft Standard for Trial Use), normative 2016
Page 16 • HL7 New Zealand
Resources
• “Resources” are:– Small logically discrete units of exchange– Defined behaviour and meaning– Known identity / location– Smallest unit of transaction– “of interest” to healthcare
– V2: Sort of like Segments– V3: Sort of like CMETs
16
Page 17 • HL7 New Zealand
What’s a Resource?
Examples
• Administrative– Patient, Practitioner,
Organization, Location, Coverage, Invoice
• Clinical Concepts– Allergy, Condition, Family History,
Care Plan• Infrastructure
– Document, Message, Profile, Conformance
Non-examples
• Gender– Too small
• Electronic Health Record – Too big
• Blood Pressure– Too specific
• Intervention– Too broad
17100-150 total - ever
Page 18 • HL7 New Zealand
DSTU Resource List
Page 19 • HL7 New Zealand
ResourceNarrative
Elements
Extensions Extensions
Structure of a Resource
Metadata
Page 20 • HL7 New Zealand20
Human Readable Summary
Standard Data Content: MRN Name Gender Date of Birth Provider
Extension with reference to its definition
Page 21 • HL7 New Zealand
Resource elements (structures)
• Resources are defined as an XML structure based on desired wire syntax– Hierarchy of elements– Each element has
• Name• Either a datatype or nested elements• Cardinality• Definition• RIM mapping
• But instances in XML or JSON
Page 22 • HL7 New Zealand
It’s all about combining resources . . .
Patient
Practitioner
Observation
Organization
http://moh.govt.nz/nhi/Patient/223
http://moh.govt.nz/hpi/Practitioner/87
http://lab.hospitalA.org/DiagRep/4445
http://lab.hospitalA.org/Observation/3ff27
http://moh.govt.nz/hpi/Organization/1
Page 23 • HL7 New Zealand
References between resources
23
Page 24 • HL7 New Zealand
FHIRRepository
Regardless of paradigmthe content is the same
Lab System
Receive a lab result in a message…
FHIR Message FHIR
Document
…Package it in a discharge summary document
NationalExchangeREST
Page 25 • HL7 New Zealand
Data types: Primitive
• Based on w3c schema and ISO data types• Stick to the “80% rule” – only expose what most will
use• Data types can have extensions too
25
Page 26 • HL7 New Zealand
Data types: Complex
26
Page 27 • HL7 New Zealand
The Case for Extensions
• Extensions are often problematic in existing HL7 specs– Z-segments in v2
• What does this mean?– ZSB|20080117|Q^57|4.30^uL
– Foreign namespaces in CDA/V3• Break schemas• And you still need to find the documentation
• Simple choice – design for absolutely everything or allow extensions
27
Page 28 • HL7 New Zealand
Extensions without the pain…
• Extensions are built into the wire format– All fully conformant systems can “handle” any possible
extension - Just a bucket of “other stuff”– <extension> is element– Can occur at any level
• Use <modifierExtension> in the instance to flag extensions that “change things” – ‘isModifier’ in the definition
• Require formal definitions of extensions to be available in interoperability space (profile)
• Extensions rendered in human readable portion
28
Page 29 • HL7 New Zealand
Profiles
• 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 points to its profileCan be (and probably are) on different servers
HTTP://server/Profile/nzpatient#iwi
Page 30 • HL7 New Zealand
Bundles
• Collections of resources– And metadata
• Needed for– Search– History– Document– Message
• Uses Atom feed– XML is standard– FHIR has defined JSON
representation
• Resources in entry elements
Bundle info
First Resource
Other Resource
Other Resource
REST
Page 32 • HL7 New Zealand
Representational State Transfer (REST)
Client Server
Request
Response
HTTP/S
• HTTP– Verbs– Headers– Status Codes
• The way the web works…
Page 33 • HL7 New Zealand
FHIR RESTful Operations
• Instance– Read GET [base]/Patient/100– Vread GET [base]/Patient/100/{vid}– Update PUT [base]/Patient/100– Delete DELETE [base]/Patient/100– History GET [base]/Patient/100/_history
• Type– Create POST [base]/Patient– Search GET [base]/Patient?name=eve– History GET [base]/Patient/_history– Validate POST [base]/Patient/100/_validate/{id}
• System– Conformance GET [base]/metadata– Transaction POST bundle to root– History GET [base]/_history– Search GET [base]/Patient?name=eve
Page 34 • HL7 New Zealand
Versioning
33, v12 – 2012-12-04
33, v13 – 2012-12-05
33, v14 – 2012-12-08
/server.org/fhir/Patient/33/_history/12
/server.org/fhir/Patient/33/_history/14
/server.org/fhir/Patient/33/_history/13
/server.org/fhir/Patient/33/_history/15
/server.org/fhir/Patient/33 or/server.org/fhir/Patient/33/_history/15
33, v15 – 2012-12-09
All FHIR resources can be versioned
Page 35 • HL7 New Zealand
Conformance Resource
• Server doesn’t have to do everything• Conformance resource indicates:
– Supported Resources– Search parameters– Supported profiles
• By paradigm
Documents
Page 37 • HL7 New Zealand
FHIR Documents
• Characteristics– A point-in-time snapshot of information– Intended for persistence– Organize information for human consumption
• Defined rules for how to render– Attested by a particular author– Do not (directly) drive behavior
• May be clinical (e.g. CDA) or non-clinical (e.g. Structured Product Labeling)
37
Page 38 • HL7 New Zealand
Documents – are bundles
38
Observation Resource
Composition Resource
SectionSection
Device Resource
Patient Resource
Prescription Resource
<feed> <entry> <Composition /> </entry> <entry> <Observation /> </entry> <entry> <Device /> </entry> <entry> <Prescription /> </entry> <entry> <Patient /> </entry></feed>
AttesterMetadata
Messages
Page 41 • HL7 New Zealand
FHIR Messages
• Messages are collections of resources sent with the intention of driving some sort of action– often replied to with another message
• Not intended for persistence as a whole• Always tied to some sort of “event”• Specific originator and intended recipient• Same as v2 and v3 message model
41
Page 42 • HL7 New Zealand
Messages – are bundles
42
Observation Resource
MessageHeadersource destination
Device Resource
Patient Resource
<feed> <entry> <MessageHeader /> </entry> <entry> <Observation /> </entry> <entry> <Patient /> </entry> <entry> <Device /> </entry></feed>
event
The Specification
Page 44 • HL7 New Zealand
The Spec: Hl7.org/fhir
44
Wrapping up (for now)
Page 46 • HL7 New Zealand
Is FHIR going to replace . . .
• HL7 v2?, v3?, CDA?
• FHIR has the potential to supplant all of the above, but that’s not going to happen soon– Sunk costs don’t get thrown out easily
• All HL7 standards will be maintained as long as implementers require
46
Page 47 • HL7 New Zealand
Key takeaways
• FHIR is a disruptive technology • Designed to be quick and (relatively) easy to implement
– And cheaper than alternatives
• Useful across all paradigms• Especially support mobile• Wide interest internationally
• This afternoon we’ll go deeper– For architects and developers