Clinical Decision Rules

MU Requirements

Meaningful Use Measures:

Implement 5 clinical decision support rules relevant to the clinical quality metrics the EP is responsible for as described further in section II(A)(3).

Certification Criteria for EHR:

1. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drug-allergy contraindication checking) according to specialty or clinical priorities that use demographic data, specific patient diagnoses, conditions, diagnostic test results and/or patient medication list.

2. Automatically and electronically generate and indicate (e.g., pop-up message or sound) in realtime, alerts and care suggestions based upon clinical decision support rules and evidence grade.

3. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user.

From CCHIT:

1. AM 35.01 The system shall provide the ability to update the clinical content or rules utilized to generate clinical decision support reminders and alerts. "Growth charts, CPT-4 codes, drug interactions would be an example. Any method of updating would be acceptable. Content could be third party or customer created."

2. AM 23.09 The system shall provide the ability to automatically generate reminder letters for patients who are due or are overdue for disease management, preventive or wellness services. "The term 'automatically' means that the system is able to generate patient recalls for all due or overdue reminders for an individual patient based on the current date, regardless of whether a user initiates this action, or if the action is triggered by pre-set parameters in the system. An example would be generating a letter to all patients overdue for a screening mammography. It is acceptable if the output allows generation of letters, such as a mail merge file."

See Patient Reminders for specifications.

Summary for the Clinical Decision Rule Engine

Engine by Brady Miller, summary by Aron Racho

In clinical_rules.php, function test_rules_clinic() collects either all a provider's patients, a specific patient, or all the patients in the clinic, then iterates through each rule (from table clinical_rules) for each patients, checking whether or not the rule applies to that patient.

The way it does that is that it uses the function test_targets() is what retrieves the data in openemr tables/columns relevant to the rule being tested and the patient. It ends up checking table rule_target.value for the expression relating to the openemr table. For example:

   ::immunizations::immunization_id::eq::20::ge::1

This string appears to describe that the particular rule must look into the immunizations table for the given patient to see whether or not the rule applies.

test_rules_clinic() is used in places such as the patient reminders widget and the cqm report. The patient reminders widget (from the demographics page) uses test_rules_clinic() to determine, for the currently selected patient, which rules apply (eg. which patient needs a pap smear or new blood test today), and and persists reminders relating to these rules in table patient_reminders if they are not already persisted.

Similarly, cqm.php (the CQM report, available from the Admin -> Reports nav) uses test_rules_clinic to report on patients who need actions (eg. have triggered a rule) across the clinic.

In summary: studying the flow from update_reminders.php (which is called by the patient reminders widget) to test_rules_clinic will show you how reminders are persisted for patients. The CQM report (cqm.php) and the patient reminders widget will show you how persisted rule 'hits' per patient are consumed.

My feeling is that we will work with the messaging subsystem to surface something like what the CQM report is already doing. We could surface messages relating to the physician's particular patients.

Some Project Proposals (by brady)

Project 1: GUI to turn off/on reminder and clinical alerts for each rule. Put this in Administration folder. Basically a screen that lists the applicable rules (use function resolve_rules_sql(\'\','0',TRUE) to collect all the pertinent rules (ie. will skip cqm and amc stuff). Each applicable rule is a row in a table with three checkboxes near it (one for active alerts, passive alerts, and clinical reminders). In the future this can be expanded to the full function admin gui (project4).

Project 2: (ownership: none) GUI to turn off/on reminder alerts for each rule for a specific patient. Put this in the screen called by edit in the patient reminder widget in summary screen. Base on gui from project 1 if want. Basically a screen that lists the applicable rules (use function resolve_rules_sql('patient_reminder',$pid,TRUE) to collect all the pertinent patient specific rules and resolve_rules_sql('patient_reminder','0',TRUE) to get the default practice rules. Each applicable rule is a row in a table with one checkboxes near it (for clinical reminders) along showing the default practice setting next to this with a checkbox that states to resort to the default practice setting. Check out the table clinical_rules to see how this will be accomplished. pid table holds the $pid (note 0 is the default practice setting). So, if the user chose to go back to default, would simply drop the patient specific entry. If they modified it, then would modify (or add if not there yet) a patient specific entry in the clinical_rules table.

Project 3: GUI to turn off/on clinical alerts (top right screen) for each rule for a specific patient. Put this in the screen called by edit in the clinical alert widget (see other widget on how to add the button) in summary screen. Basically use the same gui as from project 2. Basically a screen that lists the applicable rules (use function resolve_rules_sql('passive_alert',$pid,TRUE) to collect all the pertinent patient specific rules and resolve_rules_sql('passive_alert','0',TRUE) to get the default practice rules. Each applicable rule is a row in a table with one checkboxes near it (for clinical reminders) along showing the default practice setting next to this with a checkbox that states to resort to the default practice setting. Check out the table clinical_rules to see how this will be accomplished. pid table holds the $pid (note 0 is the default practice setting). So, if the user chose to go back to default, would simply drop the patient specific entry. If they modified it, then would modify (or add if not there yet) a patient specific entry in the clinical_rules table. In the way future this can be expanded to a sophisticated place to see sets of data by plans (by grouping rules/actions etc.)

Project 4: Build a fully functional admin gui that allows making/editing new rules, filters, targets, actions. This will be a huge project and suggest doing it last.

Project 5: Get the email and voice (maviq) reminder code to work. I've refactored all of Thomas's code (except for the maviq api, which is in its original state), so at this point just need to get the email and maviq voice connectors to work. The nice thing is that this is a really isolated project. The script that does this is interface/batchcom/batch_reminders.php, which can be run in OpenMR via Adminsitration->Patient Reminders (click Send Reminders Batch button). I'm pretty clueless on how to get the maviq voice feature to work. For the email, looks like need to place some required from email fields as new settings in interface/globals.inc.php ($sender_name, $email_address, etc.). Teh really nice thing about this project is that the reminder sql table and data (self-populated whenever a new patient is made) already exist; very self-explanatory if look at the current scripting in interface/batchcom/batch_reminders.php and the patient_reminders sql table.

Project 6: Get the CQM report to output the file that needs to be submitted (some XML thing) and ensure we get all items for MU. The CQM report is at Reports->Clinical->Quality Measures. Simply need to put a button on this page that will export the data to an xml (following mu standards). Then can also research and figure out what exactly needs to go into that report which is missing (such as number exlusions etc.).

Original Proposed Solution

• Parts of this plan are deprecated, but the information is still relevant --Tony - www.mi-squared.com 19:09, 21 December 2010 (UTC)

1. Create a health plan management system for adding health maintenance (preventive services), disease management, and wellness plans.

2. The provider can assign any health plan to any patient. Here are some of the pre-built health plans:

3. The provider can also do a group assignment by rule, e.g. all women between 30 and 50 years old.

4. CKEditor or Word (MS/OpenOffice) will be integrated for managing the email and letter templates.

5. Create a rule-based patient alert system for #1. The alerts are for screen display.

Effected Code, Tables, etc

1. Here's a proposal on the tables needed:

Proposed CDR Tables

In addition to meeting the MU requirements here, we also take into consideration of the CMS Quality Reporting MU requirements.

Owner and Status

Consortium of: Brady Miller, Medical Information Integration, LLC and EnSoftek, LLC Brady has been working on the low level design MI2 and Ensoftek launch collaborative development starting 12/11/2010.

• Original design and work done as of 2/4/2010: was rejected as not robust enough

Links

• CCHIT_MU_2011_Project
• OpenEMR Office Visit Workflow
• U.S. Preventive Services Task Force: http://www.ahrq.gov/CLINIC/uspstfix.htm
• Associated with Sourceforge forum thread: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3494342
• Associated with Sourceforge forum thread: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3531568 (although this is a clinical reminder thread, there is discussion here related to clinical decision rules, health plans, and clinical alerts)
• Associated with Sourceforge forum thread: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/1395321 (an older thread on this topic, although recently with some relevant information added)