Session Notes 4

Session 4: The User Experience Direct Deployment Models

4/12/11: 1:30 --2:45PM

Session Objectives

• Review and discuss the benefits and challenges associated with different deployment models

Presenters/Panelists

• Douglas S. Arnold, Executive Director, Medical Professional Services, Inc. (MPS)
• Greg Chittim, Director of Provider Services, Arcadia Solutions
• Holly Miller, MD, MBA, FHIMSS, Chief Medical Officer, MedAllies Inc.
• Kim Long, Program Manager, MedPlus, a Quest Diagnostics Company

Introdution, Jitin Asnaani, ONC

• There are several options for Direct user interfaces:
  • Email Client
  • Web Portal
  • EHR

• This panel will discuss the choices that they made in selecting a particular user interface.
• User Interface pros and cons:
  • All three of the options allow a provider to meet meaningful use requirements. Email and web portal are both accessible for physicians who don’t have EHRs. This won’t help with meaningful use, as a provider needs an EHR to be considered, but it does provide that initial experience with online exchange
  • All three user interfaces would have familiar formats for users, but only an EHR possibly allows for a uniform interface for clinical data entry, storage, and exchange
  • Seamless integration with clinical data record is difficult with all except EHR, but a controlled security environment should be an option with all three

• There are three deployment models:
  • Encryption at the client site. This means that encryption would be within the client’s system and would need to be built into it.
  • Encryption at the HISPs. A provider sends an unencrypted message and its HISP encrypts it and then forwards it on to the correct destination HISP, who sends it to the correct sender.
  • *Direct and XDR. *XDR has been around for awhile and several vendors have already implemented systems using it. This allows states to leverage this existing system.

• It should be noted that it probably won’t be possible for a state to only select one deployment model; states may select more than one depending on provider preferences and requirements. A HISP will be necessary for routing reasons. The state, however, can play multiple roles, such as by creating lists of recommended vendors
• Deployment models - pros and cons
  • Encryption at client vs. encryption at the HISP. With the former, you will probably be dealing with an off-the shelf product. A provider would also need to be able to handle certificate systems as well. Then, Direct would act almost as a separate Microsoft Exchange. It should be fairly seamless.
  • If the HISP is managing the encryption, there are implications for privacy and security. In the former, the HISP will not have access to the providers’ PHI. With the latter, it will. There are benefits and disadvantages to both. From the provider’s perspective, having a HISP handle all of the certificate issues may be a huge benefit_._

Presentation 1, Douglas Arnold, MPS

• RIQI has all three user interfaces and decided to encrypt at the HISP-level. Important actors in the demo include providers (PCP’s and Specialist), and the State HIE (currentcare).
• The purpose of this demo is to focus on the clinical workflow and process (rather than the technical details). These is what was focused on in the pilots. They ended up using Direct in a way not quite intended, but solved several problems of Rhode Island’s issues.
• Rhode Island is trying to address two issues:
  • How do we help providers meet meaningful use (MU)?
  • How do you feasibly feed data from so many different entities into a single state HIE?

• For Use Case A, the vanilla point-to-point exchange, RIQI is working as the convener, but letting the market drive the state health exchange. RIQI has a robust vendor market and released a simple RFP to help pre-qualify HISPs to meet these needs. This is going to be up and running in about a month. By the time RI rolls out a second solution, many of the providers that they will be working with will already have Direct accounts.
• RI had an “aha” moment, Direct works by connecting two different providers. Rhode Island wondered why they couldn’t treat each (or one) point as an entire practice or the State’s HIE?
• RI has already done this with one EHR platform that was a part of its pilot. State will next move onto the eight EHR platforms in its Beacon communities.
• It’s important that what state is asking of vendors is not unique to Rhode Island, these capabilities would work in any state.
• This is an elegant solution because of its easy-leveragability. It is not dependent on a specific type of EHR, has a standard data format and national standards. It only requires the Internet to connect and providers will already have Direct accounts for provider-provider communications.
• Runs Demo - Please See Session Slides (Slide 11) to see demo (YouTube Video link)
• This demo shows how providers could interact with the EHR and how it helps patient care
• Two deployment models (both using Direct):
  • Model A: Manual, direct provider-provider.... fairly straightforward.
  • Model B, there are transplant updates of currentcare by provider EHRs. It is necessary to implement clinical triggers that can generate CCDs and attach that CCD to Direct message an send to currentcare.
  • In addition to the SMTP and XDR, there’s a secure website that does the true directing portion of exchange. It’s very simply, like email and the HISP handles the other packaging or security issues. The message travels via the HISP, and it’s monitored by an objective third party.
  • There is a very strict opt-in consent law in Rhode Island. Nothing can be done unless patient consent is confirmed.
  • On the receiver-end, the system can find the patient information, check if the patient belongs to currentcare and, if so, direct the message on to currentcare system.
  • The CCD is a fully longitudinal record and thus, 99.9% of that CCD is already in currentcare. A fairly sophisticated system is needed to find the .1% of new information.
  • Three requirements for EHRs so that RIQI gets PHI from these systems:
    • Have to generate a CCD
    • Have to have clinical triggers
    • Have to be able to send a Direct message
    • Don’t need to worry about consent
    • Don’t need to worry about custom protocols

• Working with Beacon members as well as the provider community. This is not just being done for Rhode Island, this is very applicable for other states and other networks.

Presentation 2, Greg Chittin, Arcadia Solutions

• MedAllies utilizes an EHR user interface and uses encryption at HISPs and Direct and XDR. Major player in the Demo are hospitals/IDNs, PCPs, and specialty physicians
• MedAllies is implementing an unmodified implementation of the Java Reference Implementation. SMTP and XD* also play a role and all three deployment models are able to work cooperatively.
• It’s important that you can mix and match these deployment models. MedAllies has tested multiple scenarios, not only NY, but at HIMSS as well.
• There may be modifications necessary for certain configuration services
• MedAllies explains how the Java Reference Implementation Architecture works.
• XD* = lightweight protocol
• The HISP can talk the EHRs through the reference implementations. You can also have an XD EHR talk to a HISP. This will give you more flexibility. This allows for the Step Up format ad move it into an XDR format. The other model improves taking a pure CCD attachment, add meta data, and create a setup transactions.
  • This mix and matching is key and makes an EHR more than an email on steroids. Most of the transactions will be XD* to XD*.

Presentation 3, Holly Miller, MedAllies

• MedAllies Clinical Track
  • Background:
  • MedAllies has an active demo in the Hudson River Valley. In their deployment they had two tracks: technical and clinical.
    • There was coordination between the two tracks.

• MedAllies began with the concept that ONC has “aligned the stars”. 60% of clinicians in the Hudson River Valley have adopted EHRs. MedAllies thus wanted to provide support for EHRs.
• They received two messages from providers: discharge messages, which focus on certain, relevant, and specific results (e.g., medication lists, etc.).
• The other was a closed loop referral system. The specialist will see the patient and send the information back to the provider. There are, again, certain key pieces of information that need to be prioritized given the specialist. They worked to focus the use cases on what providers wanted.
• MedAllies worked with several vendors, including Allscripts, Siemens , Epic, eClinicalWorks, Greenway, etc.
• The goal is to support transitions of care. We discussed some common issues with clinicians and these groups became very collegial and are still collaborating.
• Use case: Hospital Discharge Message: Hospital Discharge Message from the hospital to the PCP (Primary Care Provider)
  • Setting of the Hospital and includes standard data elements and Discharge context relevant data. This information would then go through the HISP to the PCP. The PCP receives this message and reconciles the new information. All of these messages would be stored in the EHR. This would allow the key information to flow to the PCP before the patient is discharged. This greatly adds to efficiency of care and supports a PCMH model. This enabled a lot of clinical workflow.
  • Use case #2: Closed Loop Referral (from PCP to specialist and back)
    • The other user story is a closed loop referral. From the PCP, to the Specialist and back to the PCP.
    • We started at this high level and then h the vendors show storyboards for addressing these use cases. This created a healthy environment of improving systems for Direct. At HIMSS, several of their vendors has enabled new services in their system that allow interoperability without duplicate information. Key is that, because it is a physician-to-physician message (or provider-to-provider), no consent it necessary as it is a part of clinical care.

• • Building the storyboard:
    • In creating the message, many elements are dependent on provider
    • Depending on what the system’s capabilities were, they posted them on the slides
    • In one of the clinical practices, they had not yet adopted CPOE and the timeline made sure to account for all of these variables
    • EHRs had different functionalities and could have certain automated features. This was the same with receipt of information

• MedAllies runs their demo dealing with an emergency department discharge use case with a follow-up appointment with her PCP.
• Another use case demo on secure transport from system to system (PCP to Specialist to PCP).

Presentation 4, Kim Long, MedPlus

• MedPlus Direct Demo. The HISP is the big blue box the HISP’s responsibility includes certificates, security, and other core components.
• Domain Name Service (DNS) - used to validate other certificates
• Allow Hypertext Transfer Protocol (HTTP) / Representational State Transfer (REST) interfaces to connect. This also allows for any EHR to connect to this HISP for Direct messages.
• For HISP core components, the security components are the only ones taken directly from the reference implementation. For the rest, MedPlus used proprietary information and coding.
• There are two different direct addresses supported by MedPlus.
  • direct.medplus.com - For EMR users
  • direct.360.com - for Care360 users

• Can also support and host any entities’ domains. This is called a multi-tenet HISP.
• The live demo that MedPlus will show is logging in to the Web Portal and sending information via an EHR, then how this would work if the recipient did not have an EHR (involves Mozilla Thunderbird), finally, showing how this information can reach the patient
• MedPlus goes through the same demo used at HIMSS, including consumer participation
• Currently have 170,000 users on Care360