Difference between revisions of "CDR Performance"

From OpenEMR Project Wiki
Line 52: Line 52:
::*Testing all the reports in Reports->Clinical to see which ones are running fine and which ones aren't
::*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).
:*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).
[[Category:Clinical Decision Rules]]

Revision as of 18:17, 4 November 2011

Issues

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


Summary:

  • 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/Fixes

Jquery Optimization

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

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
  • 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 add a javascript processing animation to the scripts that will take awhile.
  • Likely will need to optimize the diagnois filter/target code within the library/clinical_rules.php functions.
  • Consider breaking up the batch scripts (the ones that go through a large number of patients) and/or running them as scheduled processes.

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