JASON Report Task Force July 1, 2014 - PowerPoint Presentation

Slide1

JASON Report Task Force

July 1, 2014

David McCallie, co-chair

Micky

Tripathi,

co-chairSlide2

Agenda

Taskforce membership updateRevised chargeMeeting scheduleDiscussion questions Listening session planning

7/1/20141Slide3

Task Force Members

Member Name

OrganizationRoleDavid McCallieCernerChairMicky TripathiMassachusetts eHealth Collaborative

Chair

Deven

McGraw

Manatt

Member

Gayle

HarrellFlorida State LegislatorMemberLarry WolfKindred HealthcareMemberTroy SeagondollarKaiserMemberAndy WiesenthalDeloitteMemberArien MalecRelayHealthMemberKeith FiglioliPremier, Inc.MemberWes RishelMemberLarry GarberReliant Medical GroupMemberJosh MandelChildren's Hospital BostonMemberNancy J. OrvisFHA/DoDEx OfficioTracy MeyerFHA/ONCEx OfficioJon WhiteHHSEx Officio

2Slide4

Revised Charge

Analyze and synthesize feedback on the JASON report Discuss the implications of the report and its impact on HHS, other Federal agencies and their strategiesAssess the feasibility and impact of the JASON report

on HHS and the broader HIT ecosystemIdentify use cases and lessons learned from current experienceEstablish specific recommendations that can be integrated into the Federal Health IT Strategic Plan and the ONC interoperability roadmap3Slide5

Updated Meeting Schedule

Meetings

TaskWednesday, June 18th 9:00-10:30am ET Review chargesIdentify action stepsTuesday, July 1st 3:30-5:00pm ET Review discussion questionsListening session planningThursday, July 31st 2:00-5:00pm ETListening sessionTuesday, August 5th 11:00am-12:30pm ET Tuesday, August 19th 11:00am-12:30pm ET

Tuesday, September 2

nd

11:00am-12:30pm

Wednesday, September

3

rd

Draft recommendations to HITPCAdditional meetingRefine recommendationsWednesday, September 17th Draft recommendations to HITSCAdditional meetingRefine recommendationsTBD – Joint HITPC/HITSC meetingFinal recommendations4Slide6

Discussion Questions

7/1/2014

5Slide7

SummaryWe received detailed comments from 8 task force members – thank you!

Also included comments from Dr. Halamka’s blog on the topic, which some task force comments quotedThe JASON report had an inherent limitation – it was initiated 18 months ago, and is based on information gathered 12 months ago

This is a very dynamic policy and technology space and much has happened in the last 12 months that they did not have the benefit of including in their analysis7/1/20146Slide8

Summary (continued)

Seven general themes emergedIdentification of current gaps in interoperability: JASON report appropriately notes that interoperability is not yet achieved, and accurately identifies some of the key issues (lack of APIs, lack of EHR modularization, etc)

Interoperability as a “public” resource. The report advocates for a valuable interoperability goal – a layer of “public” open APIs to enable data-level extraction from disparate clinical systems to support higher level aggregationEnabling patient control of data sharing. The report highlights the importance and benefits of greater patient control, and the importance of making it easier for patient preferences to be captured and propagated across clinical settingsPrinciple goal of JASON architecture and recommendations. It is unclear whether the report is primarily trying to address the needs of research, clinical treatment, or patient access. It implicitly assumes that a single approach will meet all of these needs, which is a key assumption that warrants more discussion and explicationAccounting for current progress. The report does not take into account progress that has been made in standards, architectures, and production deployments that are consistent with their recommendationsSingle architecture for a complex and heterogeneous set of ecosystem. The report appears to focus on designing what would essentially be a single ideal system, without identifying the considerable business, governance, legal, and cultural hurdles to achieving a single system architectureSome key terms not fully defined. There are some key concepts and assumptions that appear confusing because they are not fully explained in the report (e.g., patient “ownership” of their records, implicit assumption that cryptography is not used in the industry, assumption that EHRs are purely clinical data repositories with none of the advanced analytics and decision support features that they believe that the system needs, etc)7/1/20147Slide9

Q1: The current EHR /HIE/MU environment may be misrepresented in the report.  What did the report get wrong?

Many members feel the JASON report doesn’t recognize the substantial standards progress that has been made in recent years through Meaningful Use and other developments.Direct + C-CDA represents more than electronic faxes of page formatted documents

View, download and transmit capabilities are enabling patient’s electronic access to their data Dated and limited discussion of interoperability efforts outside of MU (IHE standards, electronic prescribing, successful health information exchanges etc)Report is premised on the faulty presumption that patients own their record (vs business record, payment mechanism, joint stewardship). The report seems to promote a focus only on discrete data. Focus solely on discrete data could lose the important integration that a document approach enables. At times the report seems to equate EHR to being only a data repository not discussing the other complex functions EHRs perform such as orders management, clinical decision support etc. The model proposed in the report makes data much more easily accessible (subject to patient permissions), which morphs at least the “outer software layer” of medical records into arguably more of a public utility. Treating the outer layer of a medical record more like a public resource could help overcome some of the business hurdles limiting exchange. But this is a radical cultural shift – and one that doesn’t just get fixed by trying to mandate a technological approach.7/1/20148Slide10

Q2: What did JASON get right about the current environment – which aspects of their critique do you especially agree with

?Many Current EHRs are poorly modular and do not

encourage an ecosystem of innovation, either on provider side or patient side, not controlled by the EHR vendor.Many Current EHRs don’t readily support information exchange for secondary uses such as population health or research. Recognition of new and complex data types that will need to be incorporated into EHRs (genomics, etc.)Recognize the limits of a “document only” interchange model, and thus the need for “public” discrete data APIs to improve overall interoperability.Most EHR vendors have not documented and published complete, usable APIs. Few vendors host any kind of public sandbox environment where developers can test their apps and integrations, or demonstrate them to potential customers.7/1/20149Slide11

Q3: What problems do you believe the JASON report is trying to address? Are these the

right problems for a robust health data infrastructure?The Report is unclear on the business problem to be solved. Much of the report focuses on supporting research activities, but many of the proposed solutions focus on clinical use-cases. In some places the report contradicts itself (e.g. patient control of data sharing vs. research needs)

Cost and operational complexity of existing standards and protocols are prohibiting providers from universal access to patient data across settingsLimits of existing methods of sharing and protecting patient privacy in ad hoc, non-standardized waysMobile devices and other consumer preferred tools aren’t used to access data across settings due to the lack of sufficient, standards-based APIs and protocols to enable access to dataEHR systems are poorly modularized, impeding innovation of independent technology (mobile or otherwise) 7/1/201410Slide12

Q4: Numerous marketplace activities are already underway, list relevant

marketplace activities.(Has the market failed to address JASON?) (I)

Population management efforts: Health Catalyst, Explorys, Cerner, Optum, dbMotion, i2b2, McKesson, and a number of others supported by large and small health systems. SMART on FHIR, HL7 FHIR as open APIs, plus various proprietary API platforms. VDT; a variety of efforts to provide "Mint.com" -like capabilities to acquire C-CDAs from VDT portals with the patient's permission and credentials; BlueButton+;Efforts supported by: Epic and Mayo with Apple HealthKit, number of organizations and MS HealthVault CommonWell, eHealthExchange, CCC, Epic Care Everywhere. ISSUE: Scale/adoption, use of proprietary platforms.HealtheWays (eHealthExchange) and CommonWell are both addressing wide-scale "query" interoperability, though focused on CDA rather than native APIs.MU already requires encryption of data in motion. HIPAA requires compensating controls for data at rest, one of which is encryption of client devices.Granular consent, enforced with certificates - Data Segmentation for Privacy work, also organizations like PrivateAccess7/1/2014

11Slide13

Q4: Numerous marketplace activities are already underway, list relevant marketplace activities.(Has the market failed to address JASON?) (II

)Discrete Data sharingNumerous regional and state HIEs are successfully exchanging discrete data (Indianapolis, Oklahoma, MassHIE, etc.)

Over 80% of the transactions conducted on the Massachusetts statewide HIE (MassHIWay) are exchanging discrete data for performance measurement, care management, and registry functions. The HIway is actively building RESTful and SOAP approaches to support populating a master patient index, consent/privacy preferences, and real time query of healthcare data. The MassHIWay is very well aligned with the first phase architecture that Jason recommends as a good starting point to accommodate real-world constraintsExisting research networks are sharing discrete data, via open public tools like i2b2, TransSmart, etc. The I2B2 project, which has been further generalized by the ONC QueryHealth project supports clinical trials and clinical research while also protecting patient privacy.PCORnet project that will link many dozens of clinical centers and patient advocacy databases, using discrete data.The Meaningful Use Common Data set for Stage 2 already represents many data elements (atomic data) with associated metadataResearch work in progress and emerging products to leverage natural language processing, turning unstructured notes into discrete data.7/1/201412Slide14

Q5: List standardization efforts (e.g. HL7, IHE, S&I) underway

that encompass some of the JASON recommendations.Fast Healthcare Interoperability Resources. HL7 FHIR provides a framework for addressing key issues of data representation, API, and

provenance.CDA standardizes most of the commonly used ValueSetsS&I has several efforts focused on discrete data, most notably the DAF and SDC projectsOAUTH2 – as profiled for BlueButton+OpenID Connect. OIDC provides a standards-based authentication framework7/1/201413Slide15

Q6: JASON

addresses technology barriers. Provide non-technologic barriers.Payment reform

that rewards data sharingPolicies for data rightsConfusion about who “owns” the recordPatient Consent – lack of universal approach to cross-cut jurisdictionsdisclosuresPolicies for data access Policies for secondary data re-use (e.g., HIPAA vs Common Rule)Legal barriersState by state variation in privacy laws42 CFR 2 / SAMHSA rules that don’t translate from paper to dataTrust FrameworkGovernance – how we decide who trusts whom?Vendor/Provider “private” networksPatient Safety7/1/201414Slide16

Q7: How does the JASON vision align

with current MU3 trajectory (include any thoughts about the recent ONC 10 year vision.

 MU3Require Query as an EHR certification capability (and perhaps an MU incentive.) move beyond the current document-centric sharing model (XCA, XDS) towards a discrete data query modelIs there time to Include FHIR in MU3?Consider slowing down the MU3 trajectory to give time for key components of the discrete data architecture to mature.Include APIs that provide access to health data, and the authorization and privacy rules around them10 year PlanAdopt API-based model for use cases involving sharing of data with patientsLook for non-MU-based levers to encourage adoptionTreat the outer layer of a medical ecosystem as a public resource7/1/201415Slide17

Q8: What does the JASON "architecture" get right?

Need for open APIs

(Need to better define what “open API” means?)Open = standards-based, plus ??Increased role for patient control over data sharing preferenceskeeps track of patient's specific data sharing preferencesUse standardized privacy “bundles” to simplify patient effortIndirectly acknowledges the need for better patient identity management servicesManages user data sharing and authorization preferences.7/1/201416Slide18

Q9: What does the JASON "architecture" get wrong?

Defines architecture at the scale of a single system, not at the scale of an ecosystem or ultra-large-scale systemNo deployment or scaling considerations

Incomplete articulation of technical and policy challenges associated with:Key managementIndexing and searchDe-identification of dataFraud detectionQuery across heterogeneous data setsSemantics Limited references to “semantic translation” service grossly underestimates the complexity No discussion of content standards or data modelsOverly optimistic assumption that “metadata” can solve semantic interop issuesDistinctions between various types of APIs Confusing statements about cryptography – is there a new idea there?MU2 advancementsNarrowing in variability and increasing conformance constraints that is getting closer to plug-and-play7/1/201417Slide19

Q10: Are there learnings that the JASON report can leverage from PCORI?

PCORI’s investments in a learning healthcare system are fairly widespread and are addressing a similar problem but too early to gauge impact How could these efforts be coordinated?

PCORNet is defining a national federated data sharing architecture. Is this what JASON envisioned? If not, what are the differences?7/1/201418Slide20

Q11: Please list any aspects of the Report that you feel need to be clarified in order to make a more meaningful assessment of JASON.

Why did they start with the premise that the patient “owns”

the data? Provide clarity on the scope of the report. What is the architecture’s function? Is it a set of design patterns or is it a detailed set of APIs and protocol specifications? How responsibilities in the design of architecture and APIs would be split between ONC and other stakeholders (such as software vendors)?Why was the discussion of data formats limited to metadata? How would the JASON architecture anticipate that UI Apps would exist in a one-to-many relation with data storage systems? 7/1/201419Slide21

Q12: Please list your two or three top recommended actions for ONC to consider (in response to JASON)

Acknowledge the value of developing a set of APIs for discrete data access into EHRs. These APIs should be seen as a supplement to the current CDA-centric approach, and maybe could eventually replace the older document-only API (XDS,XCA)Explore how FHIR can be accelerated to address the need for a "public" EHR API, and should also support rapid work on defining FHIR Profiles that could reduce the "semantic" problems with interoperability (minimizing the need for "translation" services.)

Expand research on practical ways for patients to exert more control over secondary use - focus on ENABLING of data sharing rather than simply on restricting sharing.Clarify mission/business needs and drivers with respect to the JASON data sharing vision.Better alignment of work with HL7, NSTIC, DirectTrust and others with regard to enabling these new API standards and the necessary identity/trust ecosystemsPay attention to what is organically emerging in the market place that supports APIs (cloud based solutions, mHealth, TeleHealth etc)Address the need for national-scale patient identity management and consent preference services.Examine coordination with PCORI and PCORNetInvestigate other policy levers in addition to MU37/1/201420Slide22

Q13: Other

Recommend evaluating each section for pertinence and relevance in regards to new concepts needing consideration and clarification or to determine if the concepts are indeed already existing.If the concepts are new we should determine feasibility given our current infrastructure and make policy to support those in the future.

If the concepts are current industry standards, then we should share examples where similar processes are in play. Finally, we should determine if old concepts can be combined with new so that innovation can evolve.The members of the panel are respectable and credible experts and so, I believe, that to merely criticize (as opposed to critiquing) their remarks and concepts is beyond our purview. JASON report identified an ideal future architecture, and then worked backwards to figure out how to build a bridge to it.  Recommend determining functional requirements for that future state and figure out how to move forward from our current state to achieve those requirements.  This approach will cost less, will be more likely to be achievable, and will achieve equal benefits.  Need to analyze both approaches.7/1/201421Slide23

Next steps

Incorporate TF feedbackBegin draft outline of report (co-chairs and ONC staff)Are there areas/issues that we would like further clarification on?Listening session to gather market information

7/1/201422Slide24

Listening Session Planning

July 31, 20147/1/2014

23Slide25

Listening Session Perspectives to Include and Potential Candidates

ResearchWilliam Tierney, Regenstrief InstituteRomana

Hasnain-Wynia, PCORIRobert H. Shelton, Private AccessExchange Service ProvidersDavid Horrocks, CRISPDavid Kendrick, MyHealth Access NetworkTed Kramer, Rochester RHIO?, CommonWell Eric Heflin, Healtheway StandardsJonathan Coleman  , DS4P and Data Provenance FHIR DAF Ecosystem ParticipantsSamsungAppleGoogleHealth Record Bank or PHR perspective?App developers or another data user perspective?7/1/201424Slide26

General Panelist Questions (I)

Given currently implemented information technology (IT) architectures and enterprises, what challenges will the industry face with respect to transitioning to a JASON like architecture? What challenges will your organization face?Do you see an evolutionary path for the industry to move from currently implemented approaches to a JASON like architecture?

What policy and technology developments would be necessary to assure the privacy and security of information in a JASON like architecture?What existing efforts (standards, initiatives, pilots etc) in the marketplace are advancing a JASON like infrastructure?A key recommendation of the JASON Report is that EHR vendors should be required to develop and publish APIs for medical records data, searching and indexing, semantic harmonization and vocabulary translation, and user interface applications. What existing efforts are underway in health care that could inform the implementation of this recommendation?7/1/201425Slide27

General Panelist Questions (II)

What standards, implementation specifications, certification criteria, and certification processes for electronic health record (EHR) technology and other HIT would be required to implement the JASON reports’ recommendation that ONC require open published APIs through Stage 3 of Meaningful Use?

What processes and approaches would facilitate the rapid development and use of these standards, implementation specifications, certification criteria and certification processes?How might ONC and other Federal agencies best integrate the changes envisioned by the JASON report into their future work? What actions would you recommend ONC take to help the industry advance towards a JASON like architecture that supports interoperability for primary and secondary uses of health information? 7/1/201426Slide28

Research Panel QuestionsWhat challenges and successes have you had to date collecting and utilizing data from EHRs and other health IT systems? Would a JASON like architecture help address the challenges you encountered?

7/1/2014

27Slide29

Exchange Service Provider QuestionsWhat role do you see for exchange services providers in a JASON like architecture?

Today many efforts in the exchange ecosystem are focused on primary uses of health information, what challenges do you anticipate as the exchange ecosystem transitions to enable secondary uses as well?

7/1/201428Slide30

Standards Panel QuestionsPlease describe your standard initiative? How could it support the implementation of a JASON like infrastructure?

What if any modifications to your standard initiative would be required to better align your work with a JASON like infrastructure?

7/1/201429Slide31

Ecosystem Participants

What challenges and successes have you had to date receiving and utilizing data from EHRs and other health IT systems? Would a JASON like architecture help address the challenges you encountered?7/1/2014

30Slide32

Blank