User Interfaces & Deployment Models Session 4

1. User Interfaces & Deployment ModelsSession 4 April 12, 2011

2. Agenda • User Interfaces: how do participants interact using Direct? • What are the options for Direct clients? • What are the pros and cons of each option? • Deployment Models: how can we securely enable Direct? • What are the options for security and routing? • What are the benefits and risks for each? • Panelists – live demos/real-world examples from: • Greg Chittim, Rhode Island Quality Institute Consultant; Director of Provider Services, Arcadia Solutions • Vincent P. Lewis, Principal Architect, MedAllies, Inc. • Holly Miller, MD, MBA, FHIMSS, Chief Medical Officer, MedAllies Inc. • Kim Long, Program Manager, MedPlus, a Quest Diagnostics Company • Q&A • Poll

3. User Interfaces –Overview of Options • Email Client • S/MIME Encryption is popularly supported • Downloadable Plug-in for Direct • Web Portal (or Webmail) • Web Portal can be set up by HISP or HIE • Webmail with plugin for Direct • EHR • Module that enables Direct messaging • Message generated and sent by EHR without intermediate steps @ EHR Individual communities are likely to include instances of all user interfaces, depending on provider preferences and choices in the local market

4. User Interfaces –Pros and Cons EHR @

5. Deployment Models –Overview of Options DestHISP • Encryption at Client • Client does encryption/decryption locally • Capabilities built into the EHR • Relies on HISP for routing • Encryption at HISPs • HISP provides encryption/decryption • HISP provides routing • Client interacts through EHR, Email, or Portal • Direct and XDR (optional) • Some HIEs use the IHE XDR profile for push workflows • This deployment model enables compatibility with the Direct Project Src Dest DestHISP SrcHISP Src Dest HISP Src Dest Individual communities likely to employ all deployment models, depending on provider preferences and local EHR choices. States need to enable HISPs regardless.

6. Deployment Models –Pros and Cons Threat Models for these deployments (including “Direct to/from XDR”) available at: http://wiki.directproject.org/Threat+Models

7. User Interfaces & Deployment Models Demos • Example 1: Rhode Island Quality Institute (RIQI) • User Interface(s): EHR, Web Portal, Email Client (optional) • Deployment Model(s): Encryption at HISPs • Actors: Provider (PCP and Specialist), State HIE (currentcare) • Example 2: MedAllies • User Interface: EHR • Deployment Model: Encryption at HISPs, Direct and XDR • Actors: Hospitals/IDNs, Primary Care Physicians, and Specialty Physicians • Example 3: MedPlus, a Quest Diagnostics Company • User Interface(s): REST Client, Email Client, Web Portal • Deployment Model(s): Encryption at HISPs • Actors: Provider, Patient

8. RIQI Direct Demo

9. What problems do the RIQI deployment models solve? The RIQI pilot enables an innovative solution to two difficult problems that will face healthcare providers and health information exchanges in the coming years: How do providers demonstrate Meaningful Use of health information exchange (hie)? How do you feasibly feed data from hundreds of heterogeneous practices into state Health Information Exchanges (HIE)? Direct Project The RIQI pilot is proving out solutions to both of these use cases

10. Using Direct to feed a Health Information Exchange The “Aha!” Moment: If it is inexpensive and easy to share data between two individual doctors using Direct, then why not use it to solve the bigger challenge by swapping out one of the doctors for the state’s HIE?

11. Clinical Process Demo http://www.youtube.com/watch?v=LSTkr45qefQ

12. Two Deployment Models Two distinct deployment models are being implemented: (A) direct provider-to-provider communication that meets Stage 1 Meaningful Use for health information exchange, and (B) transparent clinical updates from the EHR to the state HIE currentcare, both via Direct Health Information Service Provider (HISP) Model A: Manual, direct provider-to-provider message Sending Provider Receiving Provider Mail application (web, outlook, etc…) Mail application (web, outlook, etc…) Message with patient data attached (optional) Properly routed message with patient data attached (optional) Sending Provider Model B: Transparent updates of currentcare by provider EHRs Hosted Participation Gateway EHR clinical update made EHR Automatic Actions Automatic Actions Generate CCD (C32 v2.5) Open message Call Direct Web Service Parse CCD Message with CCD attached Match Patient Address message to currentcare De-duplicate Data Attach CCD Load Data currentcare Send message via Web Service execution

13. Detailed Solution Architecture

14. MedAllies Direct Pilot Technical Track

15. MedAllies use of the Reference Implementation • Currently MedAllies uses an unmodified implementation of the Java Reference Implementation. There is a C# version as well. http://wiki.directproject.org/Reference+Implementation+Workgroup • SMTP and XD* are both implemented and work in synergy (all three deployment models) • MedAllies has performed testing with several EHR and Hospital system vendors across three primary Meaningful Use use cases. • Modifications may be needed for Configuration Services only • Java Reference Implementation available in binary and in source code open source distributions. • Web services implemented in Tomcat, Mail service adapters implemented in Apache James.

16. Java Reference Implementation Architecture External Direct SMTP SERVICES Secure (TLS)Email Client “Real” SMTP Server SMIME TLS Gateway (Apache James) Configuration Web Service Apache Mailet API SQL Security Agent Configuration Web UI Apache Mailet API XD* Agent External XD* SERVICES XD* SOAP SERVICE External XD* SERVICES TLS TLS

17. MedAllies Direct Pilot Clinical Track Process: Use cases and Story Boards

18. Hospital Discharge Message (from the Hospital to the PCP )

19. Closed Loop Referral (Referral from PCP to Specialist & Back to PCP)

20. MedAllies Direct Pilot Hospital Discharge Building the Story Board

21. Creating the Message • Actor (Determined by the provider organization) • Functionality (Determined by the EHR System) • What is in the message • (Determined by: vendor e.g. free text in the Message; provider organization e.g. version and functionality implemented (CPOE), and ancillary systems integrated) • Screen shot(s) • Dependencies • Practice • e.g. CPOE implementation , ancillary integration • EHR Vendor • E.g. Upgrade with the desired functionality

22. Finalizing and Launching the Message • Actor (Determined by the provider organization) • Functionality (Determined by the EHR System) • e.g. EHR prompts with system events (such as d/c order) • Screen shot(s) • Dependencies • Practice • EHR Vendor

23. Finalizing/Signing the Message • Actor (Determined by the provider organization) • Functionality (Determined by the EHR System) • e.g. Automated inclusion of a standard data set (patient demographics, reconciled active medications, allergies, active problem list, etc.); Clinician selection of a pertinent variable data set (pertinent test and study results, procedures, etc.) • Screen shot(s) • Timeline for dependencies • Practice • EHR Vendor

24. Selecting the Intended Recipient • Actor (Determined by the provider organization) • Functionality (Determined by the EHR System) • e.g. Automated entry of PCP of record by EHR system • Screen shot(s) • Timeline for dependencies • Practice • EHR Vendor

25. MedAllies HISP Message Delivery • Automated secure routing of documents and authentication of users • MedAllies functionality

26. MedAllies Direct Demo Vignette 1: Hospital Discharge Vignette 2: Closed Loop Consultation

27. MedPlus Direct Demo

28. Architecture Overview

29. Demonstration Overview

30. Q&A

31. Poll