GSOC 2013 Projects

From OpenEMR Project Wiki

GSOC Project Ideas Overview

This is a listing of ideas for Google Summer of Code 2013. Please just think as these ideas as starting points and also feel free to propose your own project; the sky is the limit here. We highly recommend discussing your project proposal on the OpenEMR developer forum for advice. You can also direct any application questions or proposal questions (or any other questions) to Brady Miller at
  • We are a very friendly group and are very excited to participate in GSOC 2013!!!!!

To learn more about our project and how things work, check out our Developer documentation.


Stage 2 Meaningful Use Certification

Numerous project ideas can be found on the OpenEMR Certification Stage II Meaningful Use wiki page. There are a huge number of potential projects and ideas here if interested in helping OpenEMR getting ONC certified for 2014.

Clinical Decision Rules (CDR) Engine

Lots of room for improvement in this module. To learn about the engine, check out CDR Engine. Also have an API for the main library file of the engine here: clinical_rules.php.html

Add mechanism to allow patient specific rules and plans

Implement a mechanism to allow patient specific rules and plans. There is currently a mechanism in place that allows per-patient turning off/on of rules, however am not able to customize the rules. A potential starting point to allow full rule customization per patient:
  • Add a patient_specific column in the clinical_rules tables (if a patient_specific rule, then hold string id of the base template there). Place a key/index on this sql column.
  • Populate the rules tables with templates (for clinical_rules id, use a naming like template_appt etc. and make the pid 0). Then if a patient wants to use the template, clones the template from the rules tables with a unique id in clinical_rules(and other tables), sets the pid to the patient id and places the template id into patient_specific).
  • Modify the resolve_rules_sql() function in library/clinical_rules.php to 1) ignore rules with a pid of 0 and a populated patient_specific column and 2) collect the patient_specific rules also.
  • Modify reports algorithm to have a setting to show these per-patient customized rules and enumerate rule data by the id in the patient_specific column (and ignore pid of 0 rule) rather than the actual id.
  • Create/modify gui to allow addition of these custom rules.
  • If needed, can follow same approach as above for plans (may not be needed, though)
  • organize templates into groups of plans, if needed (essentially equivalent to treatment plans)

Integrate Plans into the Admin GUI

Implement plan/rule mapping in the Admin GUI for CDR (At Administration->Rules). Note this simply involves creating a screen that allows mapping of rules to plans via the 'clinical_plans_rules' mysql table (as the other rules, do not show or allow mods of the cqm rules and plans)(also, note that a rule can be in multiple plans). This would be an extremely useful feature for little time, and allows physicians to view rules by plans in the Patient Summary Clinical Reminder widget Edit button (Plans tab).

Integrate clinic appointments into the CDR engine and Admin GUI

Add a mechanism to check for clinic appts in the CDR engine (for example, if a patient needs to be seen in clinic every 3 months). To avoid confusion, there is a function appointment_check() in library/clinical_rules.php that is planned to use targets with target_appt, but this function is meant for appt reminders (for example, if a patient has an appt coming up, is reminded) and is not yet complete. (ensure it works with recurring appts and can be modified/added in the rules editor gui)

Integrate Procedures into the Admin GUI

Implement procedure filter/target creation in the Admin GUI for CDR. Note the CDR engine currently supports this (see the Coumadin rule for an example) and this feature is gonna be in high demand for users that want to create rules via the Admin GUI that involve procedures.

Integrate support for custom issue categories into the Admin GUI

Issue categories are stored in the library/ file and can be customized. Customized issue categories are already supported in the CDR engine(lists_check() function in library/clinical_rules.php), however they are not fully supported in the admin GUI(pertinent code found in the interface/super/rules/library/RuleCriteria* scripts).

Improve Performance

A page with project ideas on this topic can be found at CDR Performance.

Rules Editor Bugs

  • Do not think there should be a frequency setting in the Filter settings (Custom Table and Custom)
  • Unable to add a new Action item/category in the Set Target Custom section.
  • When adding a new Target, will silently overwrite settings if the target already exists for other rules (need to populate the fields after set a target).


Convert to InnoDB

This has been discussed on this thread:

Diagnostic Coding

Some ideas are listed in the Diagnostic Coding TODO list.

Integrating DSMIV

See DSMIV Diagnostic Codes Development for ideas.


Too Many Documents in Directories?

Now that OpenEMR (4.1.2+) can upload documents that are not mapped to patients, the question arises as to how many documents can be stored in each directory (since all unmapped documents are now stored in directory documents/00 or documents/direct at this point); note that this is not an issue when using the CouchDB option. This issue was brought up in the following forum: . It is still not clear if having to many files in a directory is an issue, but there is a potential solution discussed in the above forum (if needed), which consists of:
  • If there was a concern of getting to many files in one directory, then could consider creating randomly creating a directory(if not existent yet) in documents/00/ or documents/direct/ (0-10000) and placing the file in it. Note for this to work then need to deal with the fact that the Documents class does not work for second-level directories in the documents folder(this fact is what plagues the scanning form); so would make sense to have a path_depth sql_column in documents (default to 1) in documents that simply gives the directory depth of the sql_column 'url' entry in documents table to find the file. For example, the depth is 1 currently (only the first item is popped off the path), but in the case of adding another level to the directory (direct/1010), then the depth would be 2. Note that some may say, well why not just take the directory to right of 'documents' in the 'url' field, but we can not rely on that (the documents directory may be configured to something else, which would then break). The nice thing about a depth descriptor is that even higher level document directory structure would then be supported.


In order to fully support Documents (and CouchDB), should consider modifying the fax/scan scripts to utilize the Documents class directly when placing documents. See the following function in the library/ script for an example of this: phimail_store().


Ability to Sign Notes

This has been requested numerous times.
  • Forms are free to be modified as currently implemented until "signed".
  • When Signed, a SHA1 hash code (or similar) of the content and a revision number is incremented. The signature is marked in a signature tracking table and form is locked and can no longer be modified after this.
  • Ability to verify the hash code of a form would be provided as an Admin feature
  • A user can add an addendum(s) to a signed form, which can also be Save/Signed like above.
  • Question: Is a Addendum, just a free text note appended to the locked form or a "copy" of the original created as a NEW form record referencing the previous.

The base classes for marking a form (or any table entry) as signed has already been done by At: Minor enhancements to include MD5 and revision # would be needed.
  • Enhancement to add a Globals to turn on Sign and Sign+Lock for forms that have had this feature added would be needed.
  • Documented/standardized method for adding this feature to interface/forms/* would be needed
  • Enhancements to LBF form tools would need to have this feature added.
  • XML Formgen and may need to be enhanced as well.
  • Optional feature to save a 'signed' form as a PDF and attach it to the patient might be of interest as well.

Ability to view all notes from one screen

Currently, need to go into each individual encounter to view notes. Need to have a screen that allows straightforward listing/viewing of notes (for the physician to read) in at least chronological order (could also order by physician, type of note, etc.).

XMLFormGen script upgrade

Can be found at contrib/forms/xmlformgen/
Documentation at OpenEMR Xml Form Generator
Discussed here:
  • Think of a way to avoid lists conflicts in list_options table. Options include:
  • hard-coding the lists instead in the form (as with the layout)
  • add a new lists table for each form
  • add a new element in the list_options sql table to categorize
  • Such as a new sql-column
  • Or just prepend formname(dir) to the list id with || separator (I am leaning towards this, since can then use the lists across forms and can then be a mechanism to categorize/subcategorize lists)
  • Upgrade to new security model
  • Support all datatypes
  • Get it to work with just the xml file (ie. create the files on the fly via xlst like the ccr/ccd stuff)


Custom Report

The mechanism that creates a pdf report for patient custom report does not support internationalization. See the Html2pdf wiki page for plan to support internationalization of this in the future.

Translation database maintenance/improvement

We currently have a stable collaborative system in place to allow translation of any language. The translations are entered into a OpenEMR Translation Google Doc Spreadsheet. These instructions and scripts (README files describes the pipeline in detail) then allows conversions of the translation spreadsheet to mysql tables and allow detection and insertion of new english constants into the translation spreadsheet.
A new set of official translation tables are created daily.
1. Consider migrating to transifex, which is discussed here:
2. Build mechanism to import most recent translations in the Administration->Language->Manage Translation Screen.
  • Can leverage mechanism used to bring in the most recent translation set into the development demo.
  • Should use the 'standardized_tables_track' table to keep track of what is imported.


Migrate issue categories into the database

This is rather important especially with the existence of the Multisite Module. Just need to do what was done to the code_types which were also migrated from hard-coding to the database, which will then allow easy and practice specific customization. The current issue categories are hard-coded at library/


Message Center

Fully integrate Messages, dated reminders and authorization within the same screen.
  • Refresh every 30-60 seconds (same mechanism as the dated reminders module)
  • Bring in authorizations into the Message Center
  • Integrate all into a nice consistent style
  • Add a automated forwarding mechanism (for example, when a clinic member is on vacation)
  • Consider adding a flag to user table to show that they should receive local messages/reminders (if can't figure out a way to figure this out with current scheme)

Appointment Reminders

There is currently a mechanism in OpenEMR, which is broken: Sms and Email Notification Howtos. This needs to be fixed and/or can try to leverage the Reminders features in the CDR engine.


Command Line PHP Scripts

The command line php scripts since version 4.1.0 do not work since a site needs to be assigned. See the following sourceforge thread for issue (and a temporary work-around):


Security Vulnerability Assessment and Fixing

This project is ongoing with some good ideas at the following wiki page at Codebase Security.


Mental Health

Seems to be a very large demand for this.