RESTful Health Exchange (RHEx)

Transcription

1 RESTful Health Exchange (RHEx) TAT R C, M I T R E 6 September 2013 For internal MITRE use 2013 The MITRE Corporation. All rights reserved.

2 Disclaimer 2 This project is being conducted by MITRE and TATRC in partnership and is made possible by a contract that was awarded and administered by the U.S. Army Medical Research & Materiel Command (USAMRMC) and the Telemedicine & Advanced Technology Research Center (TATRC), at Fort Detrick, MD under Contract Number: W15P7T-13-C-F600. The views, opinions and/or findings contained in this presentation are those of the author and do not necessarily reflect the views of the Department of Defense and should not be construed as an official DoD/Army position, policy or decision unless so designated by other documentation. No official endorsement should be made.

3 Outline 3 What is RESTful Health Exchange? Initial RHEx Pilots Pilot Outcomes Additional RHEx Pilots with TATRC NwHIN Power Team Endorsement Summary

4 4 What is RESTful Health Exchange? Open source, exploratory project to apply Web technologies to demonstrate a simple, secure, standards-based health information exchange Builds the foundation for patient access to data via the Web and mobile devices, facilitating broad electronic health data exchange Offers a new approach to health data exchange used in other industries: Replaces moving documents with linking to needed information Sponsored by the Federal Health Architecture (FHA) program in FY12 and TATRC in FY13 Helps address NwHIN Power Team recommendation to develop a specification for RESTful exchange of health data Informs a path forward for a RESTful health data exchange RHEx technology enables secure, Web-based health data exchange 2013 The MITRE Corporation. All rights reserved. For internal MITRE use

5 RHEx Technology Demystified 5 CCDA = Consolidated Clinical Document Architecture FHIR = Fast Healthcare Interoperability Resources TLS/SSL = Transport Layer Security/Secure Sockets Layer

6 Security Use Case Pattern Initial RHEx Pilots (FY12) 6 Differences in: Pilot with TATRC focuses on secure RESTful transport between people Pilot with HealthInfoNet focuses on secure RESTful transport between machines Consult/Referral Secure RESTful transport: OpenID Connect for distributed user authentication (person in the loop) Transport volumes of data to State HIE Clinical Data Repository Secure RESTful transport: OAuth2 for service to service authentication (machine to machine)

7 7 Pilot Outcomes Pilots successfully demonstrated that: Physicians can securely share health data over the Web High volumes of data can be moved over the Web securely in support of HIE patient data integration RHEx is being implemented across Maine to support small, independent providers and FQHCs in medically underserved areas RHEx for secure mobile access was demonstrated at 2013 HIMSS Interoperability Showcase Patients can be empowered by gaining access to their comprehensive health history in the Maine Health Information Exchange (HIE) using mobile devices powered by hreader New pilots with TATRC are underway in FY13 Pilot with VHA has been discussed RHEx technology to support secure sharing of information between VHA and third party providers in support of Veterans in rural Utah FQHC = Federally Qualified Health Center

8 Additional Pilots with TATRC Apply RHEx technology for 8 Sharing images between AHLTA and third party provider systems Providing patients access to their medical history in AHLTA using a mobile platform (hreader) Securely migrating health data from AHLTA to VistA to explore methods to reduce risk for a seamless electronic health record for Service Members and Veterans AHLTA = Armed Forces Health Longitudinal Technology Application

9 Current Process for Image Sharing with Third Party Providers 9 Patient physically carries images to third party provider MHS = Military Health System PCM = Primary Care Manager

10 RESTful Health Exchange (RHEx) 10 FY13 Focus: Sharing Medical Images MHS and third party providers can access relevant diagnostic images and associated records and metadata when needed securely over the Web MHS = Military Health System PCM = Primary Care Manager URL1 is a link to the radiology order URL2 is a link to the radiology results

11 NwHIN Power Team on RHEx 11 Commendable response to NwHIN Power Team s recommendation for a RESTful complement to Direct and Exchange Responds to the industry need for a simple means of transmitting large healthcare data objects that cannot be accommodated by Direct Key part of a safe and appropriate set of standards to use as building blocks for more complicated healthcare applications From NwHIN Power Team Recommendations, June 19, 2013, August 6, Recommended that the Office of the National Coordinator for Health IT (ONC) support and encourage the development and piloting of RHEx technology

12 12 Summary RHEx project has explored secure, Web-based health data exchange, building the foundation for future advances in health care Allows providers and patients to exchange health data securely over the World Wide Web Builds foundation for secure access via mobile devices Pilots with TATRC and HealthInfoNet suggest that RHEx technology is a feasible solution for lightweight, secure exchange of health data over the Web Work continues to pilot RHEx technology in new ways RHEx is informing a path forward for the future of health data exchange

13 13 Discussion The views, opinions and/or findings contained in this presentation are those of the author and do not necessarily reflect the views of the Department of Defense and should not be construed as an official DoD/Army position, policy or decision unless so designated by other documentation. No official endorsement should be made.

14 Possible Pilot with VHA in Utah 14 The views, opinions and/or findings contained in this presentation are those of the author and do not necessarily reflect the views of the Department of Defense and should not be construed as an official DoD/Army position, policy or decision unless so designated by other documentation. No official endorsement should be made.

15 FY13 Technical Architecture 15 The views, opinions and/or findings contained in this presentation are those of the author and do not necessarily reflect the views of the Department of Defense and should not be construed as an official DoD/Army position, policy or decision unless so designated by other documentation. No official endorsement should be made.

16 Comparison: Focus 16 Demonstrate feasibility of RESTful Health Exchange. Build open source prototype that could be fielded to support real capability gaps. Define a set of resources to represent health and healthcare administration related information and the protocols that support them. Enable patients to have access to their own data in human-readable and machinereadable formats and share data where they choose. Uses FHIR for data layer. The views, opinions and/or findings contained in this presentation are those of the author and do not necessarily reflect the views of the Department of Defense and should not be construed as an official DoD/Army position, policy or decision unless so designated by other documentation. No official endorsement should be made.

17 Comparison: Network Style 17 Known providers and endpoints, unknown applications, registration and onboarding is out of band. No discovery or dynamic registration. Undefined / out of scope. Highly dynamic and distributed. Trust networks tied to Registry components, providers and clients can be outside of any registry and still may function. The views, opinions and/or findings contained in this presentation are those of the author and do not necessarily reflect the views of the Department of Defense and should not be construed as an official DoD/Army position, policy or decision unless so designated by other documentation. No official endorsement should be made.

18 18 Comparison: Security Transport: HTTPS Authentication: OpenID Connect Authorization: OAuth 2 Defines profiles for protocol use. Transport: HTTPS Authentication: Undefined (local to provider) Authorization: Suggested OAuth 2 Defines security labels for data. Transport: HTTPS Authentication: Undefined (local to provider) Authorization: OAuth 2 Defines profiles and policies for protocol use. The views, opinions and/or findings contained in this presentation are those of the author and do not necessarily reflect the views of the Department of Defense and should not be construed as an official DoD/Army position, policy or decision unless so designated by other documentation. No official endorsement should be made.

19 Comparison: Technology 19 = + + = + = + The views, opinions and/or findings contained in this presentation are those of the author and do not necessarily reflect the views of the Department of Defense and should not be construed as an official DoD/Army position, policy or decision unless so designated by other documentation. No official endorsement should be made.