Difference between revisions of "Clinical Decision Rules"

From OpenEMR Project Wiki
 
Line 82: Line 82:
::The flow of the rule engine is as follows. Lets say were looking at patient 'Bill'. We look at the first rule 'rule_A'. In 'rule_A' we first grab the associated filter set (note only one filter set per rule, for now) and test the filter set to patient 'Bill'. If Bill passes the filter set (he is now part of the group being tested), he then moves on to the next test (the target). So, we now grab the associated target set(s) for the rule 'rule_A' (note there is a mechanism for multiple target sets per rule), and test them to the patient 'Bill'. If 'Bill' does not pass the target set, then the action (associated with failed target set from 'rule_A') happens (or in the case of cqm, it is used in the calculation). To get further differentiation of filters vs targets, check out the functions test_filters() and test_targets(); note how many more features are required to be dealt with in test_filters() than test_targets().--[[User:Bradymiller|Bradymiller]] 08:08, 4 January 2011 (UTC)
::The flow of the rule engine is as follows. Lets say were looking at patient 'Bill'. We look at the first rule 'rule_A'. In 'rule_A' we first grab the associated filter set (note only one filter set per rule, for now) and test the filter set to patient 'Bill'. If Bill passes the filter set (he is now part of the group being tested), he then moves on to the next test (the target). So, we now grab the associated target set(s) for the rule 'rule_A' (note there is a mechanism for multiple target sets per rule), and test them to the patient 'Bill'. If 'Bill' does not pass the target set, then the action (associated with failed target set from 'rule_A') happens (or in the case of cqm, it is used in the calculation). To get further differentiation of filters vs targets, check out the functions test_filters() and test_targets(); note how many more features are required to be dealt with in test_filters() than test_targets().--[[User:Bradymiller|Bradymiller]] 08:08, 4 January 2011 (UTC)
::* The flow is not the actual question: '''What is a Target?''' and '''What is a Filter?'''.  How do they differ to the USER?  We are trying to create a UI that users can understand and configure, so we need clear definition of the terms themselves and how they are applied.  The flow in the code itself is fairly obvious, and not the issue at hand.  --[[User:Tmccormi|Tony - www.mi-squared.com]] 18:40, 5 January 2011 (UTC)
::* The flow is not the actual question: '''What is a Target?''' and '''What is a Filter?'''.  How do they differ to the USER?  We are trying to create a UI that users can understand and configure, so we need clear definition of the terms themselves and how they are applied.  The flow in the code itself is fairly obvious, and not the issue at hand.  --[[User:Tmccormi|Tony - www.mi-squared.com]] 18:40, 5 January 2011 (UTC)
:::The filter is to select the population that you want to run the test (ie. check for the target) on. For example, lets use a pap smear. The filter would be for woman only over a certain age. The target is the pap smear itself. This is important, because the filter defines the population of patients that are pertinent to the rule (this is used as denominator in cqm rules and in the future to auto-report results in the clinical reminder widget even if the target is true (ie. show the hgba1c result even if it is up to date)). I hope this helps.--[[User:Bradymiller|Bradymiller]] 18:55, 5 January 2011 (UTC)
:::*The filter is to select the population that you want to run the test (ie. check for the target) on. For example, lets use a pap smear. The filter would be for woman only over a certain age. The target is the pap smear itself. This is important, because the filter defines the population of patients that are pertinent to the rule (this is used as denominator in cqm rules and in the future to auto-report results in the clinical reminder widget even if the target is true (ie. show the hgba1c result even if it is up to date)). I hope this helps.--[[User:Bradymiller|Bradymiller]] 18:55, 5 January 2011 (UTC)
:5. '''We are proposing that the rule admin GUI will allow you to define, per rule, where the source of the filtering criteria. For example, rule_dm_bp_control_cqm wants to source its targets from form_vitals, bps and bpd, etc. columns. We want to present an human language 'nice title' for things like form_vitals (which really can be any developer form table, or other source such as CUSTOM:act_cat_assess). There doesn't appear to be a linkage from the rules_target or rules_filter table to any such table that could provide this friendlier name. Any suggestions on how we surface this friendlier name?'''--[[User:Aron Racho|Aron Racho]] 00:49, 4 January 2011 (UTC)
:5. '''We are proposing that the rule admin GUI will allow you to define, per rule, where the source of the filtering criteria. For example, rule_dm_bp_control_cqm wants to source its targets from form_vitals, bps and bpd, etc. columns. We want to present an human language 'nice title' for things like form_vitals (which really can be any developer form table, or other source such as CUSTOM:act_cat_assess). There doesn't appear to be a linkage from the rules_target or rules_filter table to any such table that could provide this friendlier name. Any suggestions on how we surface this friendlier name?'''--[[User:Aron Racho|Aron Racho]] 00:49, 4 January 2011 (UTC)
::Several things here. First, the actions categories (ie. act_cat_assess) do have list_options lists; for example act_act_assess is Assessment. And CUSTOM basically means the data is stored in the 'rule_patient_data' table, which in actuality is simply a garbage bin to hold data points that do not yet exist within the OpenEMR; as procedures and other openemr code is developed more for MU, less and less things will be stored in this table; nonetheless it will still always be an important mechanism that will add another nice option for customization. For example, lets say I want to track yearly fingernail length in some weirdo clinic; they could simply create the rule in the clinical rule admin GUI, use the CUSTOM method, and not need to worry about creating a sql data container or form for this information. On to the more pressing question; how to create user friendly constants (and translations) for stuff such as bps form_vitals etc. This is actual gonna be quite simple, since the actual number of terms that are used is not that big, and can be added to as more places in the database are used. Basically a simple list_options list(s) will suffice and can be done as building the admin gui.--[[User:Bradymiller|Bradymiller]] 08:22, 4 January 2011 (UTC)
::Several things here. First, the actions categories (ie. act_cat_assess) do have list_options lists; for example act_act_assess is Assessment. And CUSTOM basically means the data is stored in the 'rule_patient_data' table, which in actuality is simply a garbage bin to hold data points that do not yet exist within the OpenEMR; as procedures and other openemr code is developed more for MU, less and less things will be stored in this table; nonetheless it will still always be an important mechanism that will add another nice option for customization. For example, lets say I want to track yearly fingernail length in some weirdo clinic; they could simply create the rule in the clinical rule admin GUI, use the CUSTOM method, and not need to worry about creating a sql data container or form for this information. On to the more pressing question; how to create user friendly constants (and translations) for stuff such as bps form_vitals etc. This is actual gonna be quite simple, since the actual number of terms that are used is not that big, and can be added to as more places in the database are used. Basically a simple list_options list(s) will suffice and can be done as building the admin gui.--[[User:Bradymiller|Bradymiller]] 08:22, 4 January 2011 (UTC)

Revision as of 18:55, 5 January 2011

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 Done
  • 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 Done
  • 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 Done
  • 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)
2. 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)
3. 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) (very high utility for a clinical encounter, which is why at the top right). 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) edit/list button screen 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)
4. What is the difference between a rule target and a rule filter? As far as I can tell, they are both involved in determining whether or not a rule applies to a patient; it is not clear to me from the code. Please help us understand the difference, as I believe the admin gui utility for configuring the rules engine may have to mess with these.--Aron Racho 22:58, 3 January 2011 (UTC)
The flow of the rule engine is as follows. Lets say were looking at patient 'Bill'. We look at the first rule 'rule_A'. In 'rule_A' we first grab the associated filter set (note only one filter set per rule, for now) and test the filter set to patient 'Bill'. If Bill passes the filter set (he is now part of the group being tested), he then moves on to the next test (the target). So, we now grab the associated target set(s) for the rule 'rule_A' (note there is a mechanism for multiple target sets per rule), and test them to the patient 'Bill'. If 'Bill' does not pass the target set, then the action (associated with failed target set from 'rule_A') happens (or in the case of cqm, it is used in the calculation). To get further differentiation of filters vs targets, check out the functions test_filters() and test_targets(); note how many more features are required to be dealt with in test_filters() than test_targets().--Bradymiller 08:08, 4 January 2011 (UTC)
  • The flow is not the actual question: What is a Target? and What is a Filter?. How do they differ to the USER? We are trying to create a UI that users can understand and configure, so we need clear definition of the terms themselves and how they are applied. The flow in the code itself is fairly obvious, and not the issue at hand. --Tony - www.mi-squared.com 18:40, 5 January 2011 (UTC)
  • The filter is to select the population that you want to run the test (ie. check for the target) on. For example, lets use a pap smear. The filter would be for woman only over a certain age. The target is the pap smear itself. This is important, because the filter defines the population of patients that are pertinent to the rule (this is used as denominator in cqm rules and in the future to auto-report results in the clinical reminder widget even if the target is true (ie. show the hgba1c result even if it is up to date)). I hope this helps.--Bradymiller 18:55, 5 January 2011 (UTC)
5. We are proposing that the rule admin GUI will allow you to define, per rule, where the source of the filtering criteria. For example, rule_dm_bp_control_cqm wants to source its targets from form_vitals, bps and bpd, etc. columns. We want to present an human language 'nice title' for things like form_vitals (which really can be any developer form table, or other source such as CUSTOM:act_cat_assess). There doesn't appear to be a linkage from the rules_target or rules_filter table to any such table that could provide this friendlier name. Any suggestions on how we surface this friendlier name?--Aron Racho 00:49, 4 January 2011 (UTC)
Several things here. First, the actions categories (ie. act_cat_assess) do have list_options lists; for example act_act_assess is Assessment. And CUSTOM basically means the data is stored in the 'rule_patient_data' table, which in actuality is simply a garbage bin to hold data points that do not yet exist within the OpenEMR; as procedures and other openemr code is developed more for MU, less and less things will be stored in this table; nonetheless it will still always be an important mechanism that will add another nice option for customization. For example, lets say I want to track yearly fingernail length in some weirdo clinic; they could simply create the rule in the clinical rule admin GUI, use the CUSTOM method, and not need to worry about creating a sql data container or form for this information. On to the more pressing question; how to create user friendly constants (and translations) for stuff such as bps form_vitals etc. This is actual gonna be quite simple, since the actual number of terms that are used is not that big, and can be added to as more places in the database are used. Basically a simple list_options list(s) will suffice and can be done as building the admin gui.--Bradymiller 08:22, 4 January 2011 (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=5855"