View
40
Download
1
Category
Preview:
DESCRIPTION
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? - PowerPoint PPT Presentation
Citation preview
User Interfaces & Deployment Models
Session 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 stepsEHR
@
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
Email Client Web Portal EHRCan enable requirements of MU Stage 1? Yes Yes Yes
Accessible to physicians without upgraded EHRs? Yes Yes No
Familiar User Interface? Yes Possible Yes
Uniform interface for clinical data entry, storage, and exchange?
No No Yes
Seamless integration with clinical data record? No No Possible
Controlled Security Environment Possible Yes Yes
@
Deployment Models –Overview of Options
5
• 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 DestHISP
Dest
Src DestHISP
DestSrcHISP
HISP DestSrc
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
Encryption at Client Encryption at HISPs
Pros • Can utilize 100% off-the-shelf e-mail clients available today (20+ email clients support S/MIME today)
• Offers TLS as a point-to-point additional protection - also commonly available today
• No PHI is exposed to any HISP• ’Sent' mail folder can be examined for
inappropriate exposure of PHI
• Client does not need to perform S/MIME functions, so any e-mail client can be used
• The HISP has access to all the content so could provide value added services, such as informing of Account Disclosures
• The management of certificates and private keys is offloaded to the HISP, minimizing the burden on the client's implementation
Cons • Configuration requires that the client can handle S/MIME and address book to store certificates; e.g., EHR or Email client with S/MIME/certificates enabled
• Harder to automate inside an EHR/PHR workflow, though can be mitigated
• TLS is mandated between Client and HISP to assure confidentiality of information transmitted
• HISP has full access to PHI – requires policy consideration; e.g., BAA with provider or HIE
• HISP has full access to Private key, thus can impersonate the user
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
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 you feasibly feed data from hundreds of
heterogeneous practices into state Health Information
Exchanges (HIE)?
Direct ProjectThe RIQI pilot is proving out solutions to
both of these use cases
How do providers demonstrate
Meaningful Use of health information
exchange (hie)?
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?
How it works • Use Direct Project messages to securely transport health information from EHRs to the HIE
• Package information in standard Continuity of Care Documents (CCDs) that capture all aspects of a patient’s health record
• Work with EHR platform vendors to implement very simple updates that work in the background so that doctors can focus on patient care
Why it’s such an elegant solution
• Agnostic of what EHR a provider has, or what customizations exist• Standard data format – no matter what the workflow, the CCD will be the same• Providers will already have Direct accounts for doctor to doctor communication• No special or custom connections required – just the internet• Utilizes the emerging national standards – nothing “special” for Rhode Island
11
Clinical Process Demo
http://www.youtube.com/watch?v=LSTkr45qefQ
12
Two Deployment ModelsTwo 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
Sending Provider
Receiving ProviderMail application(web, outlook, etc…)
Sending Provider
Health Information
Service Provider (HISP)
Message with patient data attached (optional)
Mail application(web, outlook, etc…) Properly routed message
with patient data attached (optional)
Model A:Manual, direct provider-to-provider message
Model B:Transparent updates of currentcare by provider EHRs
Message with CCD attached
Hosted Participation Gateway
Open message
Parse CCD
Match Patient
De-duplicate Data
currentcare
Load Data
Generate CCD (C32 v2.5)
Call Direct Web Service
Address message to currentcare
Attach CCD
Send message via Web Service execution
EHR clinical update made
Automatic Actions Automatic Actions
EHR
13
Detailed Solution Architecture
MedAllies Direct PilotTechnical 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.
15
16
ConfigurationWeb Service
Gateway (Apache James)
Apache Mailet API
Security Agent
SQL
Configuration Web UI
“Real” SMTPServer
External XD* SERVICESXD* SOAP SERVICE
Apache Mailet API
XD* Agent
External XD* SERVICES
External Direct SMTP SERVICES
Secure (TLS) Email Client
SMIME TLS
TLS TLS
Java Reference Implementation Architecture
MedAllies Direct PilotClinical Track
Process: Use cases and Story Boards
18
Hospital Discharge Message (from the Hospital to the PCP )
1.1Setting: Hospital
Activity: - Create Message
with both minimal standard
data set and Discharge
context relevant data set
(including discharge note
and instructions) Scope – Current Hospitalization
- Select Intended Recipient (PCP)
and Send CCD via XDR to MedAllies
HISPContent Creator:
Discharge MD
19
Closed Loop Referral (Referral from PCP to Specialist & Back to PCP)
1.2 (HISP
transaction)PCP EHR
sends referral CCD via XDR to MedAllies HISP
1.3Setting: Speciali
stActivity
: -
Receive CCD and
match/register
new patient
& schedul
e appointment as needed- Store CCD in patient record
- Messag
e to Speciali
st re: New
Patient/Docum
entsContent Consum
er: Speciali
st & Schedul
er
MedAllies Direct PilotHospital 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
MedAllies Direct DemoVignette 1: Hospital Discharge
Vignette 2: Closed Loop Consultation
MedPlus Direct Demo
28
Architecture Overview
Demonstration Overview
29
Q&A
31
Poll
Recommended