Meeting Etiquette

1. Meeting Etiquette • Please announce your name each time prior to making comments or suggestions during the call • Remember: If you are not speaking keep your phone on mute • Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call • Hold = Elevator Music = very frustrated speakers and participants • This meeting, like all of our meetings, is being recorded • Another reason to keep your phone on mute when not speaking! • Feel free to use the “Chat” or “Q&A” feature for questions or comments, especially if you have a bad phone connection or background noise in your environment From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute  NOTE: This meeting is being recorded and will be posted on the Wiki page after the meeting

2. RHEx Pilots Lessons Learned WebEx #827 September 2012 wiki.siframework.org/RHEx Powering Secure, Web-Based Health Data Exchange

3. What is RESTfulHealth Exchange (RHEx)? • 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, removing barriers to broad electronic health data exchange • Offers a new approach to health data exchange • From moving documentsto linking to needed information • Sponsored by the Federal Health Architecture (FHA) program in FY12 • Continues tradition of Federal partner leadership • Investing in innovative solutions to health IT needs • Sharing results with entire health IT community • RHEx informs a path forward on RESTful health data exchange

4. Outline • Overview of RHEx Pilots • RHEx Pilot with TATRC • RHEx Pilot with HealthInfoNet • Lessons Learned • Conclusions

5. RHEx Pilots • Pilot with TATRC • Goal: Demonstrate simple, secure RESTful health data exchange in two phases • Use Case: Consults/Referral • Selected via discussions with Federal Partners • FHA Partner: Steve Steffensen and Ollie Gray, TATRC • Telemedicine & Advanced Technology Research Group (TATRC), U.S. Army Medical Research & Materiel Command (MRMC) • Pilot with HealthInfoNet • Goal: Investigate use of RESTful approach to populate Maine HIE (HealthInfoNet) Clinical Data Repository • Use Case: Populate single electronic health record for patients in medically underserved areas • FHA Partner: Todd Rogow, HealthInfoNet Develop proof of concept for a World Wide Web model for health data exchange 5

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

7. RHEx Pilots Lessons Learned TATRC Pilot

8. RHEx Pilot with TATRC • Worked with selected federal partners to identify critical capability gaps and select a prototype use case • Consult results are not consistently sent to PCP today, impacting healthcare for Veterans and Service Members • Demonstrate secure, RESTful health data exchange in support of Consult/Referral scenario • Phase 1: Secure exchange • Implement the secure exchange of health data with Direct secure messaging and OpenID authentication • Develop an OpenID Connect Identity Provider and a simple Web application that will act as the Relying Party • Phase 2: Content • Provide a richer set of services by utilizing emerging standards to support secure exchange of data in a granular fashion

9. Sample Consultation/Referral Process authorized consult request consult request Consulting Physician PCP Payer consult results Consult results are not consistently sent to PCP resulting in diminished patient care = Paper, Fax, or Email PCP = Primary Care Physician

10. Improving the Consultation/Referral Process URL-1 Message URL-1 Message URL-1 authorized consult request consult request Message Consulting Physician URL-2 PCP Payer consult results URL-2 RHEx approachallows PCP and Consulting Physician to access and retrieve current, relevant portions of each other’s records when they need them PCP = Primary Care Physician URL-1 = Consult Requests Details URL URL-2 = Consult Results Details URL

11. Phase 1 Focus Phase 2 Focus Links to patient vitals URL-3 PCP = Primary Care Physician

12. TATRC Pilot Architecture

13. RHEx Pilots Lessons Learned HEALTHINFONET Pilot

14. Motivation for Pilot with HealthInfoNet • Worked with HealthInfoNet to identify how RHEx technology might be applied • Today, patient health data from 26 hospitals and 240 ambulatory practices is moved in near real time to the Clinical Data Repository at HealthInfoNet • However, data is not sent today from smaller organizations who do not have the expertise to support a traditional HL7 interface connection to the HIE • By providing a simple, lightweight, secure method of transferring health data, small practices in underserved areas in Maine will be able to participate in the Maine HIE system • In addition, this work will contribute to the foundation for standard, machine processable formats from providers to Maine HIE for smaller healthcare organizations

15. Goal of RHEx Pilot with HealthInfoNet • Demonstrate secure, RESTful health data exchange from a Federally Qualified Health Center (FQHC) to Maine HIE using RHEx Islands Community Medical Services

16. Health data flow for connected providers in Maine 1. After patient visit is complete, physician updates patient’s record. 2. EHR system sends message to Maine HIE. 3. HL7 message is sent in near real time. A patient can refrain from opting out of the Maine HIE system. Single VPN Interface for healthcare organizations A patient can opt out of the Maine HIE system. X X Opted out X X X X X 1. Provider sends form to Maine HIE. 2. Flow of patient data from provider to HIE is blocked. 3. Maine HIE deletes the patient health data and marks patient as “opted out”.

17. Health data flow for Islands Community Medical Services in RHEx pilot 1. After patient visit is complete, physician updates patient’s record. 2. EHR system automatically generates a patient’s C32 and places it in a file directory for transport. 3. C32 document is encrypted and sent in near real time to Maine HIE using HTTPS POST over the Web. Islands Community Medical Services A patient can refrain from opting out of the Maine HIE system. Opting out process is same as for connected providers. A patient can opt out of the Maine HIE system. X X Opted out X X X X X 1. Provider sends form sent to Maine HIE. 2. Flow of patient data from provider to HIE is blocked. 3. Maine HIE deletes the patient health data and marks patient as “opted out”.

18. HealthInfoNet Pilot Architecture Maine HIE Islands Community Medical Services TLS DMZ EHR Environment OAuth2 Client Database OAuth2 Server OAuth2 EHR System C32 RHEx Client RHEx Endpoint C32 Processing Queue Shared File System EHR Trigger Translation C32s greenC32s Clinical Data Repository Integration Engine Translation to HL7 v2 HL7 v2 messages

19. RHEx Pilots Lessons Learned Lessons learned and conclusions

20. Lessons Learned, 1 of 2 • Collaboration with TATRC and HealthInfoNet has been outstanding • REST architectural style applies to multiple patterns of use • Person to person • Machine to machine • Can be leveraged to securely transport different types of documents/messages • Use of REST aids in troubleshooting integration problems • Easier to inspect network traffic • Most network transactions can be tested via web browser sessions • REST is not a magic bullet - integration issues still occur • e.g., Issues with clocks being out of sync

21. Lessons Learned, 2 of 2 • Use of OAuth and OpenID Connect work well as identity and authenticationsolutions • greenC32 format useful for standardizing input to HIE Clinical Data Repository, but standardization tool still needs to be configured to handle different vendor C32s • RHEx could be a solution for pushing large volumes of data in support of health information exchange • EHR automated trigger capability requires licensing by some EHR vendors (cost could be prohibitive for small independent providers)

22. Conclusions • 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 • Building foundation for secure access via mobile devices • Concepts were tested in pilots with TATRC and HealthInfoNet • Lessons learned can be applied in future initiatives • e.g., Automating Blue Button Initiative (ABBI) • RHEx is informing a path forward for the future of health data exchange

23. Discussion

24. RHEx Pilots Lessons Learned Backup Charts

25. OpenID Provider OpenID Provider TestData Sending A Referral PCP Direct Gateway Direct Gateway 2. Direct message with referral link is sent. 3. User receives message. 1. PCP creates referral. 4. User accesses link http://pcp.com/patient1/referral/1. PCP System Consult Dynamic Document Service AHLTA via PAWS 8. Referral viewed by user. RHEx Endpoint Authentication Service 6. User authenticates. OpenID OAuth 7. User redirected back to URL. 5. User redirected to OpenID Provider for authentication.

26. RHEx TATRC Pilot Phase 2 Model Vision PCP EHR Consulting Provider EHR greenC32 Patient Procedures Allergies Medications Lab Results Vital Signs

27. Approach to Content Organization, 1 of 2 Abstract Content Model Diagram Describes content available and resource URIs Supports coarse documents Supports hierarchy of patient data URIs can point to DICOM images or granular patient data, such as allergy or medication OData could be implemented as a Section Feed

28. Approach to Content Organization, 2 of 2 Course Grained Link Example https://example.org/patient1234/c32/c321.xml Granular Content Link Example https://example.org/patient1234/org.hl7.simplified/allergies/allergy2.xml

29. Technical data flow in RHEx pilot, 1 of 2 4. OAuth2 Server authenticates client and secure transport is established. 1. After patient visit is complete, physician updates patient’s record in EHR system. 5. C32 document is encrypted and moved to the RHEx endpoint over the Web using HTTPS POST. Maine HIE Islands Community Medical Services TLS DMZ EHR Environment OAuth2 Client Database OAuth2 Server OAuth2 EHR System C32 RHEx Client RHEx Endpoint C32 Processing Queue Shared File System EHR Trigger Translation C32s greenC32s HTTP POST http://healthinfonet.org/rhex/Islands Community Medical Services/1234/c32?token=e2FzZHNkOiAicG9k… Clinical Data Repository Integration Engine 2. EHR system trigger is used to move C32 document to shared file system. 3. RHEx Client detects the update and invokes OAuth2 workflow. Translation to HL7 v2 HL7 v2 messages

30. Technical data flow in RHEx pilot, 2 of 2 6. RHEx endpoint moves the C32 to a processing queue within the Maine HIE firewall, where it is decrypted. Islands Community Medical Services Maine HIE TLS DMZ EHR Environment Token Store OAuth2 Server OAuth2 EHR System RHEx Client RHEx Endpoint C32 Processing Queue Shared File System EHR Trigger Translation C32s greenC32s HTTP POST http://healthinfonet.org/rhex/Islands Community Medical Services/1234/c32?token=e2FzZHNkOiAicG9k… 7. C32 document is processed by the queue, translated into greenC32 and sent to Integration Engine. Clinical Data Repository Integration Engine 8. Orion sends HL7 message to Clinical Data Repository. Translation to HL7 v2 HL7 v2 messages