1. Beacon Community Program Build and Strengthen – Improve – Test innovation Beacon-EHR Vendor Full Affinity Group August 2, 2013

2. Full AG Roll call – Lynda Rowe Transitions of Care using a Referral Management software product – Dr. Kendrick Update on Beacon Transport Pilot Progress in RIQI – Lou Della Posta ONC White Paper Discussion “Key Considerations For Health Information Organizations Supporting Meaningful Use Stage 2 Patient Electronic Access Measures” – Lynda Rowe eHealth Exchange Questions Update –Adele Allison/Lynda Rowe Wrap up/Next Steps – Adele Allison Today’s Goals 1

3. Pilot Option 10 Pilot Description The Primary Care Provider, Provider A, pushes a CCD to HIE using XDR; Provider B (any treating provider of any specialty) queries HIE Pre-Condition (Goal) Access to longitudinal patient data by any treating provider (hospital, lab, specialist, etc.)

4. Actors EHR Vendor NextGen Practice/Providers Blackstone Valley Any Treating Provider Provider A Provider B Beacon Community Rhode Island HIE/HISP HIE: CurrentCare HISP: Inpriva Technical Standards Access to longitudinal patient data including PCP, Provider A, CCDs (C32) sent via Direct XDM Email transport Certifications 1. PCP, Provider A,. sends CCD from their EHR to CurrentCare (CC) via XDR (SOAP + XDR) 2. CC confirms receipt/consumption of CCD 3. Provider B accesses CC to view Data (and/or CCD) sent to CC from Provider A Pilot Option 10

5. Sequence of Events CCD is sent from PCP, Provider A, to participation gateway (PG) via XDR to confirm consent; PG confirms consent via Participation service - once consent is confirmed, CCD forwarded to edge gateway for access by CurrentCare. Provider B, accesses the CurrentCare viewer, searches for patient and has access to data including CCD documents sent. Completion Criteria Access by Provider B of patient data sent by Provider A within the CurrentCare HIE Pilot Option 10

6. SENDING: 1. EHR Vendor must be able to generate a CCD consistent with C32 Standards (and additional CurrentCare constraints) 2. EHR Vendor must support an automated clinical trigger, such as a locked record, which then generates the CCD. 3. EHR Vendor must be able to use XDR as the protocol. VIEWING: 1. Provider B (Hospital, Lab, Specialist, etc.) accesses CurrentCare, searches for patient and views CCD. Solution Suggestions – The How Numerator Number of times patient data is accessed within 30 days Number of times Provider B is able to get data from the HIE Denominator Number of times patient data is sent via a CCD within 30 days Number of times Provider B is directed to the HIE

7. DescriptionEffectMitigation Availability of Data All data submitted to the HIE is subject to consent May limit search capabilities Increase enrollments Access to viewer Only authorized/ trained users are allowed access to the Viewer Limits access to information Continue training effort Quantifying access to records Tools available to determine access Ability to identify by patient which CCD was accessed and by whom Challenges/Risks

8. Next Steps Complete reporting mechanism Quantify number of CCDs sent within given period Determine MDNs for CCDs sent Validate and report results Pilot Option 10

9. Beacon Pilot Progress Tulsa – In Progress Working on developing pilot option 9+ as well as the details behind numerator denominator calculations Mississippi – Not able to run pilots at this time South East Michigan – In Progress Went online with one Allscripts practice this week using XDS.b as the transport mechanism in an effort to work toward eHealth exchange – Looking to add an additional Allscripts practice in the next week as well In reference to User Story 2b, SE Michigan is working with Success EHS to pilot PIX and XDS.b Query & Retrieve, with automatic triggers to query our MPI and XDS.b repository to retrieve a longitudinal CDA Keystone – In Progress Developed Technical Script this week RIQI – In Progress Pilot: ToC: CEHRT to an HIO/HIE/HISP - Query by Provider B – Currently: data is being sent from Provider A, Blackstone Valley, and it is being stored within the HIE (discrete data and the document itself). – To be completed as soon as next week: Quantifying view of the data by Provider B. WNY – In Progress Direct accounts have been established for Elmwood and staff training has commenced on the use of Direct email. Mirth is working on the automation process, in the meantime Neva will send files to Elmwood. Go live is planned for 07/23 with Direct function to be implemented shortly there after. 8

10. Possible Pilot Scenarios 1 - 5 9 Pilot # Query OR Push Provider A Transport Method Certified Transport Entity Transport Method To Provider B C-CDA Generation MU 2 Metric Reporting Description Pilot 1 PushDirect (SMTP + S/MIME) EHR TechnologyTransport is directly from provider A Provider A EHR EHR Supports all aspects of DIRECT Transport Pilot 2 PushAny Edge Protocol HISP /HIE/HIODirect (SMTP + S/MIME)HISP/HIE/HIOHISP/HIO/HIEHISP/HIE/HIO must be certified to the TOC objective, i.e. support The Direct Applicability statement/produce a C-CDA Pilot 3 PushAny Edge Protocol EHR module Certified with Associated HISP/HIO (relied upon software) Direct (SMTP + S/MIME)EHR Vendor and relied upon software EHR vendor + relied upon software must meet MU2 criteria Pilot 4 PushDirect (SMTP + S/MIME)+ XDR/XDM EHRTransport is directly from provider A Provider A EHR Same as Pilot 1, except adding the optional XDR/XDM transport Pilot 5 PushAny Edge Protocol HISP /HIE/HIODirect (SMTP + S/MIME)+ XDR/XDM HISP/HIE/HIOHISP/HIO/HIEHISP/HIE/HIO must be certified to the TOC objective, i.e. support The Direct Applicability statement/produce a C-CDA

11. Possible Pilot Scenarios 6 - 10 10 Pilot # Query OR Push Provider A Transport Method Certified Transport Entity Transport Method To Provider B C-CDA Generation MU 2 Metric Reporting Description Pilot 6PushAny Edge Protocol EHR module Certified with Associated HISP/HIO (relied upon software) Direct (SMTP + S/MIME)+ XDR/XDM EHR Vendor and relied upon software EHR vendor + relied upon software must meet MU2 TOC criteria Pilot 7PushSOAP + XDR/XDM EHR – Must be certified for optional SOAP transport Transport Directly From Provider A Provider A EHR EHR Hosted SOAP + XDR/XDM Pilot 8QuerySOAP + XDR/XDM EHR – Must be certified for optional SOAP transport Any Transport via an HIE/HIO/HISP Provider A EHRHISP/HIO/HIEContent may be repackaged by HISP/HIO for provider B Pilot 9Push OR Query Any TransportHIO as an eHealth Exchange participant Query or push to provider via eHealth Exchange certified protocol Provider A EHRHIO eHealth exchange participant HIO must be a certified eHealth Exchange participant Pilot 10 QueryAny Certified Transport CEHRT natively or with relied upon software None- Query basedProvider A EHRHIO/HIE/HISPProvider A must be using CEHRT

12. Vendor Pilot Options 11 PilotSendReceive BeaconVendorBeaconVendor 1: Direct - EHR vendor complete certification Crescent City, Tulsa,SE MISuccess EHS (not yet in production) Cincinnati, Inland NW, RIQI, Tulsa, UtahNextGen UtahVitera Crescent City, SE MI, TulsaSuccess EHS 2: Direct - HIE/HIO/HISP modular certification Inland NW, ? Tulsa & KeystoneGreenwayCincinnati, Inland NW, RIQI, Tulsa, UtahNextGen Cincinnati, Inland NW, RIQI, Tulsa, UtahNExtGenUtahVitera UtahViteraCrescent City, SE MI, TulsaSuccess EHS Crescent City, SE MI, TulsaSuccess EHS Keystone, Southeast MI, WNY, Utah (Pro Only)AllScripts (Pro & Ent.) To HIO Keystone, Southeast MI, WNY, Utah (Pro Only)AllScripts (Pro & Ent.) Need HISP 3: Direct - EHR vendor + relied upon software Cincinnati, Inland NW, RIQI, Tulsa, UtahNExtGenCincinnati, Inland NW, RIQI, Tulsa, UtahNExtGen UtahVitera UtahVitera Crescent City, SE MI, TulsaSuccess EHS Keystone, Southeast MI, WNY, Utah (Pro Only)AllScripts (Pro & Ent.) Need HISP Keystone, Southeast MI, WNY, Utah (Pro Only)AllScripts (Pro & Ent.) Need HISP 4: Direct + XDR/XDM - EHR vendor complete certification Not Technologically Feasible at This Time 5: Direct + XDR/XDM - HIE/HIO/HISP modular certification Inland NW, ? Tulsa & KeystoneGreenwayCincinnati, Inland NW, RIQI, Tulsa, UtahNextGen Cincinnati, Inland NW, RIQI, Tulsa, UtahNExtGen UtahVitera Crescent City, SE MI, TulsaSuccess EHS Keystone, Southeast MI, WNY, Utah (Pro Only)AllScripts (Pro & Ent.) To HIO Keystone, Southeast MI, WNY, Utah (Pro Only)AllScripts (Pro & Ent.) Need HISP

13. Vendor Pilot Options 12 PilotSendReceive BeaconVendorBeaconVendor 6: Direct + XDR/XDM - EHR vendor + relied upon software Cincinnati, Inland NW, RIQI, Tulsa, UtahNextGenCincinnati, Inland NW, RIQI, Tulsa, UtahNExtGen Keystone, Southeast MI, WNY, Utah (Pro Only) Allscripts (Pro & Ent.) Need HISP Keystone, Southeast MI, WNY, Utah (Pro Only)Allscripts (Pro & Ent.) Need HISP 7: SOAP + XDR/XDM - Push from EHR to EHR Inland NW, ? Tulsa & KeystoneGreenway (XDS & XDR) Inland NW, ? Tulsa & KeystoneGreenway (XDS & XDR) Cincinnati, Inland NW, RIQI, Tulsa, UtahNExtGenCincinnati, Inland NW, RIQI, Tulsa, UtahNExtGen Crescent City, SE MI, TulsaSuccess EHS (XDS & XDR) Crescent City, SE MI, TulsaSuccess EHS (XDS & XDR) Keystone, Southeast MI, WNY, Utah (Pro Only) Allscripts (Pro & Ent.)Keystone, Southeast MI, WNY, Utah (Pro Only)Allscripts (Pro & Ent.) 8: SOAP + XDR/XDM - Push to HIO/HISP/HIE who forwards to Provider B Inland NW, ? Tulsa & KeystoneGreenway (XDS & XDR) Inland NW, ? Tulsa & KeystoneGreenway (XDS & XDR) Cincinnati, Inland NW, RIQI, Tulsa, UtahNextGenCincinnati, Inland NW, RIQI, Tulsa, UtahNextGen Crescent City, SE MI, TulsaSuccess EHS (XDS & XDR) Crescent City, SE MI, TulsaSuccess EHS (XDS & XDR) Keystone, Southeast MI, WNY, Utah (Pro Only) Allscripts (Pro & Ent.)Keystone, Southeast MI, WNY, Utah (Pro Only)Allscripts (Pro & Ent.) 9: EHR to an eHealth Exchange push to or query from Provider B Possible in All Environments as Long as Transport From eHealth Exchange Participant is Supported. 10: CEHRT to an HIO/HIE/HISP - Query by Provider B Possible in All Environments With Differences in the Types of Transport Supported. EHR sending vendor must support one CEHRT transport

14. VDT Objective Measure 1 for EPs and EHs 13 Objective: Provide patients the ability to view online, download and transmit their health information within four business days (EP) or 36 hours (EH/CAH) of the information being available to the EP VDT Measure 1 More than 50 percent of all unique patients seen during the EHR reporting period are provided timely (within 4 business days after the information is available (EP) or 36 hours after discharge(EH/CAH)) online access to their health information NumeratorDenominator The number of patients in the denominator who have timely online access to their health information Number of unique patients seen during the EHR reporting period; Calculations Option 1Option 2 HIO calculates the numerator/denominator. HIO’s CEHRT must know the total number of unique patients seen during the reporting period. To calculate the numerator, an HIO’s CEHRT must be able to ascertain if the required MU data elements were added to the patient portal from an EP within four business days of the information being available HIO Creates a report that lists patient names or identifiers for patients that have had the MU required data elements provided to the CEHRT (potentially a patient portal) and provides the report to the EP. EP verifies which patients to include in their numerator. Important Notes The patient is REQUIRED to receive/view/download information using CEHRT. the EP Does Not need to use CEHRT to send initial information to patient. In the event an HIO decides to seek certification for EHR technology to support EPs/EHs in achieving their MU objectives for patient electronic access, certification will require that the EHR technology can at least calculate the numerator for these measures and the EP/EH should expect that this ability be available to them.

15. VDT Objective Measure 2 for EPs and EHs 14 Objective: Provide patients the ability to view online, download and transmit their health information within four business days (EP) or 36 hours (EH/CAH) of the information being available to the EP VDT Measure 2 More than 5 percent of all unique patients seen/discharged during the reporting period (or authorized rep.) view, download, or transmit (VDT) to a third party their health information. NumeratorDenominator The number of unique patients (or authorized rep.) in the denominator who have viewed online, downloaded, or transmitted to a third party the patient's health information/discharge information Number of unique patients (or authorized rep.) seen/discharged during the EHR reporting period; Calculations Option 1Option 2 HIO calculates the numerator, denominator, and resulting percentage and provides a report to EPs/EHs. To calculate the denominator, the HIO’s CEHRT must know the total number of unique patients seen during the reporting period. To calculate the numerator, an HIO will need to ensure that only unique patients seen during the reporting period are counted in the numerator. Additionally, the HIO’s CEHRT would need to count authorized representatives who access the patient information in the numerator, without any double counting of the unique patient and authorized representative. HIO creates a report that lists patient names or identifiers. HIO provides the report to the EP/EH to allow them to verify which patients to include in their numerator. Important Information: Enough data will be needed in the report to match each patient to their list of unique patients seen during the reporting period (their denominator), in order to calculate their numerator. Depending on the connection between the HIO’s CEHRT and the EP/EH’s CEHRT, the report may need to include time stamps that the data was viewed, downloaded, or transmitted. Important Notes The patient is REQUIRED to receive/view/download information using CEHRT. the EP Does Not need to use CEHRT to send initial information to patient. The patient may but is NOT REQUIRED to use CEHRT to transmit information to the provider.

16. Secure Messaging Objective Measure 1 15 Objective: Use secure electronic messaging to communicate with patients on relevant health information Secure Messaging Measure 1 A secure message was sent using the electronic messaging function of CEHRT by more than 5 percent of unique patients (or their authorized representatives) seen by the EP during the EHR reporting period. NumeratorDenominator The number of patients or patient-authorized representatives in the denominator who send a secure electronic message to the EP that is received using the electronic messaging function of CEHRT during the EHR reporting period. Number of unique patients seen by the EP during the EHR reporting period. Calculations Option 1Option 2 HIO provides EPs and patients/authorized representatives with a CEHRT mailbox to send and receive secure messages. Important Considerations The HIO must have the capability to either generate a report of patients an EP has received secure messages from in the CEHRT, or calculate the numerator and denominator and provide a report to the provider. HIOs should keep in mind that EPs may desire to have a report of the patients included in the numerator to support their attestation information during an audit. HIO provides patients/authorized representatives with a mailbox to send and receive secure messages, potentially via Direct protocols that connects with a provider’s CEHRT. EP utilizes CEHRT (not provided by the HIO) to receive a secure message from the HIO- provided patient mailbox. An HIO can provision a patient with a Direct address and mailbox. Important Considerations The HIO is NOT REQUIRED to provide a report to EPs to assist them with calculating the measure, NOR is the HIO required to calculate the numerator for the EP. However, HIOs should consider that EPs may ask them to provide reports that may be used to support their attestation during an audit. Important Notes The patient may but is NOT REQUIRED to use CEHRT to transmit information to the provider. This measure requires the EP’s system that receives the secure message to BE CERTIFIED. If an HIO provides a mailbox outside an EP’s CEHRT, the mailbox REQUIRES CERTIFICATION. If an HIO is providing patients with the ability to create and send a secure message, possibly via Direct, it would NOT REQUIRE CERTIFICATION

17. HIOs that intend to support EP’s/EH’s patient electronic access measures by offering an online portal must use a certified portal with the following capabilities : View: display the common MU dataset, EPs (provider’s name/office contact information), EHs (Admission & discharge dates & locations; discharge instructions; & reason(s) for hospitalization). 2. Download: ability for patients (or authorized caregiver) to download the data listed in item number one above in human readable or consolidated clinical data architecture (CCDA) format. 3. Transmit: ability to send the data listed in item number one above to a third party in human readable or CCDA format, via the Direct SMTP standard. 4. Utilize Web Content Accessibility Guidelines (WCAG) 2.0, Level A Conformance for the online site. 5. Utilize any encryption and hashing algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the FIPS Publication 140-2. 6. Depending on the type of certification, modular or complete, perform one or both of the following: – a. Create a report or file that enables a user to review the patients or actions that would make the patient or action eligible to be included in the measure’s numerator. The information in the report or file created must be of sufficient detail such that it enables a user to match those patients or actions to meet the measure's denominator limitations when necessary to generate an accurate percentage; and/or – b. Electronically record the numerator and denominator and create a report including the numerator, denominator, and resulting percentage associated with each applicable meaningful use measure. 16 HIO Online Portal Certification Requirements

18. Other Considerations for HIOs Providing VDT Functionality 17 Single Sign-on to Multiple Patient Records HIO may provide users with access to not only their own records, but also those for whom they are an authorized representative (a spouse’s, children’s, and elderly parents’ records through a single sign-on to the patient portal. Each individual’s record that is viewed through the single sign-on can be counted in an EP/EH’s numerator provided each individual is in their denominator HIO providing single sign-on must have the capability to ascertain which records were viewed and provide the right EP/EH with either a numerator/denominator calculation or a report of the patients whose records were viewed. Adolescent Patient Records HIOs supporting the patient engagement Stage 2 measures must carefully craft policies for providing access to adolescent patient records. HIPAA protects adolescent health information from parental access under specific circumstances HIOs must account differing state and federal laws through policies and technological solutions. Meaningful use regulations also give EPs considerable discretion in deciding what information to make available to adolescents. EPs must be careful not to make policy decisions which differ from their HIOs because it may hamper their ability to attest to VDT Measure 2 Providing Audit Documentation EPs/EHs may need a list of the patients that are counted in the numerator (including those whose records were accessed by an authorized representative for VDT Measure 2) VDT Measure 2: The list may need to include the date patients or their representatives accessed the online system, which will help EPs/EHs demonstrate that it transpired during the reporting period Any information used to determine the meaningful use performance of the EP should be kept in such a way that it can be provided during a desk audit in the future.

19. Wrap Up/Next Steps 18 Final comments All attendees Co-Chairs: Chuck Tryon/Adele Allison Next steps – Adele Allison Conclusion