JASON Report Task Force

June 18, 2014

David McCallie, co-chairMicky Tripathi, co-chair

2

Agenda

• Task force membership

• High-level workplan

• Charge

• Overview of JASON report

• Next steps

3

Task Force Members*

Policy/Standards Member Name Organization

Standards David McCallie Cerner

Policy Micky TripathiMassachusetts eHealth Collaborative

Policy Deven McGraw Manatt

Policy Gayle Harrell Florida State LegislatorPolicy Larry Wolf Kindred HealthcarePolicy Troy Seagondollar KaiserStandards Andy Wiesenthal DeloitteStandards Arien Malec RelayHealthStandards Keith Figlioli Premier, Inc.Standards Wes Rishel

Policy/Standards Larry Garber Reliant Medical Group

*Additional members have been invited

4

Workplan

Meetings Task

Wednesday, June 18th 9:00-10:30am ET • Review charges• Identify action steps

Tuesday, July 1st 3:30-5:00pm ET • Report deep dive

Tuesday, July 22nd 11:00am-12:30pm ET(we are looking to reschedule this meeting)

• Presentations?

Tuesday, August 5th 11:00am-12:30pm ET

Wednesday, August 6th • DRAFT recommendations - HITPC

Tuesday, August 19th 11:00am-12:30pm ET

Wednesday, August 20th • DRAFT recommendations - HITSC

Tuesday, September 2nd 11:00am-12:30pm

Joint HITPC/HITSC meeting • Final recommendations

5

Charge

• Analyze and synthesize feedback on the JASON report – Discuss the implications of the report and its impact on

ONC strategies– Assess the feasibility and impact of the JASON report on

ONC programs– Identify use cases and lessons learned from current

experience– Establish specific recommendations that can be

integrated into ONC’s strategic framework, specifically related to the interoperability roadmap

A Robust Health Data Infrastructure

P. Jon White, MDDirector, Health IT

Agency for Healthcare Research and Quality

About the report

• Sponsored by AHRQ in collaboration with ONC and the Robert Wood Johnson Foundation

• JASON is an independent scientific group that provides consulting services to the US government on matters of science and technology. It was established in 1959.

Study Charge

• How can complex data handling techniques and Internet-based technologies be applied to health care to promote the development of real-time integrated datasets at a scale seen in other industries?

• How can the various users of health data in the clinical research and public health communities be presented with tailored and highly specific data views in near real time based on routinely collected health data?

• As health data grows from megabits to gigabits per individual, what fine-grained analytics should be made available to patients and health care providers to guide health care decisions?

• What fundamental data management capabilities are needed to support potential future requirements in an open-ended manner?

• What are the national security consequences of not addressing comprehensive health data opportunities in clinical research and public health?

Briefing Organizations

Arizona State University

The Broad Institute

Cornell University Deloitte

Digitalmill HIMSS IBMKaiser

Permanente

MicrosoftNational Quality

ForumStanford

UniversityUC Davis

UC San Diego University of IowaVanderbilt University

The White House

Challenges identified

• Federation

• Jurisdiction

• Scalability

• User interface

• Interdisciplinary

• Front loaded cost

• Payer

• Business Model

• Exchange concept

• Data security

• Data integrity

• Access and curation

• Consent

• Intellectual property

• Legal liability

Key Findings

• The current lack of interoperability among data resources for EHRs is a major impediment to the unencumbered exchange of health information and the development of a robust health data infrastructure.

• Interoperability issues can be resolved only by establishing a comprehensive, transparent, and overarching software architecture for health information.

• The twin goals of improved health care and lowered health care costs will be realized only if health-related data can be used in the public interest, for both clinical practice and biomedical research.

• That will require implementing technical solutions that both protect patient privacy and enable data integration across patients.

Software Architecture

• For the purposes of this report, a software architecture defines a set of interfaces and interactions among the major components of a software system that ensures specified functionality.

Health IT Architecture Principles

• The patient owns his or her data • Be agnostic as to the type, scale, platform, and storage

location of the data

• Use published APIs and open standards, interfaces and protocols

• Encrypt data at rest and in transit

• Separate key management from data management

• Include metadata, context, and provenance of the data

• Represent the data as atomic data with associated metadata

• Follow the robustness principle: “Be liberal in what you accept, and conservative in what you send.”

• Provides a migration path from legacy EHR systems

Example Architecture

User Interface Apps

Middleware Apps

Semantics and Language Translation

Search and Index Functionality

“chart/record” data

“atomic” data w/

metadataCrypto Layer

Data Storage (logical)

Data Storage (physical)

Data Transport (logical)

Data Transport (physical)

Sto

vepi

pe

Leg

acy

Sys

tem

s

Ide

ntit

y, A

uth

ent

ica

tion

, A

uth

oriz

atio

n

Pa

tient

Priv

acy

Bun

dle

M

an

age

me

nt

Ke

y a

nd C

ert

ifica

te

Ma

na

gem

en

t

Published API

• A patient privacy bundle is a collection of fine-grained settings of default permission and inheritance settings for access privileges to electronic health data.o Both atomic data and metadata must be associated

with permissions o The patient controls access by electing a privacy

bundle

• A fine-grained permission system is flexible, and can accommodate many different types of security policies

• The choice of a patient privacy bundle implies an assumption of different levels of risk by the patient in return for different benefits for themselves and society

Patient Privacy and Risk Management

Recommendations (selected)

• Within 12 months, ONC should define an overarching software architecture for the health data infrastructure.

• EHR vendors should be required to develop and publish APIs that support the architecture of the health data infrastructure.

Topics for Discussion

• ONC should define an architecture this year.

• Patient privacy and related risk management should be addressed by the use of patient privacy bundles.

• The architecture should be supported by openly developed, published and tested APIs.

Blank