I’m hoping to be able to tweak some of the Cqm rule files so tht they search for results/data in the act_patient_data table. The rules for NFQ_0059 (A1C levels over 9 with diabetes) try to extract A1C values from a location associated with laboratory result downloads. I don’t have the laboratory download function working, so the most reliable location for my A1C levels is in the rule_patient_data table with the label act_hemo_a1c. These are the results recorded when I address reminder popups. Seems to me the Numerator.php file could be tweaked a little to extract information from rule_patient_data location. The framework for making this work is already in the code.
Likewise, the same A1C values could be used for a Numerator.php script for NFQ_0061 (A1Cs below a certain level.) The denominator should be the same as for NFQ_0059, and the Numberator.php script should reflect only minimal differences. This directory would have to be added, though I suspect it could be cloned from NFQ_0059.
In addition, One could add directories for NFQ_0056 (foot exam), the results of which are already saved in the rule_patient_data file.
Doing NFQ_0575 (BP control in diabetes) should use the same denominator script, but it could extract data from the vital signs somehow in the Numerator.php script.
One could add NFQ_0064 (LDL in diabetes) similarly, but this would require one to create a popup reminder in Amc functionality to prompt for the LDL values.
I may be willing to sponsor this if it can be accomplished to create diabetes CQM reports based on data in rule_patient_data for A1C high and low and have CQM printouts well before the end of July.
Someone should take rpl121 up on this proposal. We would but we are really overbooked for July and August already.
Tony www.mi-squared.com / @tonymi2 oemr.org / @OEMR_org
Another viable option might be to write a script which synchronizes the A1c values from the rule_patient_data table to the procedure_result table and leave the existing ruleset definitions in the Numerator.php files the same. One could even add triggers which would keep the two tables in sync after the initial copy.
Simplest thing is to add it to the numerator to check both and ensure the following:
1.The entry stored in rule_patient_data is only a number (note the data entry to collect that value is a rather large textarea for entering results/details, so there is a good chance it will not be just a number). If it is not just a number then would skip this check. To really clarify this, could consider placing a Raw Data field on the input form for this to only collect the number??
(because of the potential that the field contains other info rather than the result, would suggest against synchronization methods or triggers; also, we made a decision awhile back to avoid triggers in case we ever wanted to get OpenEMR to work on other databases, such as postgresql; of course, can always re-dicsuss this, if needed)
My suggestion of using a MySQL table synchronization method isn’t meant so much as a mechanism to go into the official code base, but rather an idea to meet Dr. Leemhuis’s aggressive deadline.
Just need to be careful (could have the numerator eval for specific cases of <number> or <number>% and disregard if don’t fulfill these criteria). To get this quickly working in Dr. Leemhuis’s case would be really simple. Looking towards the future, could also place rule specific entries (actually, would be target specific) on the custom forms that get stored in rule_patient_data table (or could even create another more flexible table that rule_patient_data points to with data elements akin to the custom layout facilty specific user information that runs through the layouts engine). Then, could in this example have a form item for this that only allowed numbers with a trailing % to right of the input box. Adding this type of feature is definitely feasible.
Thanks everybody for your responses and suggestions. The frustrating thing was I thought that my diligent entry of A1C values as pure numbers on the popup reminder screens would be enough to get valid CQM reports. It was not until I actually tried printing out this CQM that I was getting no actual A1C data. The denominators were coming through but not the numerator(s). So then I started searching through the scripts and the database files to see how it actually works. I wasn’t able to figure out how to make an ad hoc modification to the Numerator.php file in NFQ_0059.php to get data from the other location. I thought of writing a totally separate MySQL script or moving the values over into official lab_results location.
Finally, I decided to level with the reviewers and just submit my zero values with the notation that there is some sort of glitch in the method and that I will be working on fixing that.
So I had to figure out how to implement the laboratory module with manual data entry. I got hung up a bit setting up lab tests in the proper hierarchical fashion. Eventually, I got labs to work manually.
Now I have to assure myself that the A1C values greater than 9 are properly recognized by the CQM Numerator.php script for the NFQ_0059.php measure. I haven’t entered enough data yet to convince myself it is working yet.
These are issues that other PCPs will have in trying to prove that their CQM reporting module is working properly.
http://www.oemr.org/phpBB3/viewtopic.php?f=11&p=911#p911
Tony notes that it is no longer a requirement that the CQM reports be done through the “certified” interface.
This is relevant to this thread as it means that these sorts of changes wouldn’t have to go through the costly certification process again.