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.

Interoperability, the rise of HL7 and FHIR

Slide deck from my Lecture for INFO I535 at SOIC, IUPUI (Spring 2016)

  • Login to see the comments

Interoperability, the rise of HL7 and FHIR

  1. 1. Interoperability, the rise of HL7, and FHIR Suranga Nath Kasthurirathne
  2. 2. About myself… • BEng in Software Engineering (Hons) 1st Class, University of Westminster , UK (2013) • PhD (Health Informatics) at Indiana University – Purdue University (IUPUI) 2018 (Expected) • Community Manager, (Asia-Pacific), OpenMRS • Google Summer of Code (GSOC) Co- Organization Administrator for OpenMRS
  3. 3. My interests • Clinical Decision Support (CDS) • Standards (HL7 and FHIR) • Health Information Architecture • Smart devices stuff • Being an ‘Early Adopter’ for OpenMRS • Anything else my boss wants me to do…
  4. 4. Disclaimers
  5. 5. What we will cover • Interoperability AKA the problem domain • Standards from the HL7 family • FHIR • Comparison of existing standards • FHIR demo • “What if” situations
  6. 6. The existing landscape • Healthcare quality is enabled by the accessibility and effective use of clinical data • Clinical data is being collected across the globe in numerous ways • Modern healthcare is distributed by nature • Clinical information systems are often implemented in an ad-hoc manner. – These limitations have led to the fragmentation of health information
  7. 7. Observations • To ensure healthcare quality, we need actionable data • We have enough data, but not when and where we need it • Data must be available where needed, when needed • We need standardized data exchange
  8. 8. Ontology The specific words that need to be used in the letter Content structure The structure and specific type of information in the letter or package – how to write a business letter Transport The method used to move the letter or package (e.g., truck, plane, boat) from point A to point B Security Sealing the envelope or the package Services Delivering to intended recipient and being able to find their address Interoperability Building Blocks Semantic Syntactic Technical Slide thanks to Masoud Hosseini (PhD Candidate, SOIC)
  9. 9. Syntactic Interoperability and standardization • Decades old domain • Numerous competing standards – HL7, DICOM etc. • Different versions – HL7 V2 and V3, CDA, CCD • Wide range of commercial tools / API’s – Mirth, HAPI, NHAPI, Everest Have these accomplished their goals?
  10. 10. The HL7 Family • Health Level Seven International (HL7) • Since 1987 • A not-for-profit, ANSI-accredited standards developing organization • (Aims to) provide a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services.
  11. 11. HL7 V2 • Multiple message types – Patient Administration (ADT) – Orders (ORMs) – Results (ORUs) – Charges (DFTs): Money, of Course! -are-the-hl7-message-types/
  12. 12. Each message type contains many messages • ADT-A01 – patient admit • ADT-A02 – patient transfer • ADT-A03 – patient discharge • ADT-A04 – patient registration • ADT-A05 – patient pre-admission • ADT-A08 – patient information update • ADT-A11 – cancel patient admit • ADT-A12 – cancel patient transfer • ADT-A13 – cancel patient discharge
  13. 13. Each message composed of multiple segment • MSH: Message Header • PID: Patient Identification • PV1: Patient Visit Information • OBR: Observation Request • OBX: Observation Segment
  14. 14. HL7 RIM Slide thanks to Masoud Hosseini (PhD Candidate, SOIC)
  15. 15. HL7 V3 • A suite of specifications based on HL7’s Reference Information Model (RIM) • Both messaging and document standards
  16. 16. Clinical Document Architecture (CDA) • A document markup standard that specifies the structure and semantics of clinical documents. • CDA conforms to the HL7 V3 Implementation Technology Specification (ITS) • Is based on the HL7 Reference Information Model (RIM), and uses HL7 V3 data types.
  17. 17. A CDA document could be • Discharge summary • Referral • Clinical summary • History/physical examination • Diagnostic report • Prescription etc. • Any document that might have a signature is a viable document for CDA.
  18. 18. Levels of Interoperability • Level 1: CDA Header plus a body consisting of an unstructured blob, such as PDF, DOC, or even a scanned image. • Level 2: CDA Header plus an XML body with narrative blocks. Each section identified with a code. • Level 3: CDA Header plus an XML body with narrative blocks and entries. The section should be encoded with the full power of the RIM with vocabulary such as LOINC, SNOMED, CPT, etc.
  19. 19. Continuity of Care Document (CCD) • A constraint on the HL7 Clinical Document Architecture (CDA) standard • Meaningful Use, Stage 1: CCD and Continuity of Care Record (CCR) were both selected as acceptable extract formats for clinical care summaries.
  20. 20. Consolidated CDA (C-CDA) • Meaningful Use, Stage 2: CCD, but not the CCR, was included as part of the standard for clinical document exchange. The selected standard is known as the Consolidated Clinical Document Architecture (C-CDA) • Developed by Health Level 7 and includes nine document types
  21. 21. Examples!
  22. 22. OpenMRS and the HL7 family HL7 V2 Import Yes ADTA08 & ORUR01 in OpenMRS core, RGRTA module(ORU,ADT), CHICA module (ADT, ORU,VXR,VXX) HL7 V2 Export Yes HL7Query module, RGRTA module(ADT,ORU), CHICA module (ORU,VXQ, VXU) CCD Export Yes Export CCD module (GSOC) CCD Import No RGCCD module CDA Export Yes… CDA Generator module (GSOC) CDA Import No
  23. 23. FHIR • Fast Health Interoperable Resources • The latest and the greatest • Combines the best features of HL7’s Version 2, Version 3 and CDA • Published as a Draft Standard for Trial use • Will (eventually) become a full normative specification (in 2016?) • Currently undergoing rapid adoption
  24. 24. FHIR resource types
  25. 25. FHIR Maturity Model (FMM) • Based on the CMM (Capability Maturity Model) framework • Seeks to inform a sense of how mature a resource is • Informed by implementability! ty_Model
  26. 26. FHIR Operations FHIR Documents
  27. 27. FHIR Value Sets • valuesets.html
  28. 28. FHIR Profiles • The (base) FHIR specification describes a set of (base) resources • There is wide variability between jurisdictions and across the healthcare ecosystem around practices, requirements, regulations, education and what actions are feasible and/or beneficial. • Therefore, FHIR specification usually requires further adaptation to particular contexts of use.
  29. 29. Adaptations can specify • Rules about ; – Which resource elements are / are not used, and what additional elements are added that are not part of the base specification – Which API features are used, and how – Which terminologies and used in particular elements – Descriptions of how the resource elements and API features map to local requirements and/or implementations
  30. 30. HL7 V2 Vs. CDA Vs. FHIR Contd. • Extensibility – V2 offers Z segments whose meaning is opaque unless prior communication by sender. In comparison, the meaning of FHIR extensions are discoverable by resolving the URI that defines each extension • Cleanliness – V2 messages are the most cluttered , CDA less cluttered, FHIR least cluttered • Relationship to non-HL7 Standards – FHIR resources can provide direct implementation of functionality from other standards such as DICOM • JSON – FHIR supports JSON
  31. 31. HL7 V2 Vs. CDA Vs. FHIR • Practical applications – CDA is restricted to clinical settings. V2 and FHIR can be used in other contexts as well. • Reusability – V2, CDA and FHIR are all built around the idea of re-usable segments, but only FHIR segments maintain truly independent identities • Human readability – V2 offers NTE segments, FHIR and CDA require human readable content for all resources • Messaging paradigms – V2 supports event based messaging. CDA does documents. FHIR does both, plus REST and service models
  32. 32. Why FHIR stands out… • Is for developers • supports JSON • Modular by design • In DSTU, and willing to listen to our needs • Plenty of interest • Adoption by major players – Project Argonaut
  33. 33. Demo!
  34. 34. Resources • FHIR Documentation : • Mailing lists : / • Hapi Demo server: • FHIR Reference implementation : HIR/ Contacts :
  35. 35. Questions
  36. 36. Thank You!