CDR Performance

Issues

Several issues have been brought up in the forums, regarding performance of the CDR engine. Here are the forum threads:

• Our experience with the new OpenEMR 4.1.0
• OpenEMR 4.1 is very slow
• Patient Reminders (4.1.0) fails on large db

Summary:

• Patient Summary page widgets related to CDR are slow

• Notable, this gets slower as the number of patients in the database increases(this has been fixed).
• Also, the other non-CDR related widgets(with ajax calls) appear to be slowed down by the CDR related widgets(ajax calls).

• CDR engine based reports are slow

• So far, the Administration-Reminders reports has been reported to not work with a patient database size of 4500 users. Suspect this issue will also be encountered in other CDR engine based reports. (this has been fixed, albeit the reports take a very long time)

Plan/Fixes

Jquery Optimization

• Upgrade Jquery, since this should improve the ajax calls from the main patient summary screen, hopefully avoiding the CDR-unrelated ajax calls from being effected by the CDR-related ajax calls. Note this has already been done by yehster in the 'master' branch(an dis in version 4.1.1): http://github.com/openemr/openemr/commit/a23f3e34e5410f4cdd61f3304b9e0900a8c3e699

• Awaiting feedback if this helps performance of the larger databases.

MySQL Optimization

• Partially related to mysql indexing.

• mysql indexes below have shown to drastically improve performance of the Patient Summary page and other CDR engine related pages:

• 'pid' and 'type' indexes on the 'lists' table
• 'pid' index in the 'form_vitals' table
• 'pid' index in the 'forms' table
• 'pid' index in the 'form_encounter' table (only in the upgrade script)
• 'patient_id' index in the 'immunizations' table
• 'patient_id' index in the 'procedure_order' table
• 'pid' index in the 'pnotes' table
• 'pid' index in the 'transactions' table
• 'patient_id' index in the 'extended_log' table (stores disclosures)
• 'patient_id' index in the 'prescriptions' table

• The above indexes have been added to OpenEMR 4.1.1 development version and the database upgrade script for that version. It was also included in the most recent 4.1.0 patch.

• Apparently checking redundant diagnosis codes in mysql standard rules. Since it is checked via LIKE %.Value.% then seems like no need to check redundant dx codes (for example, for diabetes ICD9:250 is checked, so seems to be no reason to check the more specific codes ICD9:250.xx). Can probably remove/optimize these all for the diabetes and HTN codes.

Code Optimization

• Remove php time limit for scripts:

• openemr/interface/patient_file/reminder/patient_reminders.php

• Place set_time_limit(0); php command at top of script under the require_once stuff

• The above time limit mod has been added to OpenEMR 4.1.1 development version. It was also included in the most recent 4.1.0 patch.

• Also plan to add the set_time_limit(0); to the CDR report script

• Also add a ajax mechanism to the scripts that query more than one patient (break the processing down into 5-10 patients at a time), which improves performance: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/4733322 (post number 45)
• Consider having the sql queries bypass the logging engine
• Consider optimizing the diagnois filter/target code within the library/clinical_rules.php functions.
• Consider incorporating session optimizations ( session_write_close() ) as illustrated here: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/5241401

Testing

• Debug and reporting from users/developers/vendors with large databases.

• Can either do this via tools(such as Firebug, XDEBUG, KcacheGrind, and/or monitoring sql query freq/time) or via observations and reporting of the following:

• Going through adminstration->alerts and working through the rules one at a time.

• Set as Patient Reminder to test the Administration->Reminders page or the Patient Reminder widget on the Patient Summary page.
• Set as Passive Reminders to test the Clinical Reminder widget on the Patient Summary page.

• Testing all the reports in Reports->Clinical to see which ones are running fine and which ones aren't

• Reporting the results in one of the above sourceforge threads or on this wiki page (when reporting, very useful to know the size of the following mysql tables: patient_data, form_encounter, form_vitals, lists).