Call Girl Number in Vashi Mumbai📲 9833363713 💞 Full Night Enjoy
Introduction to HL7 FHIR
1. June, 2012
INTRODUCTION
TO
HL7 FHIR
Grahame Grieve
Adapted for
Ewout Kramer
HINZ by David
Lloyd McKenzie
Hay
6/22/2012 (c) 2012 HL7 International 1
2. Outline
Why FHIR?
FHIR Background
What is FHIR?
Tooling & Migration
Relationship to other Standards
Next Steps
6/22/2012 (c) 2012 HL7 International 2
3. Caveats !
FHIR is a work in progress
Specification has been looked at by
many people, but not subjected to
ballot or any official review
FHIR continues to evolve
Much of what we tell you could
change, at least somewhat, before it is
stable
◦ Includes the hyperlinks in this document!
Though the root for the spec will remain
Specification: http://www.hl7.org/fhir
6/22/2012 (c) 2012 HL7 International 3
4. WHY FHIR?
6/22/2012 (c) 2012 HL7 International 4
5. FHIR is necessary because
V3 is too hard
Documents (CDA) aren‟t enough
V2 needs a transition path
There are new markets and HL7 needs
something to offer
The world has evolved
6/22/2012
5 (c) 2012 HL7 International
6. V3 is too hard?
V3 puts needs of the modeler before the needs of
the implementer
◦ How we publish – targeted to reviewer
◦ What we publish – rationale, derivations, abstractions
◦ Content of instances – cluttered with semantic
structures
Learning curve is too steep
◦ Have you looked at a normative edition lately?
Tools to develop, maintain & constrain are all
custom
◦ Even newer tools build on top of “off-the-shelf” UML
are heavily customized
6/22/2012 (c) 2012 HL7 International 6
7. V3 is too hard - result
Development process is slow
◦ 3-7+ years for a domain to become
normative
Poor market penetration
◦ Very little up-take without major
sponsorship (and investment) by large
projects
◦ V3 messaging is non-starter in the
US, despite massive activity & investment
in healthcare interoperability
CDA is used, but in many cases using
„local‟ semantics
6/22/2012 (c) 2012 HL7 International 7
8. So – we should throw away
v3?
No!
◦ V3 is still useful
◦ Foundation for FHIR under the covers
Couldn‟t do FHIR if we hadn‟t done v3 first
◦ V3 has been used successfully in environments
where needed implementer support resources can
be provided
◦ V3 and CDA will continue to be supported for as
long as the implementation community
wishes, just like v2
◦ FHIR is “bleeding edge”, so many projects may
wish to stick with current directions for at least the
next few years.
6/22/2012 (c) 2012 HL7 International 8
9. Documents are not enough - I
“But what about CDA?”
◦ CDA has many lessons to teach us:
Wire format stability is essential
Provide an extension mechanism
Though CDA extension is quite problematic
Text (human-to-human) interoperability is critical
stepping stone
Incremental Interoperability
Breaking data into “chunks” (sections) is helpful
◦ That said:
CDA is successful, but in many cases in spite of
rather than because of v3
Doesn‟t support workflow
6/22/2012 (c) 2012 HL7 International 9
10. Documents are not enough -
II
Good semantic representation still requires a
good knowledge of the RIM
◦ Lots of templates with poor or non-existent
semantics
Wire format overly cluttered
◦ Implementers tolerate it because there‟s nothing
better
◦ Strong push for things like Green CDA
Interoperability dependent on consistent
templates
◦ Roll-your-own CDA instance non-interoperable
except as text
While extensibility exists, its use is highly
frowned upon
6/22/2012 (c) 2012 HL7 International 10
11. V2 needs a transition path
V2 implementations will be around for
another 20+ years
◦ Many of them 2.3 and 2.3.1
However, v2 does not provide a
modern platform for internal processing
and manipulation of healthcare data
◦ And in the eyes of most implementers, nor
does v3
We need something the v2
implementers can start using
internally, and possibly eventually
migrate to using for exchange
6/22/2012 (c) 2012 HL7 International 11
12. New Markets
If someone is building a new iOS
healthcare app (and thousands
are), what standard do we point them
at?
If someone wants to provide a cloud
based health app that integrates with
social networks, what standard should
they use?
If a vendor wants to provide a simple to
use standards based API to cloud
based health integration services, what
standard should they extend?
If a government wants to implement a
6/22/2012 (c) 2012 HL7 International 12
13. The world has evolved
And HL7 needs to too . . .
V3 was first conceived almost 15 years
ago, and leveraged approaches older
than that
◦ XML was new
◦ XML Schema didn‟t even exist
The technology and approach of
interoperability has changed since then
◦ We need to get current or risk becoming
irrelevant
6/22/2012 (c) 2012 HL7 International 13
15. Fresh Look
In January 2011, the HL7 Board initiated a
project called “Fresh Look”
◦ Mandate was to identify “what would we do if we were
to revisit the healthcare interoperability space from
scratch?”
At the May 2011 WGM, there was an “official”
meeting of the Fresh Look taskforce
◦ Didn‟t accomplish a whole lot
◦ There was also an “unofficial” meeting that took over
an evening RIMBAA session and was broadly attended
◦ Much of the discussion was focused on HL7 v3 pain
points
No desire to abandon good work done HL7 Internationaldefinitely a 15
6/22/2012 (c) 2012
so far, but
16. RFH/FHIR
Prior to Sept. 2011 meeting, Grahame Grieve posted a number
of articles on his blog discussing some of the challenges (and
successes) of HL7 v3
Culmination was release of first draft of RFH – Resources for
Healthcare
◦ Not a complete specification, but complete enough to show roughly
how it would work, including example instances and model design
Reviewed at the Sept. 2011 WGM and met with a very positive
response
Re-banded as FHIR as other projects with RFH TLA
Overwhelming interest in Vancouver in May
6/22/2012
16 (c) 2012 HL7 International
18. WHAT IS FHIR?
6/22/2012 (c) 2012 HL7 International 18
19. What is FHIR?
Fast Healthcare Interoperability Resources
◦ http://www.hl7.org/fhir
◦ Pronounced “FIRE”
As significant as change from v2 to v3
◦ Won‟t be marketed as “v4” though
◦ New artifacts, methodology, tools, publishing approach
◦ Still built on v3 RIM, vocab & datatypes, but details
hidden
Inspired by commercial API: Highrise (37 signals)
Open Source license (don‟t need to be an HL7
member)
◦ At least until version 1.06/22/2012 (c) 2012 HL7 International 19
20. FHIR premises
80/20 rule
◦ Only include data elements in the core
artifacts if 80% of all implementers of that
artifact will use the data element
Allow easy extension for the remaining
20% of elements
◦ which often make up 80% of current specs
◦ Vocabulary approach to extension
definition
Focus publication on documenting
what the implementer needs, not what
the modelers thought or designers
need to remember 6/22/2012 (c) 2012 HL7 International 20
21. FHIR premises (cont‟d)
Be concise – every word written is a
word that must be read 1000s of times
Wire format (XML) rules – no ITSs –
we design the physical, not the abstract
JSON is a (mostly) first class citizen
◦ But note gotcha‟s with conversion with
XML
Wire format stability
◦ Names & paths are the same – likely
forever
Retain rigor of HL7 v3, but don‟t force
implementers to look at it – od need to
6/22/2012 (c) 2012 HL7 International 21
22. FHIR Basics: Resources
Build around the concept of “resources”
◦ Small, discrete concepts that can be
maintained independently
◦ Aligns with RESTful design philosophy
◦ Similar to the concept of CMETs, but
there‟s only *one* model per resource
◦ Each resource has a unique id
◦ Resources are smallest units of transaction
6/22/2012
22 (c) 2012 HL7 International
23. FHIR Resources: Model
Each resource is modeled using developer friendly
XML
◦ XML does not reflect RIM-based modeling
◦ No classCodes, moodCodes, etc. visible
◦ Strong ontology behind the scenes that does link to
RIM and vocabulary
Uses a variant of the ISO datatypes
◦ Simplifies some things (by moving them out of
datatypes)
◦ Adds support for simplifications such as human-
readable dates, human-readable ids
Strong interest from openEHR to collaborate
6/22/2012
23 (c) 2012 HL7 International
29. FHIR Resources: Extensions
Built-in extension mechanism
◦ Extensions are defined using name, value, link-
point
Name is tied to robust terminology with full RIM modeling
Link point identifies what element of the base resource or
other extension the extension “attaches” to
◦ Idea is the elements used by 80% of implementers
(in code of 80% of implementation solutions) are
part of the base resource.
All other elements are handled as extensions
Extension is not a “dirty word” in FHIR
◦ Wire format remains stable, even as extensions
Extensions spec
occur
6/22/2012
29 (c) 2012 HL7 International
30. FHIR Resources: Human Text
Full support for textual mark-up
◦ In v3, only CDA provides for free-text mark-
up for all elements. Messaging focuses on
discrete data.
◦ With FHIR, all resources, as well as all
resource attributes have a free-text
expression, an encoded expression or both
◦ Conformance controls whether discrete
data is required or not
◦ Ensures that FHIR can support the human-
readable interoperability delivered by CDA
◦ Mark up is xhtml directly
6/22/2012
30 (c) 2012 HL7 International
31. FHIR Basic Resource
Base Resource
Resources
Extensions
Extensions
Represented as XML or JSON
Eg Person with local and HL7
extensions
6/22/2012
31 (c) 2012 HL7 International
32. Profiles
Further define a „generic‟ resource
◦ Lipid Profile
What entries are allowed
Coding systems etc.
◦ Current medications profile
Create a profile with multiple resources
◦ Eg a „vitals‟ profile
6/22/2012
32 (c) 2012 HL7 International
33. FHIR Profiled Resource
Base Resource
Specify:
• Restrictions
Extensions • Extensions
• Terminology
Extensions
Eg Lipid profile with a specific set of
results
Can apply to multiple resources
◦ Package as Aggregation Profile spec
6/22/2012
33 (c) 2012 HL7 International
34. Aggregations
Atom „wrapper‟
Atom Header
Resource 1
Resource 2
Aggregation spec
Use Atom format where there are multiple
resources in a single package eg:
◦ Search, Message, Document
6/22/2012
34 (c) 2012 HL7 International
35. FHIR Document
Atom
Document resource (header)
Resource 1
Resource 2
Document spec
A point in time collection of resources
Can be a ‘stand alone’ document (like CDA) or a aggregated resource
type (often profiled)
‘child’ resources are like CDA sections
Can include attachments!
6/22/2012
35 (c) 2012 HL7 International
36. FHIR Messages
Collection of resources sent as a result of some real-
world event intended to accomplish a particular
purpose
Event Codes & Definitions, like HL7 v2
V2 segments broadly map to resources
Some message profiles will be defined by
HL7, others by projects or implementers
Includes a “Message” resource, similar in purpose to
Message wrapper and MSH segment
May have associated behavior
Can be conveyed via MLLP, SOAP or other means
Message spec
6/22/2012 (c) 2012 HL7 International 36
37. Exchange Patterns
Resources can be used with a simple RESTful interface
spec
◦ Predictable URL
◦ HTTP based atomic transactions for CRUD
Operations
◦ Transactions for more complex interactions
Delete may not be honored and is not a true delete
Use with a RESTful framework is not required
◦ Can aggregate resources into documents and send as a group
spec
◦ FHIR provides a classic event based messaging framework
spec
◦ Can use resources in custom services / HL7 International
6/22/2012 (c) 2012 SOA as desired spec 37
38. Exchange Patterns II
REST (all)
Initiator
SOAP (all) Recipient
(sender, c
(Server)
onsumer)
font
Mailbox
(Message, Document)
„Classical‟ HL7 exchange patterns:
◦ Messages
◦ Documents
◦ Services
6/22/2012
38 (c) 2012 HL7 International
39. Conformance
Conformance spec
How an application supports FHIR
Human and computer readable
6/22/2012 (c) 2012 HL7 International 39
40. Conformance - II
Hey dude, what do you know?
I can do people and lab results
(using NZ extensions and profiles)
Initiator Excellent. Give me the latest lipid profile Recipient
(sender, c For David Hay (NHI=WER4568) (Server)
onsumer)
Here you go (It‟s normal)…
Got it. Thanks
6/22/2012
40 (c) 2012 HL7 International
42. Tools
Generation tool built in Java. Anyone can build the publication
at will
Source files maintained as xml spreadsheets
◦ Easy Editing
◦ Easy source control & Easy merging
◦ Easy importing into whatever
May get more sophisticated tooling over time (e.g. vocab
support)
Will likely need tooling to help with mapping and particularly
with defining conformance profiles
Have existing reference implementations
Need registry tool to manage6/22/2012 (c) 2012 HL7 Internationaltoo
registered extensions 42
43. Publishing
Current version at
http://www.hl7.org/fhir
◦ Implies a new & different ballot publication
process
◦ FHIR is balloted as a single spec like v2
Instance example mandatory
Publication automatically generated
from source files – by anyone
◦ Schemas
◦ HTML
◦ Validation of instance example
◦ reference implementations:
6/22/2012 (c) 2012 HL7 International 43
44. Migration
Realistically, we don‟t expect anyone to migrate existing
interfaces any time soon. Initial adopters will be green-
field, new technology
V2
◦ Already have an integration engine that supports translation
between v2 and FHIR
◦ 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
V3
◦ Easier as based on same model
6/22/2012 (c) 2012 HL7 International 44
46. Health Information Exchange
National Services Regional Services Regional Enabling Regional CDR
Services
Sector Indices
Laboratory IS Record Locator
NHI, HPI etc..
HIE Adapter
Health Information Exchange (HIE)
Data
Service
FHIRData
Service
Data
Service
Data
Service
HIE Adapter
HIE Adapter
Integrated Family Pharmacy Dispensing Maternity Shared Care
Health System System System
HIE Adapter
GP PMS Hospital PAS Immunization Register
Provider Services
and Personal Services
47. Relationship to:
openEHR
IHE
◦ XDS & other profiles
CDA
◦ CCD, Consolidated CDA
HL7 V3
HL7 v2
hData
Terminologies (SNOMED, LOINC)
6/22/2012 (c) 2012 HL7 International 47
48. When to implement
Can implementers start doing FHIR
before it‟s “official”?
◦ Yes. And some already are
◦ Take the idea and run with it. Try things.
But be aware that you can‟t claim it‟s
“standard” and that retrofitting to become
standard may be necessary later
6/22/2012 (c) 2012 HL7 International 48
49. Why should NZ be involved
FHIR has tremendous traction
◦ It solves a real problem
It is easy on implementers
◦ Familiar standards, tools
Rooted in solid information models
◦ RIM, openEhr
Early in development
◦ We can make sure it fits our needs
Consistent with our current Integration
strategy
◦ Reference Interoperability Architecture
6/22/2012 (c) 2012 HL7 International 49
50. Thank you!
6/22/2012 (c) 2012 HL7 International 50