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

1. Interoperability, the rise
of HL7, and FHIR
Suranga Nath Kasthurirathne

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. 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. Disclaimers

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. 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. 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. 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. 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. 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. HL7 V2
• Multiple message types
– Patient Administration (ADT)
– Orders (ORMs)
– Results (ORUs)
– Charges (DFTs): Money, of Course!
http://healthstandards.com/blog/2006/10/05/what
-are-the-hl7-message-types/

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. Each message composed of multiple
segment
• MSH: Message Header
• PID: Patient Identification
• PV1: Patient Visit Information
• OBR: Observation Request
• OBX: Observation Segment

14. HL7 RIM
Slide thanks to Masoud Hosseini (PhD Candidate, SOIC)

15. HL7 V3
• A suite of specifications based on HL7’s
Reference Information Model (RIM)
• Both messaging and document standards
http://ontology.buffalo.edu/HL7/doublestandards.pdf

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. 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. 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. 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. 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. Examples!
http://wiki.ihe.net/?title=Profiles

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. 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. FHIR resource types
https://www.hl7.org/fhir/resourcelist.html

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!
http://wiki.hl7.org/index.php?title=FHIR_Maturi
ty_Model

26. FHIR Operations
https://www.hl7.org/fhir/operations.html
FHIR Documents
https://www.hl7.org/fhir/documents.html

27. FHIR Value Sets
• https://www.hl7.org/fhir/terminologies-
valuesets.html

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. 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. 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. 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. 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. Demo!

34. Resources
• FHIR Documentation :
http://hl7-fhir.github.io/
• Mailing lists : fhir@lists.hl7.org /
• Hapi Demo server: http://fhirtest.uhn.ca/
• FHIR Reference implementation :
http://www.hl7.org/documentcenter/public/standards/F
HIR/fhir-0.0.81-Java-0.81.zip
Contacts : surangak@openmrs.org

35. Questions

36. Thank You!