Transcript EMR Data Portability Setting the Stage for Interoperability

EMR Data Portability
Setting the Stage for Interoperability
May 5, 2008
By: 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
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
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
ICD10-CA
ICPC-2
Allergies
SNOMED-CT
LOINC
Provincial Billing
Third Party Billing
Medication Special
Authorizations
CCI
Transcription
Coding in the
Background
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