OntarioMD Compliance Tracker

Refer to the EMR Core Data Set Standard (CDS-S) Specification for patient demographic data elements.

CDS-S Data Elements (DE01 - Patient Demographics):

CDS-S Data Elements (DE02 - Patient Address):

Refer to the EMR CDS-S Specification for physician roster data elements.

CDS-S Data Elements (Physician Roster - from DE01):

Refer to the EMR CDS-S Specification for patient enrolment history data elements. The definitive patient enrolment to a physician used for payment is kept by the MOH, not by the EMR Offering. The EMR user MUST be able to update the current and historical enrolment information. Patients are enroled to a specific physician within a Physician Group, not to the Physician Group as a whole. Patients rostered to a physician can be either enroled or non-enrolled. For more information Refer to “Processing Enrolment/Consent Forms Reference Manual - for Primary Care Groups” in the Related Documents section.

CDS-S Data Elements (Patient Enrolment History - from DE01):

Refer to the EMR CDS-S Specification for patient contact data elements. A contact is a person named by the patient as someone who should be contacted in specific situations. At a minimum, the EMR Offering MUST support two contacts per patient. Each contact MUST support multiple contact purposes/roles, including Substitute Decision Maker and Emergency Contact.

CDS-S Data Elements (DE03 - Patient Alternative Contact):

The EMR Offering MUST provide a method of preventing the creation of duplicate patient records. Duplicate records are identified by a name match, or by a health card number (HCN) match. HCN version codes MUST be excluded from the matching function. An HCN with a different version code should be considered the same patient record.

Merging of patients refers to the merging of the entire patient medical record (not only patient demographics). Merging duplicate records is a manual function controlled by the EMR user. Automatically merging duplicate records is not an acceptable solution. Prior to merging, the EMR user MUST be notified of the permanence of the action and given an opportunity to confirm the merging of duplicate patient records. There is no requirement to undo the merge.

Based on Ontario Regulation 114/94 (Medicine Act, 1991), Section 20 (2).

Refer to the EMR CDS-S Specification for provider demographic data elements.

CDS-S Data Elements (DE04 - Provider):

Refer to the CDS-S Specification for ongoing health conditions, medical problems, and diagnosis data elements.

CDS-S Data Elements (DE06 - Ongoing Health Conditions):

Refer to the EMR CDS-S Specification for past medical and surgical history data elements.

CDS-S Data Elements (DE07 - Past Medical & Surgical History):

Refer to the EMR CDS-S Specification for allergy and adverse reaction data elements.

CDS-S Data Elements (DE11 - Allergies & Adverse Reactions):

Refer to the EMR CDS-S Specification for family medical history data elements.

CDS-S Data Elements (DE05 - Family Medical History):

Refer to the EMR CDS-S Specification for alerts and special needs data elements.

CDS-S Data Elements (DE13 - Alerts & Special Needs):

Refer to the EMR CDS-S Specification for immunization data elements.

CDS-S Data Elements (DE08 - Immunizations):

Refer to the EMR CDS-S Specification for risk factor data elements.

CDS-S Data Elements (DE12 - Risk Factors):

Refer to the EMR Chronic Disease Management Specification for chronic disease data elements. Refer to the EMR CDS-S Specification for generic care data elements.

CDS-S Data Elements (DE16 - Care Elements, Generic Vitals):

Must maintain the name of the preventive care/screening activity and the date it was performed. Additional fields (such as due dates, notes, etc.) are allowed. Preventive care and screening activities include (but are not limited to):

• Annual Physical exam
• Influenza immunization
• Mammography screening
• Colorectal cancer screening
• Pap Smear
• Obesity screening
• Tobacco use screening
• Pre-natal checkup

Cannot be a work queue item. Must be visible within the EMR Offering. Can be for any health maintenance activity.

The intent of the requirement is to ensure accurate information informs care decisions and changes to the medical record are documented. Any information modified within the medical record MUST be available for review. The record MUST also indicate who made the change, and when the change was made. This may be available within the EMR Offering audit trail. The EMR vendor is required to conform to all subsequent releases of the CPSO Medical Records Policy. Refer to the “CPSO Policies - Medical Records” in the Related Documents section.

At a minimum, the ability to know the status of past EMR data applies to the following data categories:

• a) Ongoing Health Conditions data
• b) Past Medical and Surgical History data
• c) Allergy and Adverse Reaction data
• d) Family Medical History data
• e) Alerts and Special Needs data
• f) Immunization data
• g) Risk Factors data
• h) Care Elements data

The EMR user MUST be able to identify which information was known at the time a medical decision was made. Searching through the audit trail in order to find the status of patient data on a particular date DOES NOT satisfy the requirement.

Immunization Summary is meant to reproduce the information which would be on the Ontario Immunization Record (Yellow Card) and should be consistent with the content. Immunization Summary includes:

• a) Patient Name
• b) Patient Date of Birth
• c) Patient HCN
• d) Complete list of Patient’s Immunizations
• e) Immunization Date
• f) Name of the Primary Physician

Primary Physician: In this context, it is the name of the physician accountable for administering the specific vaccine(s) listed in the summary. As such, there may be more than one physician’s name listed if the patient had vaccinations administered by different physicians.

The EMR user should not be forced to re-enter data. Requiring the EMR user to re-enter immunization data to maintain Preventive Care, Chronic Disease Management, Reporting of Diabetes, or any other current requirements involving immunization data is not an acceptable solution.

No specific guidelines provided in the OntarioMD specification.

Refer to the EMR CDS-S Specification for medication data elements. The prescription record provides the ability to identify if a medication was/is prescribed by both an internal and external physician, such as a specialist, including first and last name. Prescriptions may be either new or a record of a past prescription.

CDS-S Data Elements (DE09 - Medications):

It is important to distinguish that there is a difference between the status of medication in the treatment plan and the status of a prescription for that medication.

The EMR Offering MUST also have the capability to add the drug to the medications list for the patient.

EMR Offering to allow the creation of the EMR user’s pre-defined list based on physician or condition.

Printed prescription MUST be able to include:

• a) Physician information (name, address, phone number)
• b) Patient information (name, address, phone number)
• c) Name of medication
• d) Strength and strength unit
• e) Form
• f) Dosage
• g) Frequency
• h) Duration and/or quantity
• i) Refills
• j) Refill duration and/or refill quantity
• k) Start date
• l) Notes to pharmacist

It is acceptable that prescriptions are printed on a standard 8.5 x 11 sheet of paper. If the prescription spans multiple pages, all demographic info and signatures MUST be repeated. Multiple prescriptions can be printed on a single form. The EMR Offering MUST identify each user and the timestamp for each time the prescription is printed/re-printed. Accessing the audit log for this information is not an acceptable solution.

This decision support tool MUST be a publicly available, commercial off-the-shelf (COTS) drug database. A drug interaction database that is current MUST be used.

This decision support tool MUST be a publicly available, commercial off-the-shelf (COTS) drug database. A drug interaction database that is current MUST be used.

This decision support tool MUST be a publicly available, commercial off-the-shelf (COTS) drug database. A drug interaction database that is current MUST be used. One or more of the:

• a) Drug/condition interactions
• b) Drug/lab interactions
• c) Recommended dosing
• d) Therapeutic alternatives

The EMR Offering MUST have the ability to set the threshold for the display of medication alerts at the EMR user (physician) level. Settings made at the physician level MUST supersede settings made at the organization level.

Additional example workflows may include:

• a) After the first time, a warning is presented to an EMR user, the EMR user should be provided with the option to default to “managed” that particular warning in subsequent viewings.
• b) If a previously managed alert does not display, in the situation where medication information in the interaction database or the condition of the patient is updated, alerts previously defaulted to “managed” will retrigger.

The EMR Offering MUST have the ability to set the threshold for the display of medication alerts at the organization level.

Additional example workflows may include: If a previously managed alert does not display, in the situation where medication information in the interaction database or the condition of the patient is updated, alerts previously defaulted to “managed” will retrigger.

The EMR Offering MUST have the ability to set the display of medication alerts per patient, or per physician. Settings made per patient, or physician MUST supersede settings made at the physician or organization level.

Additional example workflows may include: If a previously managed alert does not display, in the situation where medication information in the interaction database or the condition of the patient is updated, alerts previously defaulted to “managed” will retrigger.

The purpose of this requirement is to assist physicians in organizing the view of medication information for a particular patient. To maintain an accurate view of a patient’s medication treatment plan, the ability to display current medications, rather than a chronological list of medication prescribing activities is essential. Current medications and historical medications do not have to be separate screens, as long as the current medications are grouped, displayed, and identified as current. Provide views for current and past treatment plans showing drug name, and prescription date at a minimum. The CPSO Medical Records Policy requires the ability to display at minimum a list of the chronic medications in the patient’s treatment plan.

At a minimum, medication name, dosage, and start date MUST be displayed. The EMR user MUST be able to select any medication in the patient’s medication list. Information MUST be printable. Printed information MUST include all data elements referenced in the requirement.

At a minimum, the date of last update information MUST be viewable from within the medication module of the EMR Offering (e.g., from a menu item accessible from the medications module). It is strongly recommended this date is included within a centralized source of dates and licensing information. EMR user is not required to have administrative permissions to view the date of the last update.

It is acceptable for vendors to notify and provide access to updates for customers to update their on-site EMR Offerings.

Refer to the EMR CDS-S Specification for medication data elements.

Refer to the EMR CDS-S Specification for laboratory test data elements.

CDS-S Data Elements (DE10 - Laboratory Test Results):

New test reports are considered to be those that the clinician has received and has not yet opened and/or viewed. At a minimum, the functionality MUST be available to:

• a) The ordering physician
• b) Copied-to physician(s)

At a minimum:

• a) Test Reports MUST display an “abnormal” flag without opening the actual result
• b) Test Reports need to be “sortable” such that after being sorted, abnormal lab reports appear at the top of the list

No specific guidelines provided in the OntarioMD specification.

The graph MUST show:

• a) Test Name
• b) Test Result Value
• c) Reference Ranges
• d) Collection Date (if available)

Scales MUST be appropriate to the data. The graph MUST be printable. The printed graph MUST include all data elements referenced in the requirement.

The use of mouse hovering or tool tips do not meet the requirement. The printed graph MUST include all data elements referenced in the requirement.

The table MUST show:

• a) Test Name(s)
• b) Test Results Values
• c) Collection Date (if available)

The table MUST be printable. The printed table MUST include all data elements referenced in the requirement.

A lab summary is a printed summary of Test Results in tabular or graphical format, grouped by Test Name. An explanation can be provided via the physician appending notes through the EMR Offering, or via templates that are specific to the Test Names on the lab summary.

EMR Offering MUST provide a visually distinct indication of abnormal scanned laboratory reports through a physician work queue and the patient chart.

These are free-form text notes added by the physician at the overall Test Report level and Test Result level (refer to Core Data Set Standard Data Element “DE10.017 – Physician Notes”).

The EMR user MUST be able to simultaneously view and compare the ordered and received lists of laboratory tests. Reconciliation may be automatic, manual, or a combination of both. Some lab orders may exist without matched results (i.e., the patient did not go to a lab). The EMR Offering MUST provide the ability to remove an order from the reconciliation list if desired.

Relates to any laboratory tests results received by the EMR Offering:

• a) Through an interface
• b) Scanned into the EMR Offering or,
• c) Manually entered

Mapping of test codes to test names in the EMR Offering may be provided by the EMR vendor, or the EMR Offering MUST provide the ability for an EMR user to perform this mapping manually.

Refer to the “OLIS Nomenclatures” in the Related Documents section.

The EMR Offering MUST support checking off appropriate boxes, as well as adding text entries within the appropriate sections of the standard form. The creation of the lab requisition form within the EMR Offering does not require a preview of the completed form, but the requested tests and the date/time of the lab requisition order MUST be maintained within the EMR Offering. The clinician’s (e.g., physician’s, nurse practitioner’s) signature is still required on the completed (printed) form. Standard laboratory requisition forms may be updated at MOH discretion and EMR Offerings are required to conform to the most recent update. Refer to the “Laboratory Requisition” in the Related Documents section for the most current laboratory requisition form available.

The laboratory requisition form may be updated at the MOH’s discretion. EMR Offerings are required to conform to the most recent update. Refer to the “Laboratory Requisition” in the Related Documents section for the most current laboratory requisition form available.

The lab result needs to be received and associated with a patient record without the manual or automated creation of a lab requisition.

The default view is the most recent report received in the patient chart. The EMR user MUST be able to identify the annotations related to any Test Reports and Test Results, both partials and final.

Refer to the EMR CDS-S Specification for report data elements. Relates to any external document received by the EMR Offering:

• a) Through an interface
• b) Scanned into the EMR Offering

Copying and pasting the text from the original document into the EMR would not meet the requirement.

CDS-S Data Elements (DE14 - Reports Received):

Patient documents stored within the EMR Offering MUST be viewable within the patient record, even if not yet viewed or signed off by the responsible physician.

At a minimum, the CPP displays the following categories:

• a) Ongoing Health Conditions
• b) Past Medical and Surgical History
• c) Family Medical History
• d) Immunization Summary
• e) Allergies and Adverse Reactions
• f) Medication Summary
• g) Risk Factors
• h) Medical Alerts and Special Needs

Refer to requirements PC07.02 through PC07.08 regarding CPP categories. Refer to the “CPSO Policies - Medical Records” for information about the CPP.

Referenced also as ongoing (current) Health Condition or Diagnosis List.

No specific guidelines provided in the OntarioMD specification.

No specific guidelines provided in the OntarioMD specification.

No specific guidelines provided in the OntarioMD specification.

Can display an ongoing medication treatment plan as the default. Can also include current acute medications.

No specific guidelines provided in the OntarioMD specification.

No specific guidelines provided in the OntarioMD specification.

The EMR user MUST be able to order the list in any way they choose for each CPP category for a patient:

• a) Ongoing Health Conditions
• b) Past Medical and Surgical History
• c) Family History
• d) Allergies and Adverse Reactions
• e) Medication Summary
• f) Risk Factors
• g) Medical Alerts and Special Needs

Allowing the EMR user to only sort the items alphabetically will not satisfy the requirement. Re-ordered items should be maintained on the patient CPP in subsequent logins.

At a minimum, Medications and Ongoing Health Conditions (problems, diagnoses) can be selected and managed from the encounter note to update the CPP.

At a minimum, the EMR user MUST be able to:

• a) Add and remove CPP categories for display
• b) Add and remove discrete data information to display within the CPP categories

Customizations can be made at the EMR user level. Customizations made MUST be maintained in subsequent logins by the EMR user.

Accepted solutions include (but are not limited to): Resizing CPP categories to optimize data display and scrolling. Any customizations MUST be maintained in subsequent logins by the EMR user.

Sections of the CPP MUST be identifiable within the printed document. The printed document MAY exceed one page.

Examples: SOAP (Subjective, Objective Assessment Plan), Annual Physical, Ante-natal, etc.

The following would NOT meet the requirement:

• a) Manual entry of identification (e.g., initials)
• b) Comparing encounter note versions to identify what information was entered by an EMR user
• c) Requiring the EMR user to access audit logs to view entry information

Allowing the EMR user to toggle identifying information within the encounter note view is acceptable if the identifier information can be retrieved.

No specific guidelines provided in the OntarioMD specification.

Based on Ontario Regulation 114/94, Section 20 (4).

At a minimum, the EMR user should be able to select both a start date (day, month, year) and an end date for the date range to satisfy this requirement.

Whether the EMR Offering supports free text, coding, or other data discipline of entering and capturing multiple diagnoses within an encounter note, each method should discretely capture diagnoses at the physician’s discretion.

Allow for a logical grouping of encounter documentation that indicates multiple activities within a single office visit.

Refer to the EMR CDS-S Standard Specification for appointment data elements.

CDS-S Data Elements (DE15 - Appointments):

No specific guidelines provided in the OntarioMD specification.

At a minimum, the two elements that can be transferred from the scheduling MUST be:

• a) The patient’s HCN
• b) Service date

No specific guidelines provided in the OntarioMD specification.

MUST display two or more physicians per screen. Appointment dates and times are synchronized on the screen when scrolling.

MUST be an online function, not a report.

No specific guidelines provided in the OntarioMD specification.

The day-sheet should be in ascending order (i.e., the earliest time should appear at the top of the sheet).

No specific guidelines provided in the OntarioMD specification.

No specific guidelines provided in the OntarioMD specification.

Ad hoc double booking does not meet the requirement. MUST be:

• a) Visually distinct
• b) Preplanned and configured
• c) Able to search for the next available slot or overbooking occurs only after the planned period is full

Ability to book an appointment that overlaps with another appointment(s), without needing to configure the schedule.

Showing only the patient name on-screen without patient data is acceptable. Displaying patient data when hovering over appointments is not acceptable. The EMR user MUST be able to toggle between displaying and hiding patient data viewable in the schedule.

Can be cut and pasted, or any other means of rescheduling without a delete and add process.

The EMR Offering MAY have pre-defined status definitions or allow for EMR user-defined status.

No specific guidelines provided in the OntarioMD specification.

The view includes both past and future appointments.

The letter templates MUST:

• a) Integrate patient demographics (i.e., name, age, DOB, gender, HCN, patient contact information) from the EMR Offering
• b) Include the physician’s letterhead and contact information
• c) Referring physician’s name and contact information
• d) Integrate clinical data from the patient record as selected by the physician including:
  • CPP data
  • Lab Test Reports / Test Results
  • Progress notes (encounter notes)
  • Consultation notes (received)
  • External reports (e.g., diagnostic images)
  • Be able to be edited to provide letter-specific content

Letters generated from the template MUST be:

• a) Saved in their original form
• b) The date saved is the date the letter was generated
• c) Updates made to the patient medical data after letter generation MUST not affect and update the saved letter

Reminders MUST:

• a) Be visually distinct
• b) Be in the patient record
• c) Identify referral physician
• d) Be turned off at EMR user discretion

For this requirement to be met, this MUST be EMR user-administered and does not require an EMR vendor to attend the process. MUST be able to print information for a single patient record. See “CPSO Policies - Medical Records” in the Related Documents section.

The EMR user MUST be able to set up and maintain the following parameters for the target populations:

• a) Enrolment status
• b) Age
• c) Gender
• d) Procedure/vaccination timeline
• e) Exclusion codes

The parameters applicable MUST be adjustable and saved:

• a) On a fiscal year basis for Cumulative Bonus Reports
• b) On a real-time basis for Patient Recall List

Hard coding the parameters would not satisfy this requirement. Service Enhancement Codes are set by the MOH for applicable Physician Group Agreements. See the OHIP Bulletins and MOH guidelines.

Patient Recall List MUST include/indicate:

• a) Target population
• b) The physician to whom the patient is enroled
• c) Patient information (name, HCN, age, gender, phone number, address)
• d) Guardian information (name, phone number, and address) for Childhood Immunizations
• e) Whether the patient is entitled to receive the first letter, second letter or phone call
• f) Last procedure date
• g) Last date of communication (printed letters or phone call)

The Patient Recall List is a real-time report. Updates to patient data, report parameters, and letter generation MUST be automatically reflected in the Patient Recall List report. Requiring the EMR user to re-enter any information (e.g., Demographic and EMR information) already in the EMR Offering would not satisfy the requirement. Service Enhancement Codes are set by the MOH for applicable Physician Group Agreements. See the OHIP Bulletins and MOH guidelines.

At a minimum, the EMR Offering MUST be able to:

• a) Generate the letters in a batch and individually (both MUST be supported)
• b) Generate the letters without requiring the EMR user to do another patient lookup
• c) Save records of all correspondence including dates of delivery of the written notices

Letters MUST meet requirements listed in the MOH Service Enhancement Codes Primary Care Agreements:

• a) Indicate whether it is the first or second written notice
• b) Indicate the procedure type, benefits and the date of the last procedure
• c) The name and address of the patient or guardian (for Childhood Immunizations)
• d) Physician letterhead and information (name, address, phone number)

Cumulative Bonus report MUST include/indicate:

• a) The target population
• b) The physician to whom the patient is enroled
• c) Patient information (name, HCN, age, gender)
• d) Last procedure date
• e) Whether the eligible patients for the selected fiscal year have received the procedure or not
• f) Percentage of patients who have received the procedure from the target population

The Cumulative Bonus Report is a real-time report. Updates to patient data, report parameters, and letter generation MUST be automatically reflected in the Cumulative Bonus report. Reports can be generated for each fiscal year. Requiring the EMR user to re-enter any information (e.g., Demographic and EMR information) already in the EMR Offering would not satisfy the requirement. Service Enhancement Codes are set by the MOH for applicable Physician Group Agreements. See the OHIP Bulletins and MOH guidelines.

The EMR user MUST be able to create the query and run the report and does not require an EMR vendor to attend the process. Any discrete data field specification requirements satisfied by the EMR Offering can be selected for report parameters. At a minimum, ad hoc reporting functionality should allow for the selection of reported fields and allow for filtering based on “AND”, “OR”, and “NOT” logic. Ad hoc query facility supports Boolean search capabilities. The tool MUST be user-friendly.

A spell checker is not sufficient. Examples:

• a) Coding schemas
• b) Drop-down lists, etc.

Text fields include any free-form text or notes fields. Able to search within text fields for partial matches.

Image data is not required.

Able to search within text fields for partial matches. Image data is not required.

No specific guidelines provided in the OntarioMD specification.

To satisfy this requirement the physician MUST be able to define the name and population of their cohort(s). The physician MUST be able to add a population of patients individually or in bulk to the cohort. Each patient in the EMR Offering can belong to more than one cohort if desired by the physician.

Report indicates:

• a) Physician for whom the report is being generated
• b) Date range of report
• c) Practice profile information
• d) Metrics for the patients rostered to physician:
  • i) scheduled appointments
  • ii) billing (OHIP, WSIB, private, uninsured)
  • iii) encounter notes created
  • iv) problems entered in the Ongoing Health Condition list
  • v) stored documents (including scanned documents or external documents received from an interface)
  • vi) new and renewed prescriptions
  • vii) lab test results received electronically
  • viii) alerts/reminders generated

Refer to section 3.1 - EMR Usage Metrics Report (Req # PC11.13) - Sample.

EMR Offering MUST provide the ability to open the patient record in a single action.

Priority can be indicated by urgent, low, etc., or a priority checkbox.

No specific guidelines provided in the OntarioMD specification.

Laboratory Test Report/Result can be opened from the task. Assigned the EMR user’s access to lab information MUST follow appropriate security permissions for that EMR user.

Document records can be opened from the task. Assigned EMR user’s access to documents MUST follow appropriate security permissions for that EMR user.

No specific guidelines provided in the OntarioMD specification.

No specific guidelines provided in the OntarioMD specification.

No specific guidelines provided in the OntarioMD specification.

Storing this information only in the audit log is not acceptable.

Work queues can be customized by roles such as nursing, physicians, receptionists, etc.

At a minimum, the following tasks MUST be automatically generated:

• a) Outstanding lab requests, and other tests (e.g., Diagnostic Imaging)
• b) Appointment reminders

This requirement does not include preventive care (e.g., preventive care reminders). The requirement is not met if an EMR user only accesses the patient chart in order to see the task. The EMR Offering allows the ability to turn off this functionality for each type of task.

Running a query to generate tasks on all applicable records is acceptable. The EMR user should be able to assign/redirect tasks to a particular EMR user or role. The EMR user should be able to turn off this functionality. See the OHIP Bulletins and MOH guidelines.

This applies to all patient information (i.e., reports) that require sign-off such as:

• a) Reports received through an interface
• b) Reports scanned into the EMR Offering
• c) Reports manually keyed

A mandatory concurrent entry MUST be present in the physician’s “inbox” for sign-off.

At a minimum, sign-off should be available for:

• a) Encounter documentation
• b) Reports
  • Received through an interface
  • Scanned into the EMR Offering
  • Manually keyed into the EMR Offering

Sign-off information (including sign-off date and identity of the physician) MUST be:

• a) Visible in the patient’s chart
• b) Captured in the audit log

The trainee is not necessarily a physician – may be a nursing student, etc.

This applies to any patient information that requires physician sign-off such as:

• a) Encounter documentation
• b) Reports
  • Received through an interface
  • Scanned into the EMR Offering
  • Manually keyed into the EMR Offering

Sign-off information (including sign-off date and identity of the physician) MUST be:

• a) Visible in the patient’s chart
• b) Captured in the audit log

Only 1 copy of the report is posted to the patient’s chart.

This applies to all patient information signed off, such as:

• a) Reports received through an interface
• b) Reports scanned into the EMR Offering
• c) Reports manually keyed

In addition, provides the ability to search and review items that were signed off on a particular date or date range per EMR user. This is not an undo function, but rather the ability to display (return to) previously viewed patient information without requiring the EMR user to recall patient demographic details.

See the OHIP Bulletins and MOH guidelines.

At a minimum, the basic error checking to be provided when:

Registering patients:

• a) Ontario HCN - check digit
• b) HCN duplicate

Edits for all mandatory billing fields:

• a) Service date
• b) Physician number
• c) HCN
• d) Name
• e) Date of Birth (DOB)
• f) Gender
• g) Fee code and fee claimed
• h) Checks all dates are valid dates and in the past

The reconciliation reports can be either the entire MRO data file or include the MOH-defined data fields, based on their MRO record type. Supports the resubmission of rejected claims without the need to re-enter data. See the OHIP Bulletins and MOH guidelines.

The EMR Offering MUST:

• a) Notify of version code discrepancies, and
• b) Upon EMR user request, automatically update the patient record with demographic data associated with the HCN:
  • Name
  • Gender
  • DOB

No specific guidelines provided in the OntarioMD specification.

MUST transfer all pertinent billing data that is present in the clinical record. Pertinent data includes, but is not limited to:

• a) Patient information
• b) Physician information
• c) Service date
• d) Procedure code
• e) Diagnosis code
• f) Location
• g) Clinic/hospital number

Diagnosis code information comes from the patient’s EMR data and is not manually entered by the EMR user.

No specific guidelines provided in the OntarioMD specification.

The list MUST indicate:

• a) Patient ID
• b) Service provided
• c) Service date
• d) Outstanding amount

Any ageing buckets are acceptable. Can be any report to manage outstanding claims.

No specific guidelines provided in the OntarioMD specification.

Prior fee schedule information may be required for resubmission purposes.

No specific guidelines provided in the OntarioMD specification.

The EMR user MUST take some action to remove unbilled appointments from the list. Deleting appointments does not meet the requirement.

Able to be generated on demand. At a minimum, the third-party billings with invoices MUST include:

• a) Physician name
• b) Patient name or ID
• c) Payor address
• d) Service date
• e) Service
• f) Itemized amount(s)
• g) Total amount billed

Able to be generated on demand. At a minimum, the third-party billings with statements MUST include:

• a) Physician name
• b) Patient name or ID
• c) Payor address
• d) Service date
• e) Service
• f) Itemized amount(s) amount paid
• g) Balance

Receipts are not sufficient.

OHIP claim # is assigned by the OHIP claims payment system. Accounting # is assigned by EMR Offering or EMR user to a claim.

Refer to the “OHIP Fee Schedule Master” in the Related Documents section.

At a minimum, notifications MUST be provided for:

• a) Updated Fees
• b) Updated Effective Date
• c) Updated Expiration Date
• d) New billing codes

OMA services and third-party suggested fees for uninsured services can be accessed from scheduling and billing modules, and the patient’s medical record. Refer to “Physician’s Guide to Third-Party and Other Uninsured Services” published by the OMA for a list of suggested fees for uninsured services and third-party services.

A “write-off” implies an uncollectable amount. These amounts should be coded and treated as such. An “error” is an honest error and should be treated as such. Write-offs and errors should be associated with a reason code/reason description. Report(s) that show write-offs and error corrections should show each.

It is recommended to maintain records for a minimum of 15 years. Refer to the “CPSO Policies - Medical Records” in the Related Documents section.

This standard may be updated by MOH.

The vendor MUST provide substantiation that databases with inherent limitations, such as MSDE or MS Access, can meet this requirement.

Based on Ontario Regulation 114/94, Section 20 (7). Back-up can be full or incremental, etc. Recovery can be to the last backup, point of failure, etc.

Refer to the external documentation described in section 2.6 External Document Management. A solution that stores documents in the file system (server or client) only does not satisfy the requirement.

A solution that only encrypts data as it is transmitted over the network does not satisfy the requirement.

Server hardening consists of creating a baseline for the security of the application server. Threats to Personal Health Information breaches via external access are greatly reduced by eliminating entry points and minimizing system software. Physical security is elevated when all application data and information is encrypted. This guideline does not apply to Hosted EMR Offerings. Refer to the “Server Hardening Checklist” in the Related Documents section.

The vendor MUST recommend to physicians an anti-malware solution that does not negatively impact the EMR Offering and that both solutions can co-exist on the same server without creating any conflicts.

No specific guidelines provided in the OntarioMD specification.

No specific guidelines provided in the OntarioMD specification.

To satisfy this requirement, the EMR vendor MUST be able to provide support by viewing the EMR user interface without physically being at a site, provided appropriate consent has been given to the EMR vendor to do so. Considerations MUST be made for the privacy and security of Personal Health Information.

To satisfy this requirement, the EMR vendor MUST be able to:

• a) Push updates and administrator to download, accept and execute
• b) Schedule a time with the user and make updates remotely

The documentation MUST be comprehensive of all available EMR functionality. To satisfy this requirement, documentation MUST either be distributed to or made available for download by customers. The document MUST be searchable.

Help MUST be invoked from within the EMR user interface and specific to the screen, function, or function groups being used. The use of tooltips to provide a brief description of a function does not satisfy this requirement. Opening up the entire training document and searching does not satisfy this requirement.

At a minimum, training MUST be offered on all functionalities described in this specification.

Refer to the “Technical Specifications – Interface to Health Care Systems” in the Related Documents section.

For this requirement to be met, the EMR vendor MUST obtain a letter certifying the successful interface. The letter MUST be dated within the previous twelve (12) months.

Refer to the Health Card Validation Reference Manual.

The EMR vendor MUST provide either:

• a) a current ISO 13485 certificate, or
• b) a current ISO 9001 certificate + provide an excerpt of the audited quality documentation (e.g., quality manual) that demonstrates the concept of patient safety (i.e., patients’ freedom from unacceptable risk) was included in the description of:
  • i) the needs and expectations of interested parties (ISO 9001:2015 Requirement 4.2) and
  • ii) the scope of the quality management system (ISO 9001:2015 Requirement 4.3).