HL7 FHIR
Ewout Kramer
e.kramer@furore.com
http://www.slideshare.net/ewoutkramer/hl7-fhir
HL7 Norway, april 1st, 2014
Our common problem
• Avoid speaking between lunch and afternoon
coffee
• No one is interesting to listen to for more than
45 minutes
So….Please…
• I’ll break the presentation in 45 minutes
• State your questions at anytime
• Read your e-mail if you need to
(well, that’s relative)
(that’s what we need)
(the web technology bit)
Why have something new?
STARTING A FHIR
Why something new?
“How can I get data from
my server to my iOS app?”
“How do I connect my applications
using cloud storage?”
“How can I give record-based
standardized access to my PHR?”
If your neighbour ‘s son can’t hack an
app with <technology X> in a
weekend…..
you won’t get adopted
10
WHAT’S IN THE BOX?
Slice & dice your data into “resources”
MedicationPrescription
Cover 80%
- Context independent
Problem
- Unit of exchange/storage
Thousands of examples
Patient
MRN 22234
Patient
“Ewout Kramer”
30-11-1972 MRN 22235
Amsterdam “Olaf Olafsson”
01-01-1994
Bergen
Organization
“ACME Hospital”
Organization
National Drive 322
Orlando, FL
“ACME Hospital”
National Drive 322
Orlando, FL
Consistent documentation
Structure of a Resource
(XML example)
Human Readable
• CDA taught HL7 a very important lesson
– Even if the computers don’t understand 99% of what
you’re sending, that’s ok if they can properly render it to a
human clinician
• This doesn’t just hold for documents – important for
messages, services, etc.
• In FHIR, every resource is required to
have a human-readable expression
– Can be direct rendering or human entered
How many resources?
Currently: about 40
Next up…still about 100 to go
• Administrative
• Scheduling
– Patient, Location, Encounter,
Organization,
• Clinical Concepts
– AllergyIntolerance,
Questionnaire, Observation
• Infrastructure
– ValueSet, Composition, Profile,
Conformance
- Appointment, Availability, Slot
• Financial
-
Claim, Account, Coverage
• Consent
Everything to cover C-CDA
Cover all usecases - (n)ever
Specific
Generic
HL7v2
openEHR RM
HL7 CDA
HL7v3 RIM
HL7v3 CMETS
openEHR
Archetypes
FHIR
openEHR
Templates
C-CCD
IHE PDQ
Cover the 80% out of the box…
+
=
Patient
MRN 22234
“Ewout Kramer”
30-11-1972
Amsterdam
+
Haircolor BROWN
You can extend:
- Resources
- Elements of Resources
- FHIR Datatypes
Organization
“ACME Hospital”
National Drive 322
Orlando, FL
+
Taxoffice Id NLOB33233
Extending a multiple birth
Key = location of formal definition
Value = value according to definition
?
Package & publish: The Profile
“My First Profile”
V1.0 by Ewout
Support “Bottom-up re-use”
Document from the resource to the wire
HTTP/1.1 200 OK
Content-Type:
application/json;charset=utf-8
Content-Length: 627
Content-Location:
/fhir/person/@1/history/@1
Last-Modified: Tue, 29 May 2012
23:45:32 GMT
ETag: "1“
"Person":{"id":{"value":"1"},"identifi
er":[{"type":{"code":"ssn","system":"
http://hl7.org/fhir/sid
Packaging & transport
√
√
Yes, v2 style messaging
is also supported!
Yes, v3 CDA style
documents
are also supported!
IN SUMMARY…
FHIR Manifesto (abridged)
•
•
•
•
Focus on implementers
Keep common scenarios simple
Leverage existing technologies
Make content freely available
Implementer support…
In Summary…
•
•
•
•
•
•
Basic “80%” Resources
Extension mechanism
Publication mechanism for specs (profiles)
Package as Message, Document or “REST”
XML/JSON/HTTP protocol for transport
Examples, documentation, API’s, connectathons
What’s Next?
• January 2014 First Draft Standard for Trial Use ballot (“DSTU1”)
– Semi-stable platform for implementers Additional DSTU versions roughly annually
to make fixes, introduce new resources
• May 2015 Second Draft Standard for Trial Use ballot (“DSTU2”)
– Additional (C-CDA) resources, more workflow support, work on validation,
community feedback
• Normative is around 3 years out
– We want lots of implementation
experience before committing to
backward compatibility
31
Questions?
INTERLUDE: SOURCE OF FHIR
“Source” of FHIR
Straight from the HL7 SVN “code” respository
at gforge.hl7.org
Publication process
.INI
Website
Validation
Schema’s
examples
Publication tool
(org.hl7.fhir.tools.jar)
Resource
Examples
UML
DictXml
Java, C#,
Delphi
Resource profiles
eCoreDefinitions.xml
Combining resources into useful exchanges
PLAYING WITH FHIR
It’s all about combining resources . . .
http://lab.hospitalA.org/Observation/3ff27
Observation
Patient
Organization
http://hospitalA.org/Organization/1
Diagnostic
http://lab.hospitalA.org/DiagRep/4445
Report
Practitioner
http://hospitalA.org/Practitioner/87
37
Diagnostic
Report
Patient
Practitioner
Observation
In REST: Possibly distributed…
FHIR server @ pat.registry.org
Patient/223
Patient
DiagnosticReport/4445 Observation/3ff27
subject
FHIR server @ hospitalA.org
Organization/1
Practitioner/87
Organization
39
FHIR server @ lab.hospitalA.org
Practitioner
Diagnostic
Report
Observation
http://fhirblog.com/2014/01/24/modellingencounters-with-fhir/
“Repository” model of healthcare
Hospital System
Create
Update
Lab System
Create
Update
Query
Organization
Patient
Patient
Patient
FHIR server
Create
Query Subscribe
Update
Diagnostic
Report
Observation
Observation
Observation
“Atom”: New reports in the mail
FHIR Document
Discharge
Summary
Dr. Bernard
Patient Mary
Practitioner
Patient
Composition
Kidney Stones
Condition
Chief Complaint
Pulse
section
Physical
Vital Signs
list
Observation
entry
section
Medications
section
BP
Observation
Discharge Meds
list
Dyclofenac
entry
MedicationPrescription
Tamsulosin
MedicationPrescription
43
Regardless of paradigm the content is the same
Receive a lab result in a message…
FHIR Message
FHIR
Repository
FHIR Document
Lab System
National
Exchange
…Package it in a discharge summary document
http://fhirblog.com/2014/03/31/referrals-orders-and-fhir/
Very short intro to Profiles
CONTROLLING THE FHIR
The need for Profiles
• Many different contexts in healthcare, but a
single set of Resources
• Need to be able to describe restrictions 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.
Constraining cardinality
1..2
1..1
0..0
Limit cardinality to 1..2
(e.g. to at maximum your
organizations’ identifier + the
national one)
Limit names to just 1 (instead of 0..*)
Forbid any telecom elements
Note: something that’s mandatory in the core definition
cannot be made optional in a profile
48
Limit value domains
If deceased is given, it must be a
dateTime, not a boolean
OrganizationNL
=“true”
49
Fix value: Only allow “active”
Patients
Use our national codes for
MaritalStatus
Use another profiled Resource
“Basic” Document
Practitioner
Composition
Patient
0..1 subject
0..* Section
Any Resource
50
Practitioner-NO
Document-NO Profile!
Discharge
Summary-NO
Patient-NO
Composition
Condition
1..1 Complaint
section
0..1 Physical
section
1..1 Medications
section
0..1 Home situation
section
Vital Signs
list
Discharge Meds
list
Observation
Medication
Prescription-NO
51
What’s in a profile?
http://hl7.no/Profiles/patient-no
Conformance
Metadata
Constraints
Identifier
Name, Version
Publisher
Description, Code
Status
Date (of publication)
ExtensionDefn
Resource
Extension
ValueSet
Tagging a Resource
Patient
http://hl7.org/fhir/tag/security
MRN 22234
“Ewout Kramer”
30-11-1972
Amsterdam
“I’m a VIP - My information cannot yet be disclosed”
http://hl7.org/fhir/tag
“This is TEST data! Don’t use!”
http://hl7.org/fhir/tag/profile
“I’m an Organization as defined in the Norwegian Profile – see
http://hl7.no/Profiles/patient-no”
(Distributed) validation
App’s server
Store &
Validate
Country validation server
Profile X
Profile Y
Profile Y
Some examples from early-adopters
THE FHIRSTARTERS
1. Form Request
+ Patient data in FHIR
Empty
Questionnaires
Completed
Questionnaires
Form Filler
Form Repository
3. Filled out form
Form Client
FHIR
FHIR
Patient & Provider registry
National Patient Portal
References
Hospital System
CCD Documents
INTEROP WITH V2/V3
V2 to FHIR bridge
FHIR message
processor
FHIR
Messages
FHIR
Repository
FHIR
REST
Hospital System
Note: Messages are events,
REST exposes a “repository”
Model of data…
Migration – v2 and FHIR
• Already have an integration engine that supports
translation between v2 and FHIR messages
• Resources map to segments reasonably well
• As always, the challenge with v2 mapping is the
variability of v2 interfaces
– “Common” mappings can be created, but they won’t
be one size fits all
…and v2 mappings
Every Resource has v2 mappings specified, e.g.:
http://www.hl7.org/fhir/patient-mappings.html#http://hl7.org/v2
Patient
identifier
name
telecom
gender
birthDate
deceased[x]
address
maritalStatus
PID-3
PID-5, PID-9
PID-13, PID-14, PID-40
PID-8
PID-7
PID-30
PID-11
PID-16
CDA to FHIR
Document bridge
FHIR
Documents
FHIR Document
processor
FHIR
Repository
FHIR
REST
Hospital System A
Note: Documents are compositions,
• No update semantics
• Context?
• Wholeness?
Migration – CDA and FHIR
• Made more complex by human-readable
nature
– Need to ensure text <-> entry linkages are
retained
• Will best be handled on a template by
template basis
– Likely start with important ones like C-CDA
…and v3 mappings
Every Resource has v3 mappings specified, e.g.:
http://www.hl7.org/fhir/patient-mappings.html#http://hl7.org/v3
Patient
identifier
name
telecom
gender
birthDate
deceased[x]
address
maritalStatus
multipleBirth[x]
Patient
./id
./name
./telecom
./administrativeGender
./birthTime
./deceasedInd
./addr
./maritalStatus
.multipleBirthInd
FHIR & C-CDA
•
•
•
•
•
C-CDA is mandated by Meaningful Use
FHIR is a new specification
FHIR is not a replacement for C-CDA (yet)
Project to migrate C-CDA content to FHIR
In the future, FHIR may gradually replace CCDA
66
(XDS) references
A DocumentReference resource is used to
describe a document that is made available to a
healthcare system.
It is used in document indexing systems, and are
used to refer to:
• CDA documents in FHIR systems
• FHIR documents stored elsewhere (i.e. registry/repository following the XDS
model)
• PDF documents, and even digital records of faxes where sufficient information is
available
• Other kinds of documents, such as records of prescriptions.
IHE MHD
“This winter (…) the Volume 2 part of Mobile Health
Documents (MHD) will be replaced with the
appropriate content describing a profile of
DocumentReference to meet the needs of MHD and
the family of Document Sharing in XDS, XDR, and
XCA.”
John Moehrke, august 16, 2013
So why use anything else?
• FHIR is brand new
– No market share
– Only recently passed DSTU ballot
– Little track record
• Business case
– No-one dumps existing working systems just because
something new is “better”
– Large projects committed to one standard won’t change
direction quickly (or even at all)
Simple message
• Yes, FHIR has the potential to supplant HL7 v3, CDA and even
v2
• However
– It’s not going to do so any time soon
• No one's going to throw away their investment in older
standards to use FHIR until
1.
2.
•
The specification has a good track record
It’s clear the new thing provides significant benefits
HL7 will support existing product lines so
long as the market needs them
http://www.forbes.com/sites/danmunro/2014
/03/30/setting-healthcare-interop-on-fire/
SMART DEMO
http://smartplatforms.org/smart-on-fhir/
S
F
M
H
A
I
R
R
T
S
F
M
H
A
I
R
R
T
BlueButton
F
H
I
R
Any
FHIR
Server
(PHRs!)
Let’s run a demo!
Next Steps for you
• Read the spec at http://hl7.org/fhir
• Try implementing it
• Come to a (European?) Connectathon!
•
•
•
•
•
fhir@lists.hl7.org
#FHIR
Implementor’s Skype Channel
FHIR Developer Days (November 24 – 26), Amsterdam
StackOverflow: hl7 fhir tag