User Interfaces & Deployment Models Session 4

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 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

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 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

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 Demo

Vignette 1: Hospital Discharge

Vignette 2: Closed Loop Consultation

MedPlus Direct Demo

28

Architecture Overview

Demonstration Overview

29

Q&A

31

Poll