1. 360Exchange (360X) Project 12/06/12

2. Reminders / announcements 360X Update CEHRT 2014 / MU2 Transition of Care Requirements 1 Agenda

3. This meeting is being recorded. If you don’t wish to be recorded, please hang up now. If you’re not speaking, please mute your line. Please don’t put us on hold (though dance breaks are fun). Due to events and holidays, we’ll hold the next community- wide (Thursday 11am) call on January 10, 2013 2 Reminders / Announcements

4. In the past, we’ve talked about our guiding principles… – It’s not to demonstrate that it’s possible – It’s to ensure that it’s clinically relevant and useful – It’s to ensure that it’s rapidly and widely deployable – It’s to reduce friction and/or add lubricant We’ve found that everyone is at a slightly different place and nobody is fully ready to support MU2 standards… yet. What’s the best path forward? – Our pilots will start with what folks can do now – Our 360X v1.0 Implementation Guide will point to our desired future – Both activities will inform and be informed by the other 3 360X Updates

5. Supporting Meaningful Use Stage 2 Transition of Care Requirements

6. CEHRT & MU Relationship Meaningful Use Stage 2 (MU2) CMS: Medicare and Medicaid EHR Incentive Programs Stage 2 outlines incentive payments (+$$$) for early adoption outlines payment adjustments(-$$$) for late adoption/non-compliance Reference: CMS Medicare and Medicaid Programs; Electronic Health Record Incentive Program – Stage 2 Final Rule 495.6 ONC: Standards, Implementation Specifications & Certification Criteria(SI&CC) 2014 Edition Specifies the data and standards requirements for certified electronic healthrecord (EHR) technology (CEHRT) needed to achieve “meaningful use” Reference: ONC Health Information Technology : Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions tothe Permanent Certification Program for Health Information Technology 170.314(b)(1)&(2)

7. MU2 Electronic Exchange Requirements MU2 focuses on actual use cases of electronic information exchange Measure #1 requires that a provider send a summary of care record for more than 50% of transitions of care and referrals. Measure #2 requires that a provider electronically transmit a summary of care for more than 10% of transitions of care and referrals Measure #3 requires at least one summary of care document sent electronically to recipient with different EHR vendor or to CMS test EHR Measure #1 requires that a provider send a summary of care record for more than 50% of transitions of care and referrals. Measure #2 requires that a provider electronically transmit a summary of care for more than 10% of transitions of care and referrals Measure #3 requires at least one summary of care document sent electronically to recipient with different EHR vendor or to CMS test EHR

8. CEHRT & MU Relationship Care Coordination / Transitions Meaningful Use Stage 2 (MU2) – Care Coordination CMS: Medicare and Medicaid EHR Incentive Programs Stage 2 Measure #2 : Provide an electronic ‘‘summary of care record for more than 10 percent of such transitions and referrals” using one of the accepted transport mechanisms specified in the rule. Reference: CMS Medicare and Medicaid Programs; Electronic Health Record Incentive Program – Stage 2 Final Rule 495.6 ONC: Standards, Implementation Specifications & Certification Criteria(SI&CC) 2014 Edition Electronically receive and incorporate a transition of care/referral summary Electronically create and transmit a transition of care/referral summary Reference: ONC Health Information Technology : Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions tothe Permanent Certification Program for Health Information Technology 170.314(b)(1)&(2)

9. CEHRT Criterion 170.314(b)(2) – Transition of Care (Send) In order for a certification criterion to be met, all specific capabilities expressed as part of it need to be demonstrated. For example, in 45 CFR 170.314(b)(2) there are two: (i)Create CCDA with requisite data specified for MU (ii)Enable a user to electronically transmit CCDA in accordance with: (a)Direct (required) (b)Direct +XDR/XDM (optional, not alternative) (c)SOAP + XDR/XDM (optional, not alternative) Thus, whatever EHR technology is presented for certification must demonstrate compliance with both (i) and (ii) under (b)(2) to meet the certification criterion. This also means that there’s no certification for ‘transport only’ as part of MUS2 / CEHRT 2014 Edition

10. Scenario 1 1.EHR generates CCDA 2.EHR performs as STA and sends Direct msg Complete EHR or EHR Module certification issued. STA/HISP function integrated into EHRs; no separate certification testing for HISP. Scenario 2 1.EHR sends “data” to HISP 2.HISP generates CCDA 3.HISP performs as STA and sends Direct msg EHR Module certification issued HISP certified independently as EHR Module. Scenario 3 1.EHR generates CCDA 2.EHR sends CCDA to HISP 3.HISP performs as STA and sends Direct msg Complete EHR or EHR Module certification issued HISP certified as “relied upon software” with the EHR. Certification given to the pair, not EHR and HISP separately. Valid Certification Scenarios for EHR Technology (Sending with Direct) Provider A Provider B EHR Affiliated HISP Provider A HISP Provider A Direct (SMTP + S/MIME) Provider B Direct (SMTP + S/MIME) Any Edge Protocol Any Edge Protocol What gets presented for certification 45 CFR 170.314(b)(2) (i)Create CCDA with requisite data specified for MU (ii)Enable a user to electronically transmit ToC in accordance with Direct (or Direct +XDR/XDM; or SOAP + XDR/XDM) Whatever EHR technology is presented for certification must demonstrate compliance with both (i) and (ii) under (b)(2) to meet the certification criterion.

11. MU Transition of Care Measure #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 percent 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.

12. Scenario 1 1.EHR generates CCDA 2.EHR performs as STA and sends Direct msg Complete EHR or EHR Module certification issued. STA/HISP function integrated into EHRs; no separate certification testing for HISP. Scenario 2 1.EHR sends “data” to HISP 2.HISP generates CCDA 3.HISP performs as STA and sends Direct msg EHR Module certification issued HISP certified independently as EHR Module. Scenario 3 1.EHR generates CCDA 2.EHR sends CCDA to HISP 3.HISP performs as STA and sends Direct msg Complete EHR or EHR Module certification issued HISP certified as “relied upon software” with the EHR. Certification given to the pair, not EHR and HISP separately. Approach #1 -- Send with CEHRT Required Transport: Using Direct Provider A Provider B EHR Affiliated HISP Provider A HISP Provider A Direct (SMTP + S/MIME) Provider B Direct (SMTP + S/MIME) Any Edge Protocol Any Edge Protocol CEHRT

13. Example #1 1.EHR generates CCDA 2.EHR (certified to include optional SOAP + XDR/XDM transport) sends message to Provider B using SOAP + XDR/XDM In this scenario, the EHR must be certified to support both Direct (required) and SOAP + XDR/XDM (optional) as transport standards. Approach #2 -- Send with CEHRT Optional Transport: SOAP + XD (Example) Provider A Provider B SOAP + XDR/XDM CEHRT Note: This is one example of how a provider may use EHR technology that has been certified to include optional transport standards. The CEHRT could support a different optional transmission mechanism (e.g., Direct + XDR/XDM). Also, as with the required Direct transport, the CEHRT has architectural flexibility to use relied upon software in their solution, seek modular certification, etc.

14. 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 repackages content as Direct message and sends to Provider B In this scenario, the EHR must be certified to support both Direct (required) and SOAP + XDR/XDM (optional) as transport standards. The HISP does not need to be certified. This meets the MU requirement for using CEHRT. Approach #2 -- Send with CEHRT Optional Transport: SOAP + XD via Intermediary (Example) HISP Provider A Provider B Direct (SMTP + S/MIME) SOAP + XDR/XDM CEHRT 1.Because Provider A is sending to Provider B using their CEHRT’s SOAP + XDR/XDM transport option, the fact there’s a “HISP in the middle” is irrelevant with respect to Provider A meeting MU requirements. 2.This allows any EHR vendor supporting the SOAP + XDR/XDM option to interoperate with any HISP that also offers SOAP + XDR/XDM support. 3.Under this approach, HISPs do not have to be certified 4.If EHRs implement SOAP/XD 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 Scenario #3 with minimal (or no) additional development/technical work on their part.

15. NwHIN Example 1.EHR generates CCDA 2.EHR sends CCDA to NwHIN Exchange Participant 3.NwHIN Exchange Participant sends to Provider B Complete EHR or EHR Module certification issued. NwHIN Exchange participant does not get certified. Approach #3 – Send via NwHIN Exchange Participant Provider A Provider B CEHRT NwHIN Exchange Participant (now eHealth Exchange) CEHRT Note: the regulation also permits an EP, eligible hospital, or CAH to count in their numerator instances where a summary care record for transitions of care or referrals was received via electronic exchange facilitated in a manner consistent with the governance mechanism ONC establishes for the nationwide health information network. ONC has not yet established a governance mechanism for the nationwide health information network. Until ONC establishes such a governance mechanism, this specific option will not be available.