Looking to the Future:

Leveraging Emerging Standards and

HL7® FHIR®

Russell B. Leftwich, MD
Senior Clinical Advisor, Interoperability
InterSystems
Learning Objectives
• Discuss the importance, the driving factors, and the
impact of emerging healthcare standards;
• Recognize the key organizations that are critical in
ensuring that health information technology among
systems are interoperable;
• Identify specific ways that standards organizations like
HL7 and IHE are preparing for the future.
Agenda
• Driving factors behind new standards
• HL7 FHIR and REST
• Everything is on FHIR
• Consolidated CDA
• IHE Structured Data Capture Profile
Evolution of standards driven by
new technologies and
new use cases
Drivers for New Standards
Shift from off-line to on-line
• BYOD (clinician / nursing / patient apps)
• Mobile outside health care

Shift towards data transparency

• Examples: MU, NHS GPSoC, VNA, ECM
• Access to data in distributed systems

Growth of data and knowledge

• Big Data
• Limits on human capacity
5
 Growth of Mobile
• Mobile phone market
– first billion mobile phones: 20 years
– second billion phones: 4 years
– third billion: 2 years
– Fourth & fifth billion: 1 year – in 2013

Gora Data, Cal2Cal

The burning platform

William Stead, et al
Academic Medicine. 86(4): 429-434, April 2011.
HL7® version2 (2.x)
is 30 years old.

HL7® CDA
is over 10 years old.

8
What if HL7 created a
new interoperability
standard starting from
scratch?

9
 ®
HL7 FHIR ®

Fast

Healthcare

Interoperability

Resources

® Health Level Seven, HL7 and FHIR are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office.
10
 FHIR Supports
4 InteroperabilityParadigms

RESTful Documents

Messages Services

11
 REST
REpresentational State

Google, Twitter, FaceBook

Your favorite travel website

12
Your favorite travel site

AnyAirplaneFlight.com

13
 Resources ®

“of
“Resources” are: interest”
Known
identity /
to location
healthcare

Smallest
unit of
Small logically
discrete units
transaction
Defined
of exchange behavior
and
meaning

14
What’s a Resource?
Examples Non-examples
• Administrative • Gender
Patient, Practitioner, Too small
Organization
• History &
• Clinical Concepts Physical
Allergy, Condition, Too big
Family History,
Care Plan • Blood Pressure
Too specific
• Infrastructure
Document, • Intervention
Message, List Too broad
How many Resources?

Release 2.0: Goal:

Release 1.0:
49 Additional 100-150
50 Resources
Resources . Resources
FHIR Extensions: 80/20 Rule
FHIR Resources have data elements if
80% of existing systems include them

Extensions are the other 20%

 Meet specific use cases
 The encoding looks no different,
just not in the standard
FHIR Profiles
Profiles are implementation guides
Built for specific use cases
Encompass the entire scenario
Profiles include entire implementation
Multiple Resources & Extensions
Vocabulary/terminology/code binding
Everything is still shared, available
FHIR servers - public access to Profiles
HL7 hosts HAPI server to share
Ah-ha moment on FHIR
Regardless of paradigm the content is the same*

It’s straight-forward to share content across paradigms

e.g. Receive a lab result in a message.
Package it in a discharge summary document

It also means constraints can be shared across paradigms

e.g. Define a profile for Blood Pressure; use
same resources in messages, documents,
REST and services

* Ah-ha!!
 Making FHIR
clinically useful
20
Example: a mobile app
A mobile application for a clinician providing
access to data in one's own hospital systems
using a mobile device.
 Collect and present clinical information
 Record information
 Order meds/tests, scheduling
 Get decision support
 Save a summary in a Document Repository
Mobile App FHIR Layer

HIE Platform

Data
EMR LIS RLS
Repository
 What if you took
scissors and cut a
History & Physical
into data elements?

24
Detailed Clinical Models
When is a blood pressure not a blood pressure?

Detailed Clinical Models:

Profiles that give data context
and semantic interoperability.
25
 CIMI

Clinical Information Modeling Initiative

• Fostered by HL7 in 2010
• Create reference detailed models of clinical data
• Create processes to transform reference model
into any one of existing detailed clinical models
Timeline for FHIR development
99 Resources
Vocabulary server
50 Resources FHIR Maturity Model
STU 1.0 STU 2.0 STU 2.1

2014 2015 May 2016

www.FHIR.org
 FHIR Maturity Model

• Based on existing objective software development model

• 6 stages of maturity: 0-5
• Applied at the FHIR Resource level
• Based on development of FHIR Resource + implementations
 iPhone Maturity Model
• People purchased and used the iPhone 2
• It did not have all of the features of iPhone 3
• Some features were improved, some were added
• iPhone 6 is even better, but you can still use earlier iPhones
Everything is on FHIR
SMART on FHIR
adaptation of Harvard SMART app platform
http://smarthealthit.org/interoperability/

CDA on FHIR
mapping CDA documents to FHIR
construct/deconstruct CDA documents

HL7 v2 messages on FHIR

mapping v2 message segments to FHIR
… and catching FHIR
IHE Mobile Access to Health Documents
Profile (MHD) on FHIR
adding RESTful interface to IHE XDS

IHE Reconciliation Profile on FHIR

HL7 Consolidated Clinical
Document Architecture
(C-CDA)
 How Did We Get Here?
2005 Clinical 2009 Meaningful Use 2011 HL7 approves 2014 Stage 2
Document (MU) enacted in Consolidated CDA providers must
Architecture stimulus bill requiring (C-CDA 1.1) that send electronic
(CDA) R2 ANSI- EHR certification and updates CCD and documents in
approved data exchange eight other document >10% of care
types transitions

2006 HL7 approves 2010 Release of MU 2012 Release of Stage 2015 C-CDA 2.1
Continuity of Care Stage 1 regulations 2 regulations requiring published by HL7
Document (CCD) requiring providers to primary document and selected as
which harmonizes test CCD or CCR standard of C-CDA for primary standard
CDA and Continuity exchange in data exchange in Stage 3
of Care Record (CCR)

ANSI American National Standards Institute CDA Clinical Document Architecture

CCD Continuity of Care Document EHR Electronic Health Record
C-CDA Consolidated Clinical Document Architecture MU Meaningful Use
CCR Continuity of Care Record HL7 Health Level 7

Adapted from Source:MedTech Boston 2014

https://medtechboston.medstro.com/blog/2014/08/11/c-cdas-the-fuel-for-medical-apps/
 Consolidated-Clinical Document Architecture
Release 2.0

Document Types 100 C-CDA Section Templates

• Continuity of Care Doc (CCD) • Header - patient
• Discharge Summary • Allergies
• Referral Note • Medications
• Consultation Note • Advance Directives
• Progress Note • Chief Complaint
• Diagnostic Imaging • Reason for Visit
• Operative Note • Procedures
• Procedure Note
• Vital Signs
• Transfer Summary
• Social History
• Care Plan
• Family History
• Referral Note
• ….. And even more
C-CDA R2.0 care plan document

Lisa Nelson, Lantana Consulting, for Blue Cross Blue Shield Association, 2015
IHE STRUCTURED DATA CAPTURE
PROFILE
(SDC)
 SDC Overview
• Launched in 2013 in collaboration with NIH (NLM, NCI), AHRQ, FDA,
CMS and CDC
• Uses the structured data within EHRs to supplement data collected for
other purposes, such as:
• Clinical research (Patient Centered Outcomes Research/ Comparative
Effectiveness Research) (NLM)
• Patient safety event reporting (AHRQ) & Adverse Event Reporting (FDA)
• Public Health Reporting (CDC)
• Determination of Coverage (CMS)

38
 Value and Benefits
• Reduce the data collection burden.
• Improve clinical research by leveraging data in EHRs.
• Implement published interoperability standards.
• Contribute to and encourage the use of learning
health systems.
• Improve comparability of data to better inform
research, quality reporting and ultimately, improve
patient care.
• Contribute to projects which support more effective
use of informatics (e.g. registries, cohort
identification, and shared data across multiple sites).

39
 Structured Data Capture Workflow
CDE Library
1 Sends request for
form/template Form Library
Form/Template
Repository

Sends requested form/template 2

SDC Scope

3 Converts, populates
and displays form

4 Fills, stores/transmits structured data

Actor Key
5 Extract,
Forms
Transform, Filler
and Load Data by Forms
Manag
form/ template er
External
Repository
IHE SDC Workflow with Standards

SDC Standards
A. Standard for the
Common Data
Element (CDE)
B. Standard for the
structure of the
Form/Container
C. Standard for the
transactions
D. Guidance for pre-
and auto-population
(Optional)
41
Interoperability is a Journey
 Thank You

Questions?
[email protected]