David Hay HL7 New Zealand

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

14. FHIR BACKGROUND
6/22/2012 (c) 2012 HL7 International 14

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

17. ast (to design & implement)
ealthcare
nteroperability
esources
6/22/2012 (c) 2012 HL7 International 17

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

24. Simplified datatypes model
6/22/2012 (c) 2012 HL7 International 24

25. Person resource: UML
Person spec
6/22/2012 (c) 2012 HL7 International 25

26. Person resource: XML
definition
6/22/2012 (c) 2012 HL7 International 26

27. Person resource: sample
6/22/2012 (c) 2012 HL7 International 27

28. Person resource: schema
6/22/2012 (c) 2012 HL7 International 28

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

41. TOOLING AND MIGRATION
6/22/2012 (c) 2012 HL7 International 41

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

45. RELATIONSHIP
WITH OTHER STANDARDS
6/22/2012 (c) 2012 HL7 International 45

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