Looking to the Future: Leveraging Emerging Standards and HL7 ...

Looking to the Future: Leveraging Emerging Standards and HL7® FHIR®

Russell B. Leftwich, MD Senior Clinical Advisor, Interoperability InterSystems

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

Learning Objectives

• Driving factors behind new standards • HL7 FHIR and REST • Everything is on FHIR • Consolidated CDA • IHE Structured Data Capture Profile

Agenda

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.

8

HL7® version2 (2.x) is 30 years old.

HL7® CDA is over 10 years old.

9

What if HL7 created a new interoperability

standard starting from scratch?

HL7® FHIR®

Fast

Healthcare

Interoperability

Resources

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

FHIR Supports 4 InteroperabilityParadigms

11

RESTful Documents

Messages Services

REST

REpresentational State

Google, Twitter, FaceBook

Your favorite travel website

12

Your favorite travel site

13

AnyAirplaneFlight.com

Resources

Defined behavior

and meaning

Smallest unit of

transaction

“of interest”

to healthcare

14

“Resources” are: Known identity / location

Small logically discrete units of exchange

®

What’s a Resource?

• Administrative Patient, Practitioner, Organization

• Clinical Concepts Allergy, Condition, Family History, Care Plan

• Infrastructure Document, Message, List

Examples Non-examples

• Gender Too small

• History & Physical Too big

• Blood Pressure Too specific

• Intervention Too broad

How many Resources?

Release 1.0: 50 Resources

Release 2.0: 49 Additional

Resources

Goal: 100-150 . 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

Data Repository

HIE Platform

Mobile App

EMR LIS RLS

FHIR Layer

What if you took scissors and cut a History & Physical

into data elements?

24

Detailed Clinical Models

Detailed Clinical Models:

Profiles that give data context and semantic interoperability.

25

When is a blood pressure not a blood pressure?

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

50 Resources STU 1.0

2014

99 Resources Vocabulary server

FHIR Maturity Model STU 2.0

2015

STU 2.1

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 Document Architecture (CDA) R2 ANSI-approved

2006 HL7 approves Continuity of Care Document (CCD) which harmonizes CDA and Continuity of Care Record (CCR)

2009 Meaningful Use (MU) enacted in stimulus bill requiring EHR certification and data exchange

2010 Release of MU Stage 1 regulations requiring providers to test CCD or CCR exchange

ANSI American National Standards Institute CCD Continuity of Care Document C-CDA Consolidated Clinical Document Architecture CCR Continuity of Care Record

2011 HL7 approves Consolidated CDA (C-CDA 1.1) that updates CCD and eight other document types

2012 Release of Stage 2 regulations requiring primary document standard of C-CDA for in data exchange

2014 Stage 2 providers must send electronic documents in >10% of care transitions

2015 C-CDA 2.1 published by HL7 and selected as primary standard in Stage 3

Adapted from Source:MedTech Boston 2014 https://medtechboston.medstro.com/blog/2014/08/11/c-cdas-the-fuel-for-medical-apps/

CDA Clinical Document Architecture EHR Electronic Health Record MU Meaningful Use HL7 Health Level 7

Consolidated-Clinical Document Architecture Release 2.0

• Continuity of Care Doc (CCD) • Discharge Summary • Referral Note • Consultation Note • Progress Note • Diagnostic Imaging • Operative Note • Procedure Note • Transfer Summary • Care Plan • Referral Note

Document Types 100 C-CDA Section Templates • Header - patient • Allergies • Medications • Advance Directives • Chief Complaint • Reason for Visit • Procedures • Vital Signs • Social History • Family History • ….. 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

CDE Library

4

1

5

Sends requested form/template

Fills, stores/transmits structured data

Sends request for form/template

3 Converts, populates and displays form

Extract, Transform,

and Load Data by form/ template

Forms Manager

Forms Filler

Actor Key

Structured Data Capture Workflow

2

Form Library

External Repository

SDC

Sco

pe

Form/Template Repository

IHE SDC Workflow with Standards

41

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)

Interoperability is a Journey

Thank You

Questions?

[email protected]