EMR Data PortabilitySetting the Stage for Interoperability

May 5, 2008By: Harley Rodin & Ed Chang

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.

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

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

OntarioMD’s EMR Interoperability Strategy

1. Provide data portability among certified EMRs

2. Establish a standard Core Data Set for data portability

3. Use the Core Data Set as the basis for messaging between EMRs and the broader eHealth environment

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

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

Comprehensive Core Data Set - Administrative and Clinical Information

Cumulative Patient Profile (CPP) segments

• Personal History• Family History• Past Health• Problem List• Risk Factors• Allergies & Adverse Reactions• Medications & Treatments• Immunizations

Non-CPP segments• Patient Demographics• Laboratory Results• Appointments • Physician’s My Clinical Notes• Reports Received:

– Scanned– Images– Audio– Fax– Messages & Attachments– etc.

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

• 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

Defining Data Portability, cont.

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

Key Finding: Free Text Barrier to Interoperability

CCIThird Party Billing

SNOMED-CT

ICD10-CA ICPC-2

LOINCProvincial Billing

Allergies

Medication SpecialAuthorizations Transcription

Coding in theBackground

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

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

Questions and Answers