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?
– 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
2
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
Individual communities are likely to include instances of all user interfaces,
depending on provider preferences and choices in the local market
3
User Interfaces –
Pros and Cons
@
Email Client
Web Portal
EHR
Can 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
Possible
Yes
Yes
Controlled Security
Environment
4
Deployment Models –
Overview of Options
Dest
HISP
Src
Src
HISP
Src
Src
HISP
Dest
HISP
•
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
Dest
Dest
Dest
Individual communities likely to employ all deployment models, depending on provider
preferences and local EHR choices. States need to enable HISPs regardless.
5
Deployment Models –
Pros and Cons
Encryption at Client
Pros
Cons
•
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
•
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
Encryption at HISPs
•
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
•
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
6
impersonate the user
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
7
RIQI Direct Demo
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
9
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
•
•
•
Why it’s such an
elegant solution
•
•
•
•
•
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
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
10
Clinical Process Demo
http://www.youtube.com/watch?v=LSTkr
45qefQ
11
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
Model A:
Manual, direct
provider-to-provider
message
Sending Provider
Model B:
Transparent updates
of currentcare by
provider EHRs
Sending Provider
Mail application
(web, outlook,
etc…)
Receiving Provider
Message with
patient data
attached (optional)
EHR clinical
update made
Properly routed message
with patient data
attached (optional)
Health
Information
Service
Provider (HISP)
EHR
Mail application
(web, outlook,
etc…)
Hosted Participation Gateway
Automatic Actions
Automatic Actions
Generate CCD (C32 v2.5)
Open message
Parse CCD
Call Direct Web Service
Address message to
currentcare
Attach CCD
Send message via Web
Service execution
Message with
CCD attached
Match Patient
De-duplicate Data
Load Data
currentcare
12
Detailed Solution Architecture
13
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.
15
Java Reference Implementation
Architecture
External Direct SMTP
SERVICES
SMIME
“Real” SMTP
Server
TLS
Secure (TLS) Email
Client
Gateway
(Apache James)
Configuration
Web Service
Apache Mailet API
SQL
Security Agent
Configuration Web UI
Apache Mailet API
XD* Agent
External XD*
SERVICES
TLS
XD* SOAP SERVICE
TLS
External XD*
SERVICES
16
MedAllies Direct Pilot
Clinical Track
Process: Use cases and Story Boards
Hospital Discharge Message
(from the Hospital to the PCP )
1.3
1.1
Setting: 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
HISP
Content Creator:
Discharge MD
1.2
(HISP transaction)
Hospital EHR sends
discharge CCD package via
XDR to MedAllies HISP
MedAllies HISP routes
CCD Package to
Ambulatory EHR
Setting: PCP
Activity:
- Receive CCD
- Match/reconcile patient
with existing patient, or
create/register new
patient
Schedule appointment as
needed
- Store CCD in patient
record
- Message to PCP re: New
Patient Document
Content Consumer: PCP,
Scheduler, Nurse Care
Manager (if applicable to
the practice, e.g. PCMH)
18
Closed Loop Referral
(Referral from PCP to Specialist & Back to PCP)
1.1
Setting: PCP
Activity:
- Create CCD
with: both
minimal
standard data
set and referral
context
relevant data
set (including
reason for
referral)
- Select
Intended
Recipient
- Send CCD via
XDR to
MedAllies HISP
Content
Creator: PCP
1.3
1.2
(HISP
transaction)
PCP EHR sends
referral CCD
via XDR to
MedAllies HISP
Setting:
Specialist
Activity:
- Receive CCD
and
match/register
new patient &
schedule
appointment
as needed
- Store CCD in
patient record
- Message to
Specialist re:
New
Patient/Docum
ents
Content
Consumer:
Specialist &
Scheduler
1.4
1.5
Setting:
Specialist
(HISP
transaction)
Activity:
Specialist EHR
sends consult
note CCD via
XDR to
MedAllies HISP
- After patient
visit, construct
patient consult
note CCD for
PCP with:
both minimal
standard data
set and
consultation
context
relevant data
set (including
consultation
note)
Content
Creator: PCP or
tasked staff
1.6
Setting: PCP
Activity:
- Receive CCD
from specialist
and match
with patient
record.
- Store CCD in
patient record
- Notify PCP
Specialist CCD
consult note
received
Content
Consumer:
Front Desk
Staff, PCP,
Nurse Care
Manager (if
applicable to
the practice,
e.g. PCMH)
19
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
21
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
22
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
23
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
24
MedAllies HISP Message
Delivery
• Automated secure routing of documents and
authentication of users
• MedAllies functionality
25
MedAllies Direct Demo
Vignette 1: Hospital Discharge
Vignette 2: Closed Loop Consultation
MedPlus Direct Demo
Architecture Overview
28
Demonstration Overview
29
Q&A
Poll
31