1. HITPC Meaningful Use Stage 3 RFC Comments July 29, 2013 Information Exchange Workgroup Micky Tripathi

2. Agenda Provider directory recommendation Data portability 2

3. Revisit provider directory recommendation Provider directory recommendation 3

4. Principles for Provider Directories (continued) 5.Transactions: A.Querying systems must have ability to: 1.Present authenticating credentials of requesting entity 2.Validate authenticating credentials of sending entity 3.Present provider-identifying information 4.Securely transmit query message B.Provider directory must have ability to: 1.Validate authenticating credentials of requesting entity 2.Present authenticating credentials to requesting entity 3.Match provider 4.Respond with unambiguous information necessary for message addressing and encryption or acknowledgement of non-fulfillment of request C.Provider directories must have administrative capabilities to: 1.Submit updated provider directory information (additions, changes, deletions) to external provider directories 2.Receive and process provider directory updates from external provider directories 6.Transaction details: a.Provider directories should contain minimum amount of information necessary on EPs and EHs to address and encrypt directed exchange and/or query for a patient record messages b.Provider directories should contain minimum amount of information necessary on EPs and EHs to disambiguate multiple matches (i.e. same provider at different entities, providers with the same name, etc) 4

5. Data Portability 5

6. Background As the EHR installed base, we expect to see growing demand for data portability across vendor systems – Market surveys suggest that 20-30% of providers could switch vendors in the next 2 years, suggesting that there is some urgency to the issue This is a testament to the urgency of the need because currently the difficulty of data migration is a large barrier to exit for providers contemplating switching vendors – Ad hoc process that is highly variable and fraught with potential for errors and lack of continuity in medical record completeness – Difficult to include in contracts in a way that is operationally executable when needed – can be difficult or impossible to execute if vendor is not cooperative or system has been highly customized or if mismatch exists between source and receiving system capabilities 6

7. Background (continued) Data or information can be lost, rendered operationally inaccessible, stripped of context/meaning, or misplaced leading to erroneous context/meaning – Safety – records attached to wrong patient, data placed in wrong fields, etc – CQMs and CDS – loss of data important to measurement and decision support, such as look-back periods, exclusions, etc can cause disruption in performance improvement efforts – Administrative – loss of data important to revenue cycle can cause disruption in revenues A standard for data portability would set a common baseline for medical record continuity that will be vital as the EHR user base grows and matures, and the industry comes to increasingly rely on electronic medical records and MU-related EHR functions – Difficult to completely define data migration requirements because needs may vary locally – However, setting a floor will inspire greater market dynamism by lowering barriers to exit and promote safety and continuity of care by reducing opportunities for errors 7

8. Recommendation (draft) HITPC recommends: – Data Portability: EHR systems have the ability to electronically export and import medical record and administrative information across EHR vendor systems to enable users to switch EHR vendors without significant or material loss of clinical or administrative data 8

9. Principles for Data Portability HITPC recommends that the following principles be used for establishing requirements and standards for data portability across EHR vendor systems: 1.Consistency: Build on CCDA approach in alignment with general HITECH direction. Perhaps consider CCDA templates specific to “Cross-System Data Portability”? 2.Content: Should encompass all clinically and administratively-relevant information that can be reasonably transferred across systems without loss of essential patient, clinical, and administrative context or meaning Clinical data should: Extend beyond MU data set to include at least TOC content ? Retain structuring of data Retain structure/context of notes Allow transfer of attached documents and retain attachment to patient Administrative data should: Retain claims transactions for reasonable time period covering transition Retain scheduling and appointment information for reasonable time period covering transition Other 3.Time horizon: Should allow user-configurable setting of time period to cover legal medical record retention requirements as well as to support look-back periods for decision support, CQMs, and care management 9

10. Next Steps HITPC presentation on August 7 th 10

11. Data Portability Background Materials 11

12. IEWG 103 Data portability RFC Question What criteria should be added to the next phase of EHR Certification to further facilitate healthcare providers’ ability to switch from using one EHR to another vendor’s EHR? Stage 2 Certification Criterion: Enable a user to electronically create a set of export summaries for all patients in EHR technology formatted according to the standard adopted at § 170.205(a)(3) that represents the most current clinical information about each patient and includes, at a minimum, the Common MU Data Set and the following data expressed, where applicable, according to the specified standard(s): (i) Encounter diagnoses. The standard specified in § 170.207(i) or, at a minimum, the version of the standard at § 170.207(a)(3); (ii) Immunizations. The standard specified in § 170.207(e)(2); (iii) Cognitive status; (iv) Functional status; and (v) Ambulatory setting only. The reason for referral; and referring or transitioning provider’s name and office contact information. (vi) Inpatient setting only. Discharge instructions. Comment Summary 56 comments The majority of commenters felt this criterion was important and that further progress needed to be achieved around data portability. A number of commenters felt this criterion was unnecessary or duplicative of other criteria. A few commenters questioned if this criterion would add significant value as substantially more data would need to be migrated to maintain continuity. 12

13. IEWG 103 Data portability Comment Summary Commenters suggested a number of new data types that should be added: Many commenters suggested new data elements included in Stage 3 should be added to this criterion Many said any historical data that is required to calculate the Stage 3 CQMs In future stages this requirement should be changed to include any additions to objectives and CQMs. Other structured data where possible and document export as readily viewable documents where structured data is not available. All currently accepted elements of the CCD formatted according to the standard. Patient notes Allergies Past medical history Nutrition/diet orders Family/social history data (fluoride status of home water, second hand smoke exposure, alcohol use, drug use, cessation counseling, etc.) Non‐lab screening data (depression screen (PHQ9), asthma screen, hearing screen, autism screen, vision screen, etc.) Free text narrative Consent History of present illness Review of systems documentation Physical examination documentation Progress notes Signed notes Consultations Provider data 13

14. IEWG 103 Data portability Comment Summary Two commenters expressed a specific concern that the CCDA could not adequately provide/represent the information a provider needs to switch from one EHR to another. One felt that HL7 Quality Reporting Document Architecture (QRDA) category 1 might be better able to populate a patient record for historical quality measurement needs. While the other thought significant work would be required to support this functionality this criterion aims for. A few commenters questioned if this criteria could wait for a future Stage of meaningful use. One commeter requested this criterion be removed from Stage 3. One commenter felt the criterion should require certified EHRs to be able to export data based on either number of encounters of by a specified time period. Another commenter requested the ability to transfer by diagnosis. One commeter raised the point that in the long-term EHRs may not be viewed as the central repository for a patient’s entire medical record as this function might be assigned elsewhere. A few commenters felt more work was needed to ensure EHRs are able to import this data when a provider switches systems. 14