Provider Data Migration and Patient Portability NwHIN Power Team August 28, /28/141

HIT Policy Committee Recommendations The Information Exchange Workgroup sees two use cases that need to be addressed to promote an efficient HIT marketplace and to support safe and effective care delivery – Provider Data Migration: Provider switching from one or more EHR systems to another (or multiple systems) – Enable providers switching EHR systems to continue providing seamless care to patients (coded data in old system is consumable by the new system so clinical decision support still works) – Patient Portability: Patient requesting the movement of their complete record (e.g., to a new primary care provider) – Enable patients who switch providers to have their care continue seamlessly (no repeat tests, missing key clinical information, etc.)

HIT Policy Committee Recommendations The HITPC recommends that the HIT Standards Committee, by Stage 3 of Meaningful Use, develop standards and technical specifications to address both the provider data migration and patient portability use cases (to include such cases as patient care, clinical quality metrics and clinical decision support) a)The HITSC should determine the necessary elements of a core clinical record that will establish a first step on the path towards improved data portability for patients and providers b)The HITPC suggests the HIT Standards Committee explore the adoption of a core clinical record that is easily extractable and consumable by EHRs to support the provider data migration and patient portability use cases

HIT Policy Committee Observations (1 of 2) Expect to see rising 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 Difficulty of data migration is a barrier to exit for providers who are switching vendors, and a barrier to continuity of care for patients who are switching providers – 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 EHR contracts in a way that is operationally executable when needed – Can be difficult or impossible to execute if vendor is not cooperative, system has been highly customized, or if mismatch exists between source and receiving system capabilities 8/28/144

HIT Policy Committee Observations (2 of 2) Data 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. – Clinical Quality and Decision Support – Loss of data important to quality measurement and clinical 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 Challenges – Difficult to completely specify data migration requirements because needs may vary locally for a variety of reasons including record retention laws, provider/patient preferences, and provider documentation patterns – EHR migration use case covers data and workflow needs beyond the core clinical record that may be required for continuity of business and clinical care 8/28/145

2014 Data Portability Criterion 8/28/146 § (b) (7) Data portability. Enable a user to electronically create a set of export summaries for all patients in EHR technology formatted according to the standard adopted at § (a)(3) [Consolidated CDA] 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 § (i) [ICD-10-CM] or, at a minimum, the version of the standard at § (a)(3) [SNOMED-CT]; (ii) Immunizations. The standard specified in § (e)(2) [HL7 CVX]; (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. Note: These same data elements are required for Transitions of Care, except that ToC also requires provider name and contact information (ambulatory only), and is not limited to the “most current” information.

Common MU Data Set Patient name Sex Data of birth Race* Ethnicity* Preferred language* Care team members Medications* Medication allergies* Care plan Problem(s)* Laboratory test(s)* Laboratory value(s) / result(s) Procedures* Smoking status* Vital signs 8/28/147 * Defined vocabulary must be used

Questions for Discussion What other discrete data elements, and/or narrative data, should be added to the 2014 Data Portability criterion? For example: – Patient history – with time period as a specifiable parameter, with a default of "1 year prior to most recent encounter" (e.g., one year's worth of labs, reports, etc.) – Master file of all users and roles – Future appointments – Insurance information 8/28/148

Questions for Discussion Should the core elements be limited to the “most current” (as in 2014 Edition)? What historical data might be needed for clinical quality measurement and clinical decision support? Do needs differ for the two use cases (patient portability and provider data migration)? What data and workflow considerations need to be addressed to help assure continuity of business and clinical care, when a provider changes EHR vendors? EHR vendors probably have developed common practices in the real world; can ONC seek actual input from vendors who have migrated data into their systems? What would the vendors like to see? 8/28/149

Blank 8/28/1410