Embed Size (px)
Citation preview
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
