EMR Data Portability

1. EMR Data Portability Setting the Stage for Interoperability May 5, 2008 By: Harley Rodin & Ed Chang

2. Background – OntarioMD’s EMR Mandate Funding and transition support of approved Clinical Management Systems (CMS) for eligible primary care physicians A CMS has three integrated components: EMR, Scheduling and Billing. Management of the CMS Certification Cycle Development of the CMS Specification, defining criteria for certification of vendor offerings. Validation of vendor offerings against the functionality defined within the CMS Specification.

3. Interoperability of e-Health Applications • The ability for medical practices to receive and share data captured within their EMR to achieve interoperability more broadly within the eHealth environment. • The Canadian e-Health environment is still taking shape, and interoperability will be a critical success factor: • Physician Office Systems • Drug Information Systems • Jurisdictional / Provincial Laboratory Information Systems • e-Referrals • Patient’s Hospital Discharge Summaries & Text Reports • Radiology Information Systems • Websites containing Clinical References, Decision Support Applications & Educational Content • Chronic Disease Management & Preventative Care Activities

4. Challenges to Interoperability • The evolution of Ontario’s eHealth landscape is still taking place, and will continue to do so for many years. • The need to evolve the capabilities of EMRs to support interoperability, in the absence of eHealth applications and standards • How do we address these challenges? • Data Portability standards through the CMS Specification, to serve as a building block towards interoperability

5. OntarioMD’s EMR Interoperability Strategy • Provide data portability among certified EMRs • Establish a standard Core Data Set for data portability • Use the Core Data Set as the basis for messaging between EMRs and the broader eHealth environment

6. The Business Case for Data Portability Standards • Many EMR vendors with proprietary data sets and data definitions. • The need to protect providers’ investment in EMR technology for the cases when: • Software is no longer appropriate for the practice’s needs • The vendor no longer supports their software • The physician joins a different practice and needs to transfer their patient data

7. Scope of Data Portability – CMS Specification 2.0 • Export / Import administrative and clinical information needed to support: • continuity of patient care • preventative care • chronic disease management • patient safety • Self-Administered • Keep it simple to start with: • Batch, encrypted, and compressed transfer

8. Cumulative Patient Profile (CPP) segments Personal History Family History Past Health Problem List Risk Factors Allergies & Adverse Reactions Medications & Treatments Immunizations Comprehensive Core Data Set - Administrative and Clinical Information • Non-CPP segments • Patient Demographics • Laboratory Results • Appointments • Physician’s My Clinical Notes • Reports Received: • Scanned • Images • Audio • Fax • Messages & Attachments • etc.

9. Defining Data Portability • Key industry stakeholders were engaged for existing knowledge and experience • Working Group Participation • OntarioMD • Ontario Health Informatics Standards Council (OHISC) • ITAC/CHITTA & the CMS Vendor Community • Consultation • Family Health Team Physician Leaders Group • MOHLTC • OMA • Physician Colleges

10. Defining Data Portability, cont. • Reviewed and utilized many standards at various points of implementation that addressed parts of the physician’s Data Portability requirement • College of Physician and Surgeons of Ontario (CPSO) Cumulative Patient Profile (CPP) • Ontario College of Family Physicians (OCFP) requirements • Ontario Health Profile • Vendors CPP schemas • Alberta POSP T/COPD – similar business need, different scope • Other standardization initiatives: • Ontario Continuing Care e-Health Request and Clinical Care Data Set (OHISC Tier 2 Approval) • British Columbia e-Medical Summary project (based on HL7 RIM and CDA, R2) • IHE Medical Summary (XDS-MS) Content Integration Profile

11. Lessons Learned through Data Portability Requirements Development Process • The absence of standards and the introduction of proprietary interfaces presents a big problem • Achieving a more structured documentation approach from a physicians perspective is essential • Interjecting too much structure for data input is observed to impact the patient encounter that could: • lead to data quality issues • cause physicians to abandon important parts of the clinical application at point of care

12. Key Finding: Free Text Barrier to Interoperability

13. Automatic Coding of Free Text • More structured use of clinical vocabularies in the EMR from a provider point-of-view is required • Need to code text information in order to achieve interoperability • E.g. ICPC, ICD10-CA, etc. • Clinical vocabularies and codes are important to convey the meaning of patient encounters • Need to translate narrative and discrete information contained within the EMR in support of interoperability • Ideally, this translation will be accomplished in the background without interrupting the physicians’ natural dialogue with their patients

14. Leveraging Data Portability for Interoperability The data captured within the EMR as a result of the Core Data Set and data portability requirements serves as a stepping stone to greater interoperability: Examples: eReferrals from a Primary Care Physician to a Specialist Transferring hospital discharge summary information into the EMR Interoperability will be achieved as standards become integrated into the EMR and eHealth applications become available

15. Questions and Answers