310 likes | 422 Views
User Interfaces & Deployment Models Session 4. April 12, 2011. 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?
E N D
User Interfaces & Deployment ModelsSession 4 April 12, 2011
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
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
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.
Deployment Models –Pros and Cons Threat Models for these deployments (including “Direct to/from XDR”) available at: http://wiki.directproject.org/Threat+Models
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
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
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?
Clinical Process Demo http://www.youtube.com/watch?v=LSTkr45qefQ
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
MedAllies Direct Pilot Technical Track
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.
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
MedAllies Direct Pilot Clinical Track Process: Use cases and Story Boards
Closed Loop Referral (Referral from PCP to Specialist & Back to PCP)
MedAllies Direct Pilot Hospital Discharge Building the Story Board
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
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
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
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
MedAllies HISP Message Delivery • Automated secure routing of documents and authentication of users • MedAllies functionality
MedAllies Direct Demo Vignette 1: Hospital Discharge Vignette 2: Closed Loop Consultation