CDR Performance

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

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

Patient Summary page widgets related to CDR are slow

• Notable, this gets slower as the number of patients in the database increases.
• 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.

Plan

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: http://github.com/openemr/openemr/commit/a23f3e34e5410f4cdd61f3304b9e0900a8c3e699

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

MySQL Optimization

• Potentially related to mysql indexing since performance gets worse as the number of patients increases. Awaiting further testing/debugging to locate performance bottlenecks before taking any action here.

• Proposed mysql indexes (It has been confirmed that these indexes drastically improve performance of the Patient Summary page and other CDR engine related page)

• '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

• When add indexes to database.sql for next OpenEMR version, also need to add in the upgrade script and can take advantage of the SHOW INDEX and CREATE INDEX mysql commands to do this in a safe fashion.

Code Optimization

• Potentially related to coding. Awaiting further testing/debugging to locate performance bottlenecks before taking any action here.

• 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

• Also add a javascript processing animation to the scripts that will take awhile.

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).