Successfully reported this slideshow.

FHIR - more than the basics


Published on

Presentation given at HL7 Norway on april 1st, 2014. Subjects are: why a new standard? what are the basic building blocks of FHIR? What are profiles? How do we make documents out of resources? Also contains some example architectures.

Published in: Technology
  • Be the first to comment

FHIR - more than the basics

  1. 1. HL7 FHIR Out-of-the-box eHealth interoperability Ewout Kramer HL7 Norway, april 1st, 2014
  2. 2. Our common problem • Avoid speaking between lunch and afternoon coffee • No one is interesting to listen to for more than 45 minutes
  3. 3. So….Please… • I’ll break the presentation in 45 minutes • State your questions at anytime • Read your e-mail if you need to
  4. 4. (well, that’s relative) (that’s what we need) (the web technology bit)
  5. 5. STARTING A FHIR Why have something new?
  6. 6. Why something new?
  7. 7. “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?”
  8. 8. If your neighbour ‘s son can’t hack an app with <technology X> in a weekend….. you won’t get adopted
  9. 9. 10
  10. 10. WHAT’S IN THE BOX?
  11. 11. Slice & dice your data into “resources” MedicationPrescription Problem Cover 80% - Context independent - Unit of exchange/storage
  12. 12. Consistent documentation Organization “ACME Hospital” National Drive 322 Orlando, FL Organization “ACME Hospital” National Drive 322 Orlando, FL Patient MRN 22235 “Olaf Olafsson” 01-01-1994 Bergen Patient MRN 22234 “Ewout Kramer” 30-11-1972 Amsterdam Thousands of examples
  13. 13. Structure of a Resource (XML example)
  14. 14. 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
  15. 15. How many resources? Currently: about 40 • Administrative – Patient, Location, Encounter, Organization, • Clinical Concepts – AllergyIntolerance, Questionnaire, Observation • Infrastructure – ValueSet, Composition, Profile, Conformance Next up…still about 100 to go • Scheduling - Appointment, Availability, Slot • Financial - Claim, Account, Coverage • Consent Everything to cover C-CDA
  16. 16. Generic Specific Cover all usecases - (n)ever HL7v3 RIM HL7 CDA C-CCD openEHR RM HL7v2 IHE PDQ FHIR openEHR Archetypes openEHR Templates HL7v3 CMETS
  17. 17. + = Cover the 80% out of the box…
  18. 18. Organization “ACME Hospital” National Drive 322 Orlando, FL Patient MRN 22234 “Ewout Kramer” 30-11-1972 Amsterdam +Haircolor BROWN + Taxoffice Id NLOB33233 You can extend: - Resources - Elements of Resources - FHIR Datatypes
  19. 19. Extending a multiple birth Key = location of formal definition Value = value according to definition
  20. 20. ?
  21. 21. Package & publish: The Profile “My First Profile” V1.0 by Ewout
  22. 22. Support “Bottom-up re-use”
  23. 23. 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":"
  24. 24. Packaging & transport Yes, v2 style messaging is also supported!√ Yes, v3 CDA style documents are also supported! √
  25. 25. IN SUMMARY…
  26. 26. FHIR Manifesto (abridged) • Focus on implementers • Keep common scenarios simple • Leverage existing technologies • Make content freely available
  27. 27. Implementer support…
  28. 28. 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
  29. 29. 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
  30. 30. Questions?
  32. 32. “Source” of FHIR Straight from the HL7 SVN “code” respository at
  33. 33. Publication process .INI Publication tool ( Java, C#, Delphi eCoreDefinitions.xml Website Validation Schema’s Examples DictXml Resource profiles Resource UML examples
  34. 34. PLAYING WITH FHIR Combining resources into useful exchanges
  35. 35. It’s all about combining resources . . . 37 Diagnostic Report Patient Practitioner Observation Organization
  36. 36. Diagnostic Report Practitioner Patient Observation
  37. 37. FHIR server @ Practitioner Practitioner/87 Organization Organization/1 FHIR server @ Diagnostic Report DiagnosticReport/4445 Observation Observation/3ff27 In REST: Possibly distributed… 39 FHIR server @ Patient Patient/223 subject
  38. 38. encounters-with-fhir/
  39. 39. FHIR server Patient Observation Organization Patient Patient Observation Observation Diagnostic Report “Repository” model of healthcare Create Update Query Lab System Create Update Hospital System Create Update Query Subscribe
  40. 40. “Atom”: New reports in the mail
  41. 41. FHIR Document 43 Dr. Bernard Practitioner Patient Mary Patient Discharge Meds list Vital Signs list Pulse Observation BP Observation Dyclofenac MedicationPrescription Tamsulosin MedicationPrescription Kidney Stones Condition Discharge Summary Composition Chief Complaint section Physical section Medications section entry entry
  42. 42. FHIR Repository Regardless of paradigm the content is the same Lab System Receive a lab result in a message… FHIR Message FHIR Document …Package it in a discharge summary document National Exchange
  43. 43.
  44. 44. CONTROLLING THE FHIR Very short intro to Profiles
  45. 45. 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.
  46. 46. Constraining cardinality 48 Limit cardinality to 1..2 (e.g. to at maximum your organizations’ identifier + the national one) 1..2 1..1 Limit names to just 1 (instead of 0..*) Forbid any telecom elements 0..0 Note: something that’s mandatory in the core definition cannot be made optional in a profile
  47. 47. Limit value domains 49 Fix value: Only allow “active” Patients =“true” If deceased is given, it must be a dateTime, not a boolean Use our national codes for MaritalStatus Use another profiled Resource OrganizationNL
  48. 48. “Basic” Document 50 Practitioner Patient Any Resource Composition 0..* Section 0..1 subject
  49. 49. Document-NO Profile! 51 Practitioner-NO Patient-NO Medication Prescription-NO Discharge Meds list Vital Signs list Observation Condition Discharge Summary-NO Composition 1..1 Complaint section 0..1 Physical section 1..1 Medications section 0..1 Home situation section
  50. 50. What’s in a profile? Metadata Identifier Name, Version Publisher Description, Code Status Date (of publication) Constraints ExtensionDefn Conformance ValueSet Resource Extension
  51. 51. Tagging a Resource Patient MRN 22234 “Ewout Kramer” 30-11-1972 Amsterdam “I’m a VIP - My information cannot yet be disclosed” “This is TEST data! Don’t use!” “I’m an Organization as defined in the Norwegian Profile – see”
  52. 52. (Distributed) validation App’s server Store & Validate Country validation server Profile X Profile Y Profile Y
  53. 53. THE FHIRSTARTERS Some examples from early-adopters
  54. 54. Form Filler Form Repository Empty Questionnaires 1. Form Request + Patient data in FHIR Form Client 3. Filled out form Completed Questionnaires
  55. 55. FHIR FHIR
  56. 56. Patient & Provider registry CCD Documents Hospital System National Patient Portal References
  57. 57. INTEROP WITH V2/V3
  58. 58. V2 to FHIR bridge FHIR message processor Hospital System FHIR Repository FHIR REST FHIR Messages Note: Messages are events, REST exposes a “repository” Model of data…
  59. 59. 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
  60. 60. …and v2 mappings Every Resource has v2 mappings specified, e.g.: Patient identifier PID-3 name PID-5, PID-9 telecom PID-13, PID-14, PID-40 gender PID-8 birthDate PID-7 deceased[x] PID-30 address PID-11 maritalStatus PID-16
  61. 61. CDA to FHIR Document bridge Hospital System A FHIR Documents Note: Documents are compositions, • No update semantics • Context? • Wholeness? FHIR Repository FHIR REST FHIR Document processor
  62. 62. 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
  63. 63. …and v3 mappings Every Resource has v3 mappings specified, e.g.: Patient Patient identifier ./id name ./name telecom ./telecom gender ./administrativeGender birthDate ./birthTime deceased[x] ./deceasedInd address ./addr maritalStatus ./maritalStatus multipleBirth[x] .multipleBirthInd
  64. 64. 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 C- CDA 66
  65. 65. (XDS) references • 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. 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:
  66. 66. 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
  67. 67. 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)
  68. 68. 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. The specification has a good track record 2. It’s clear the new thing provides significant benefits • HL7 will support existing product lines so long as the market needs them
  69. 69. /03/30/setting-healthcare-interop-on-fire/
  70. 70. SMART DEMO
  71. 71.
  72. 72. BlueButton S M A R T S M A R T F H I R F H I R Any FHIR Server (PHRs!) F H I R
  73. 73. Let’s run a demo!
  74. 74. Next Steps for you • Read the spec at • Try implementing it • Come to a (European?) Connectathon! • • #FHIR • Implementor’s Skype Channel • FHIR Developer Days (November 24 – 26), Amsterdam • StackOverflow: hl7 fhir tag