Difference between revisions of "Clinical Decision Rules"

From OpenEMR Project Wiki
(16 intermediate revisions by the same user not shown)
Line 24: Line 24:
See [[Patient Reminders]] for specifications.
See [[Patient Reminders]] for specifications.


=Summary for the Clinical Decision Rule Engine=
==Summary for the Clinical Decision Rule Engine==


Engine by Brady Miller, summary by Aron Racho
Engine by Brady Miller, summary by Aron Racho
Line 42: Line 42:
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.
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 Overview==


'''Project 1:''' <span style="color:red;"><b>(ownership: none)</b></span> 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 1:'''  
* [[CDR Activation Manager]] - Functional Spec for GUI w/ screen mock ups:  <span style="color:blue;"><b>(ownership: MI2)</b></span> - Target Date: 12-29
* Code Dev and QA: <span style="color:blue;"><b>(ownership: EnSofttek/MI2)</b></span>


'''Project 2:''' <span style="color:red;"><b>(ownership: none)</b></span> 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
'''Project 2:'''  
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.
* [[Patient Reminder Alert Manager]] - Functional Spec for GUI w/ screen mock ups:  <span style="color:blue;"><b>(ownership: MI2)</b></span> - Target Date: 12-29
* Code Dev and QA: <span style="color:blue;"><b>(ownership: EnSofttek/MI2)</b></span>


'''Project 3:''' <span style="color:red;"><b>(ownership: none)</b></span> 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 3:'''  
* [[Patient Clinical Alerts Manager]] - Functional Spec for GUI w/ screen mock ups:  <span style="color:blue;"><b>(ownership: MI2)</b></span> - Target Date: 12-29
* Code Dev and QA: <span style="color:blue;"><b>(ownership: EnSofttek/MI2)</b></span>


'''Project 4:''' <span style="color:red;"><b>(ownership: none)</b></span> 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 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.
* Research and document specifics on how the list_options items are used by the CDR Engine: <span style="color:blue;"><b>(ownership: EnSofttek/MI2)</b></span> Target: 12/31
* Functional Spec w/ screen mock ups:  <span style="color:blue;"><b>(ownership: MI2)</b></span> - Target Date: 01/09/2011


'''Project 5:''' <span style="color:red;"><b>(ownership: none)</b></span> 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,
'''Project 5:''' <span style="color:red;"><b>(ownership: none)</b></span> 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,
Line 59: Line 66:
which is missing (such as number exlusions etc.).
which is missing (such as number exlusions etc.).


'''Project 7:''' <span style="color:red;"><b>(ownership: bradymiller)</b></span> Get the Automated Measure Calculations functional. The skeleton rules and report are entered in, but not functional. Will likely need to incorporate a date range (rather than a target range) for this feature. Then will simply be a matter of working out the rules.
'''Project 7:''' <span style="color:blue;"><b>(ownership: bradymiller)</b></span> Get the Automated Measure Calculations functional. The skeleton rules and report are entered in, but not functional. Will likely need to incorporate a date range (rather than a target range) for this feature. Then will simply be a matter of working out the rules.


'''Project 8:''' <span style="color:red;"><b>(ownership: bradymiller)</b></span> Get the Clinical Quality Measures functional. The skeleton rules and report are entered in, but not functional. These are all rather complicated rule sets for each quality measure, so will likely require some customized functions (called by rule engine) to deal with some of these (to avoid overburdening the core rules engines with a bunch of confusing implementations).
'''Project 8:''' <span style="color:blue;"><b>(ownership: bradymiller)</b></span> Get the Clinical Quality Measures functional. The skeleton rules and report are entered in, but not functional. These are all rather complicated rule sets for each quality measure, so will likely require some customized functions (called by rule engine) to deal with some of these (to avoid overburdening the core rules engines with a bunch of confusing implementations).


==Original Proposed Solution==
== Notes and Issues==
Please add your issues, comments and suggestions and rember to use the 'signature' tag to sign and date the entry.


:*Parts of this plan are deprecated, but the information is still relevant --[[User:Tmccormi|Tony - www.mi-squared.com]] 19:09, 21 December 2010 (UTC)
# Permissions levels for each part of the process need to be clearly defined --[[User:Tmccormi|Tony - www.mi-squared.com]] 00:26, 30 December 2010 (UTC)
 
Agreed, need to ensure basic acl's are set up (for now, only people that are allowed to see clinical stuff on patient should be able to see these widgets in the patient sumamry screen. --[[User:Bradymiller|Bradymiller]] 19:12, 31 December 2010 (UTC)
1. Create a health plan management system for adding health maintenance (preventive services), disease management, and wellness plans.
# Patient Reminders work list may be better in Miscellaneous than administration. It is similar in function to 'BatchCom' for patient communications. --[[User:Tmccormi|Tony - www.mi-squared.com]] 00:26, 30 December 2010 (UTC)
 
After all the pieces and links are in place, then would start thinking about the best place to put them. --[[User:Bradymiller|Bradymiller]] 19:12, 31 December 2010 (UTC)
[[File:CDS_Admin_Plan1.png]]
# On patient summary/demographic.php the patient reminders and clinical reminders widgets contain the nearly same information in different sort orders.  Is in necessary to have two widgets for reminders or would we be better with one that indicates the difference between the two or combines information? --[[User:Tmccormi|Tony - www.mi-squared.com]] 00:44, 30 December 2010 (UTC)
 
Yes, it is necessary, because they do different things. The clinical reminders widget is for real time indicators (and activated by the active_alert_flag in clinical_rules mysql table). The patient reminders widget is for sending/tracking reminders to the patient (and activated by the patient_reminder_flag in clinical_rules mysql table). The same clinical_rules entry can be activated to do both (which is now set for most during development) but in real life, many of the rules will be set for only as a real time indicator or as a patient reminder; and these mechanisms will be even more powerful when the per patient customization gui's are set up. In the end, the clinical reminders widget (real time indicators) will also be the perfect place to put plan (ie. diabetes, HTN, ..) stuff (but don't want to get to far ahead of ourselves). --[[User:Bradymiller|Bradymiller]] 19:12, 31 December 2010 (UTC)
[[File:CDS_User_Plan1.png]]
 
2. The provider can assign any health plan to any patient. Here are some of the pre-built health plans:
 
[[File:CDS_5.5_Pre-Built_Health_Plans.png]]
 
3. The provider can also do a group assignment by rule, e.g. all women between 30 and 50 years old.
 
[[File:CDS_5.1_Health_Plan.png]]
 
[[File:CDS_5.2_Health_Plan.png]]
 
4. CKEditor or Word (MS/OpenOffice) will be integrated for managing the email and letter templates.  
 
[[File:CDS_CKEditor.png]]
 
5. Create a rule-based patient alert system for #1. The alerts are for screen display.  
 
[[File:CDS_5.4_System_Alert_Setup.png]]
 
[[File:CDS_Patient1.png]]


==Effected Code, Tables, etc==
==Effected Code, Tables, etc==


1. Here's a proposal on the tables needed:
In addition to meeting the MU requirements here, we also take into consideration of the CMS Quality Reporting MU requirements.


[[media:Proposed_CDR_Tables.pdf|Proposed CDR Tables]]
* Current Tables:
 
** [[CDR Rules tables]]
In addition to meeting the MU requirements here, we also take into consideration of the CMS Quality Reporting MU requirements.
** [[list_options Contents for CDR Rules]]


==Owner and Status==
==Owner and Status==
Line 110: Line 97:


==Links==
==Links==
* [[Original CDR Deprecated Proposal - Archive]]
* [[CCHIT_MU_2011_Project]]
* [[CCHIT_MU_2011_Project]]
* [[media:OpenEMR_Office_Visit_Workflow.pdf‎|OpenEMR Office Visit Workflow]]
* [[media:OpenEMR_Office_Visit_Workflow.pdf‎|OpenEMR Office Visit Workflow]]

Revision as of 19:12, 31 December 2010

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.

Project Overview

Project 1:

  • CDR Activation Manager - Functional Spec for GUI w/ screen mock ups: (ownership: MI2) - Target Date: 12-29
  • Code Dev and QA: (ownership: EnSofttek/MI2)

Project 2:

  • Patient Reminder Alert Manager - Functional Spec for GUI w/ screen mock ups: (ownership: MI2) - Target Date: 12-29
  • Code Dev and QA: (ownership: EnSofttek/MI2)

Project 3:

  • Patient Clinical Alerts Manager - Functional Spec for GUI w/ screen mock ups: (ownership: MI2) - Target Date: 12-29
  • Code Dev and QA: (ownership: EnSofttek/MI2)

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.

  • Research and document specifics on how the list_options items are used by the CDR Engine: (ownership: EnSofttek/MI2) Target: 12/31
  • Functional Spec w/ screen mock ups: (ownership: MI2) - Target Date: 01/09/2011

Project 5: (ownership: none) 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: (ownership: none) 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.).

Project 7: (ownership: bradymiller) Get the Automated Measure Calculations functional. The skeleton rules and report are entered in, but not functional. Will likely need to incorporate a date range (rather than a target range) for this feature. Then will simply be a matter of working out the rules.

Project 8: (ownership: bradymiller) Get the Clinical Quality Measures functional. The skeleton rules and report are entered in, but not functional. These are all rather complicated rule sets for each quality measure, so will likely require some customized functions (called by rule engine) to deal with some of these (to avoid overburdening the core rules engines with a bunch of confusing implementations).

Notes and Issues

Please add your issues, comments and suggestions and rember to use the 'signature' tag to sign and date the entry.

  1. Permissions levels for each part of the process need to be clearly defined --Tony - www.mi-squared.com 00:26, 30 December 2010 (UTC)

Agreed, need to ensure basic acl's are set up (for now, only people that are allowed to see clinical stuff on patient should be able to see these widgets in the patient sumamry screen. --Bradymiller 19:12, 31 December 2010 (UTC)

  1. Patient Reminders work list may be better in Miscellaneous than administration. It is similar in function to 'BatchCom' for patient communications. --Tony - www.mi-squared.com 00:26, 30 December 2010 (UTC)

After all the pieces and links are in place, then would start thinking about the best place to put them. --Bradymiller 19:12, 31 December 2010 (UTC)

  1. On patient summary/demographic.php the patient reminders and clinical reminders widgets contain the nearly same information in different sort orders. Is in necessary to have two widgets for reminders or would we be better with one that indicates the difference between the two or combines information? --Tony - www.mi-squared.com 00:44, 30 December 2010 (UTC)

Yes, it is necessary, because they do different things. The clinical reminders widget is for real time indicators (and activated by the active_alert_flag in clinical_rules mysql table). The patient reminders widget is for sending/tracking reminders to the patient (and activated by the patient_reminder_flag in clinical_rules mysql table). The same clinical_rules entry can be activated to do both (which is now set for most during development) but in real life, many of the rules will be set for only as a real time indicator or as a patient reminder; and these mechanisms will be even more powerful when the per patient customization gui's are set up. In the end, the clinical reminders widget (real time indicators) will also be the perfect place to put plan (ie. diabetes, HTN, ..) stuff (but don't want to get to far ahead of ourselves). --Bradymiller 19:12, 31 December 2010 (UTC)

Effected Code, Tables, etc

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

Retrieved from "https://www.open-emr.org/wiki/index.php?title=Clinical_Decision_Rules&oldid=5837"