1. Understanding and Leveraging MU2 Optional Transports Paul M. Tuten, PhD Senior Consultant, ONC Leader, Implementation Geographies Workgroup, Direct Project

2. Meaningful Use & Certification Relationship “Transitions of Care” (ToC) Objective For Meaningful Use Stage 2, the ToC objective includes 3 measures: Measure #1: requires that a provider send a summary care record for more than 50% of transitions of care and referrals. Measure #2 requires that a provider electronically transmit a summary care record for more than 10% of transitions of care and referrals using CEHRT or eHealth Exchange participant Measure #3 requires at least one summary care record electronically transmitted to recipient with different EHR vendor or to CMS test EHR Meaningful Use2014 Edition Certification Two 2014 Edition EHR certification criteria 170.314(b)(1) : Transitions of care— receive, display, and incorporate transition of care/referral summaries. 170.314(b)(2) : Transitions of care— create and transmit transition of care/referral summaries.

3. Feature Focus: ToC Measure #2 & 170.314(b)(2) The eligible provider, eligible hospital or CAH that transitions or refers their patient to another setting of care or provider of care provides a summary of care record for more than 10% of such transitions and referrals either: (a) electronically transmitted using CEHRT to a recipient; or (b) where the recipient receives the summary of care record via exchange facilitated by an organization that is a NwHIN Exchange participant or in a manner that is consistent with the governance mechanism ONC establishes for the nationwide health information network. ToC Measure #2170.314(b)(2) Transitions of care—create and transmit transition of care/referral summaries. (i) Enable a user to electronically create a transition of care/referral summary formatted according to the Consolidated CDA with, at a minimum, the data specified by CMS for meaningful use. (ii) Enable a user to electronically transmit CCDA in accordance with: “Direct” (required) “Direct” + XDR/XDM (optional, not alternative) SOAP + XDR/XDM (optional, not alternative) eHealth

4. Certification Options & Meaningful Use Approaches

5. Transmit Summary Care Record Using CEHRT “Direct” (Required) Provider A Provider B EHR Affiliated HISPProvider A HISP Provider A Direct (SMTP + S/MIME) Provider B Direct (SMTP + S/MIME) Any Edge Protocol Represents Certified EHR Technology or “CEHRT” Direct (SMTP + S/MIME) Any Edge Protocol Example 1 Example 2 Example 3

6. As an EHR vendor, you could… 6 1 2 3 Be a HISP Partner with a HISP Enable clients to be a “self-service HISP” Regardless of the option(s) you select, you’ll want to ensure that you, your partner(s), and/or your client(s) are capable of doing what’s required to successfully engage in Direct exchange

7. Security/Trust Agents (STAs) are responsible for securing, routing, and processing Direct Messages – STA may be a system under the direct control of an exchange participant – STA may be a service offered by an intermediary, known as a Health Information Service Provider (HISP), acting on behalf of an exchange participant In order to use the STA effectively, the exchange participant or HISP must perform a number of services required for the exchange of health information as defined by the Direct Project – Provide Direct Addresses – Publish and find digital certificates – Facilitate management of trusted exchange relationships – Secure health information in transit using S/MIME and certificates – Route and transport Direct Messages using Direct Addresses and SMTP – Depending on implementation model (e.g., web portal), possibly store Direct Messages STAs and HISPs 7

8. What it means to be a HISP… HISP = Health Information Service Provider Ongoing responsibilities often include: – Developing, maintaining, and enforcing participation agreements – Providing online and phone support for onboarding, connectivity issues and outages, and other service needs – Assigning and managing (directly or through delegation) Direct domains and addresses – Provisioning, managing, and publishing certificates using DNS or LDAP – Maintaining trust relationships, possibly entailing joining a trust community and fulfilling its accreditation and other membership requirements – Ensuring Direct Security/Trust Agent (STA), certificate publication, and other customer- supporting services are available and perform to the needs of customers 8

9. Transmit Summary Care Record Using CEHRT “Direct” + XDR/XDM (Option) Provider A Provider B EHR Affiliated HISPProvider A HISP Provider A Direct (SMTP + S/MIME) + XDR/XDM Provider B Direct (SMTP + S/MIME) + XDR/XDM Any Edge Protocol Represents Certified EHR Technology or “CEHRT” Direct (SMTP + S/MIME) + XDR/XDM Any Edge Protocol Example 1 Example 2 Example 3

10. Transmit Summary Care Record Using CEHRT “Direct” + XDR/XDM (Option) Provider A Provider B Direct (SMTP + S/MIME) + XDR/XDM Represents Certified EHR Technology or “CEHRT” To enhance real world interoperability, all vendors should anticipate receiving Direct messages conforming to the optional XDR/XDM specification. What if Provider B’s EHR technology is only certified to receive via the minimum required “Direct” transport standard? X

11. 1. EHR generates CCDA 2. EHR (certified to include optional SOAP + XDR/XDM transport) sends message to Provider B using SOAP + XDR/XDM Transmit Summary Care Record Using CEHRT SOAP +XDR/XDM (Option) Provider A Provider B SOAP + XDR/XDM Example 1 Example 2 1. EHR generates CCDA 2.EHR (certified to include optional SOAP + XDR/XDM transport) sends message to Provider B (via HISP) using SOAP + XDR/XDM 3.HISP/HIE repackages content and sends to Provider B HISP/HIE Provider A Provider B SOAP + XDR/XDM Represents Certified EHR Technology or “CEHRT” Examples 2 demonstrates how CEHRT may be used to integrate with other HISPs, eHealth Exchange participants, or HIEs offering query-based exchange.

12. Transmit Summary Care Record Using CEHRT SOAP + XDR/XDM (Option) CEHRT Example 2 1. EHR generates CCDA 2.EHR (certified to include optional SOAP + XDR/XDM transport) sends message to Provider B (via HISP) using SOAP + XD 3.HISP/HIE repackages content and sends to Provider B HISP/HIE Provider A Provider B SOAP + XDR/XDM The fact there’s a “HISP/HIE in the middle” is irrelevant with respect to Provider A meeting MU requirements. Provider A’s use of their CEHRT’s optional transport capability enables Provider A to include this transmission in Measure #2’s numerator. Under this approach, HISPs/HIE entities do not have to be certified. This allows any EHR vendor supporting the SOAP + XDR/XDM option to interoperate with any Direct HISP that also offers SOAP + XDR/XDM support. Let’s take a closer look at Example #2…

13. Transmit Summary Care Record Using CEHRT SOAP + XDR/XDM (Option) Example 2 1. EHR generates CCDA 2.EHR (certified to include optional SOAP + XDR/XDM transport) sends message to Provider B (via HISP) using SOAP + XD 3.HISP/HIE repackages content and sends to Provider B HISP/HIEProvider A Provider B SOAP + XDR/XDM If EHR vendors implement the optional SOAP + XDR/XDM support and then partner with a HISP (i.e., use the HISP as “relied upon software” for certification), they can also fulfill their Direct requirement under the “Direct” Example #3 with minimal (or no) additional development/technical work on their part. In addition, by certifying to the SOAP + XDR/XDM, the EHR vendor preserves the option to work with other HISPs or allow their clients to do so. One final point on Example #2… Represents Certified EHR Technology or “CEHRT” (Optional Transport) Represents Certified EHR Technology or “CEHRT” (Required Transport) EHR Affiliated HISP

14. NwHIN Example 1.EHR generates CCDA 2.EHR sends CCDA to eHealth Exchange Participant 3.eHealthExchange Participant sends to Provider B Provider A Provider B CEHRT eHealth Exchange Participant (formerly NwHIN Exchange) Example 1 Transmit Summary Care Record Using eHealth Exchange Participant An eHealth Exchange Participant does not have to be certified in order for Provider A’s transmissions to count for MU. However, Provider A must still use CEHRT to generate a standard summary record in accordance with the CCDA.

15. Provider 1Provider 2Provider 3Provider 4 Provider 5 Providers #1-4 (1) have CEHRT, and (2) use the CEHRT’s transport capability (Direct or SOAP) to send a CCDA to a HISP/HIE that enables the CCDA they’ve sent the HISP/HIE to be subsequently pulled by Provider #5. HISP/HIE Transmit Summary Care Record Using “Pull” or “Query” Infrastructure In this scenario, the HIE does not have to be certified.

16. Provider 1Provider 2Provider 3Provider 4 Provider 5 If Providers #1-4 do not have CEHRT, their EHR technology will either 1.Need to be certified as a pair with HISP/HIE to be able to create the CCDA and transmit it to Provider 5 (per the prior slides). 2.Need to use an HIE that has been certified to support this criteria (per the prior slides). HISP/HIE Transmit Summary Care Record Using “Pull” or “Query” Infrastructure

17. Provider 1Provider 2Provider 3Provider 4 Provider 5 Regardless of certification path, Provider #5 needs to “pull” the summary care record in order for Provider #1-4 to potentially count the pull in their numerator. For all Providers where the patient meets the denominator requirements, when Provider #5 pulls they can then count that pull in their numerator as a transmission to Provider #5 (e.g., Providers #1-3 saw the patient during the reporting period but #4 did not; thus only Providers #1-3 could count the pull). HISP/HIE Transmit Summary Care Record Using “Pull” or “Query” Infrastructure In the “pull” scenario, accurately counting transactions for the providers’ numerators and denominators represents a non-trivial challenge.