Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction to HL7 FHIR

David Hay
HL7 New Zealand

  • Login to see the comments

Introduction to HL7 FHIR

  1. 1. June, 2012INTRODUCTIONTOHL7 FHIR Grahame Grieve Adapted for Ewout Kramer HINZ by David Lloyd McKenzie Hay 6/22/2012 (c) 2012 HL7 International 1
  2. 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. 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: 6/22/2012 (c) 2012 HL7 International 3
  4. 4. WHY FHIR? 6/22/2012 (c) 2012 HL7 International 4
  5. 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. 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. 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. 8. So – we should throw awayv3? 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. 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. 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. 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. 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. 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. 14. FHIR BACKGROUND 6/22/2012 (c) 2012 HL7 International 14
  15. 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. 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. 17. ast (to design & implement) ealthcarenteroperability esources 6/22/2012 (c) 2012 HL7 International 17
  18. 18. WHAT IS FHIR? 6/22/2012 (c) 2012 HL7 International 18
  19. 19. What is FHIR? Fast Healthcare Interoperability Resources ◦ ◦ 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. 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. 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. 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. 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. 24. Simplified datatypes model 6/22/2012 (c) 2012 HL7 International 24
  25. 25. Person resource: UML Person spec 6/22/2012 (c) 2012 HL7 International 25
  26. 26. Person resource: XMLdefinition 6/22/2012 (c) 2012 HL7 International 26
  27. 27. Person resource: sample 6/22/2012 (c) 2012 HL7 International 27
  28. 28. Person resource: schema 6/22/2012 (c) 2012 HL7 International 28
  29. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 39. Conformance Conformance spec How an application supports FHIR Human and computer readable 6/22/2012 (c) 2012 HL7 International 39
  40. 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. 41. TOOLING AND MIGRATION 6/22/2012 (c) 2012 HL7 International 41
  42. 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. 43. Publishing Current version at ◦ 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. 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. 45. RELATIONSHIPWITH OTHER STANDARDS 6/22/2012 (c) 2012 HL7 International 45
  46. 46. Health Information ExchangeNational 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. 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. 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. 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. 50. Thank you! 6/22/2012 (c) 2012 HL7 International 50