Active Projects

Overview

This is a listing of currently important active projects. This is a place to see what's going on, and also a place to see where help is needed by other developers and testers. These are kind of ordered by how important they are to OpenEMR's future.

Wiki

Internationalization

This has been a bit more difficult than anticipated. The polyglot extension was initially considered but is no longer maintained and likely buggy. Gonna go with below manual approach described HERE

1. Install/configure the following extension:
   • ParserFunctions
     • The ParserFunctions extensions adds some logical functions to allow use of the languages and languages/Lang templates described HERE.
2. Recruit translators

Language Testing Page

Jason B. and Brady are working on this.

Certification

A very large multi-developer project is currently underway to get certification and is described on the ONC Meaningful Use Project wiki page.

Internationalization

OpenEMR supports internationalization and multi-language clinics. Most of this are from recent modifications that got released in OpenEMR 3.1.0. Further information on the project can be found on the internationalization configuration and development wiki pages.

Date formatting

Still work to do in order to support date formats across multiple languages. Here's the forum thread discussing this.

Awaiting a Analyzer to figure out a good plan for this.

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.

Brady is maintaining this.

Calendar

Multi-facility bugs

Description of bugs:

1. Things work great with one facility
2. With two facility the bugs appear (different bugs happen with the $GLOBALS['restrict_user_facility'] turned off(default) and on)
3. When $GLOBALS['restrict_user_facility'] is turned off get following behavior. In essence the calendar only shows what is set as 'default facility' in the users settings. If you choose the facility then that user won't be available. By choosing all facilities, it will actually show all appointments from all facilities, however the scrollbar display is confusing (shows the top item), and unable to schedule an appt at anything but in the scroll bar; this also screws up what you see when scrolling through new days.
4. When $GLOBALS['restrict_user_facility'] is turned on, then only seems to work right if you place all facilities in the users settings 'Schedule facilities'. Then everything seems to work fine, but there is no option to view all facilities, which seems like should be an option. If you don' t place all facilities in the users 'schedule facilities', then you'll see other appointments at other disallowed facilties like they are on the selected on (not much of a bug since appointments shouldn' be scheduled on disallowed facilities anyways), however can only add to the allowed facility, which is good.

Seems like the bug(s) really stem from three mechanisms:

1. When choose all facilities, don't then highlight the item below it; highlight them all and that have this supported when click other buttons (moving days or adding appt)
2. With global restrict_user_facility off (default) allow users to be scheduled at all facilities.
3. With global restrict_user_facility on give option to show all facilties in calendar.

Currently linked to this tracker item and this forum thread.

Awaiting a Developer to fix this bug.

Recurring appointment bugs

This problem is discussed in this forum thread and this forum thread.

Bug described in good detail by Gayll in this bug tracker item: http://sourceforge.net/tracker/?func=detail&aid=2963714&group_id=60081&atid=493001

Awaiting a Developer to fix this bug.

General code base improvements

Security Vulnerability Assessment and Fixing

ASSESSMENT

• Nice independent security analysis by Realsearch group at NC State.

The Realsearch group at NC State has been working with OpenEMR in it's evaluation of the CCHIT security criteria. As a part of this research they've done automated testing of the application and have discovered a number of security vulnerabilities with the software. They have gone through and tried to manually verify each vulnerability. The list of actual vulnerabilities, more than 500 in total, can be found at the links below. The true vulnerabilities have a value of True in the 'Vulnerable' column.

• Automated Penetration Testing Test Results
• Static Analysis

As a summary, here are the types of issues they've found and their counts:

Fortify 360:

Cross-Site Scripting (215)

Nonexistent Access Control (129)

Dangerous Function (24)

Path Manipulation (20)

Error Information Leak (19)

Global Variable Manipulation (9)

Insecure Upload (8)

Improper Cookie Use (7)

HTTP Header Manipulation (4)

Rational AppScan:

Cross-Site Scripting (50)

Phishing Through Frames (25)

Cross-Site Request Forgery (22)

Error Message Information Leak (14)

SQL Injection (4)

JavaScript Cookie References (6)

Directory Listing (6)

Password Not Encrypted (2)

Path Disclosure (1)

• Some sort of software convention (Eurostar 2009) looking for OpenEMR bugs, still waiting for them to post the bugs. Here are all the links pertaining to this: link1 Link2 link3 link4 link5

• Published security advisories:

Arbitrary Database Creation/Database Enumeration - OpenEMR 4.0.0 (FIX included in 4.0.0 patch released on 4/15/2011)

Local File Inclusion - OpenEMR 4.0.0 (FIX included in 4.0.0 patch released on 4/15/2011)

Reflected Cross-site Scripting - OpenEMR 4.0.0

PLAN

• Proposal/plan to fix. This is a specific proposal/plan which is currently underway in order to prevent sql-injection and xss attacks. This involves a per script walk-through of the code. For developers, new scripts or scripts that have been converted to this new system need to follow these steps. Not only does this secure the script from sql-injection and xss attack, but it also markedly simplifies coding since the developer does not need to deal/worry about database escaping of variables (escape for a rare case). The strategy includes the following steps; will first discuss the strategy, and then will discuss how to practically do it.

1. Remove the mechanism to fake register globals. This is discussed here: Clean up use of the extract...
2. Automatically reverse magic quotes (if turned on).
3. Utilize binding/placeholders in sql calls (prevents sql-injection). If making a sql call that contains a variable in it, then use a placemaker.
4. Utilize htmlspecialchars function (prevent xss attacks). This function should be wrapped around all text that can potentially be "touched" by the user.
5. Exception to rule 4 for javascript literals; when using javascript literals, utilize the addslashes function instead to prevent white screen of death.

• Below is how to practically complete the above steps:

1. Remove the mechanism to fake register globals. Place the following code at top of script above the include statement for the globals.php file:

$fake_register_globals=false;

2. Automatically reverse magic quotes (if turned on). Place the following code at top of script above the include statement for the globals.php file::

$sanitize_all_escapes=true;

3. Utilize binding/placeholders in sql calls (prevents sql-injection).

sqlStatement=("DELETE FROM immunizations WHERE id =? LIMIT 1",array($_GET['id']);

4. Utilize htmlspecialchars function wrappers from library/htmlspecialchars.inc.php. These functions have ample documentation within that file.

$para_class = attr($db_data);
$para_content = text($user_data);
$header_text = xlt('My Header');
echo "<h3>$header_text</h3><p class='$para_class'>$para_content</p>\n";

5. Exception to rule 4 for javascript literals; when using javascript literals, utilize the addslashes function instead to prevent white screen of death.

<script LANGUAGE="JavaScript">
alert('<?php echo addslashes(xl('Hello there')) ?>');
</script>

• Below are examples where scripts have been converted to the new security mechanism discussed above:

Messages and Pnotes (patient notes) module: http://github.com/openemr/openemr/commit/21e15cce4507d36c7ffd234f2c4f034b38d1087e

Patient searching modules: http://github.com/openemr/openemr/commit/a9aa64513e4556aeb2f36b049e86aac47b3fef42

Transactions module: http://github.com/openemr/openemr/commit/f56f469c9d2481f3d440c79db1917e0a38f076a9

Patient history module: http://github.com/openemr/openemr/commit/a4817af442d569525b24129ed75afa915030a4dd

Immunization module: http://github.com/openemr/openemr/commit/5d06c6f08d04405a80b036810a8523a7cb680a31

Authorization module: http://github.com/openemr/openemr/commit/e08e3327b83f36164db0177c9acb8b7a1c3f9ddb

demographics.php script: http://github.com/openemr/openemr/commit/c0bfa8a51106cd97842374d5ae719bb5b469b763

Language admin gui module: http://github.com/openemr/openemr/commit/28f02594d450ce1e1546557b4cee040b8bedc194

• The forum where this plan was developed/discussed along with updates on progress is here: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3530656

Code walk through is currently underway.

Clean up use of the extract() function on post and get variable (faking them as globals)

In global.php, use of wrapping POST and GET variables within extract() function; this is a security issue. The globals.php has been recently modified to begin to excise this disease: http://github.com/openemr/openemr/commit/70038c1c6de77242c28acac2cb764d994b0a98bd

So, a script can turn it off by making $fake_register_globals=false before including the interface/globals.php script. Of course, each script will need to be tested, so this will be a slow walk through. Probably a good idea to include this in all new scripts also. Then, when the code is free of this disease, this mechanism also can be removed.

This will be a ongoing multi-developer walk through of the code'

Clean up magic quotes, prevent sql-injection, and prepare for PHP6

THIS PROJECT IS NOW DEPRECATED, AND WE ARE INSTEAD GOING WITH THE PROJECT DISCUSSED HERE: Security Vulnerability Assessment and Fixing

Plan to pass all input data through functions in the openemr/library/formdata.inc.php file before inserting into mysql database. This is useful for following reasons:

1. Will centralize input validation
2. Will centralize sql-injection blocking
3. Fix the escaping bugs(magic quotes) that are seen throughout OpenEMR when inputting the apostrophe character
4. Will allow easy migration to php6 (since magic quotes will no longer exist in php6)
5. Simplify support for other database software

Objectives of openemr/library/formdata.inc.php functions:

formData() - This function will remove escapes (if magic quotes is set), and then places database specific escapes to ensure safe database insertion of variable. Input accepts POST, GET, or REQUEST variables, and there is an option to trim the input.

formDataCore() - This function will remove escapes (if magic quotes is set), and then places database specific escapes to ensure safe database insertion of variable. Input accepts any variable, and there is an option to trim the input.

strip_escape_custom() - This function will remove escapes (if magic quotes is set). Input accepts any variable

add_escape_custom() - This functions places database specific escapes to ensure safe database insertion of variable. Input accepts any variable

Timeline objectives:

12/2009-1/2009: Clean up all the apostrophe input bugs and get OpenEMR to work with magic quotes turned on and off.

01/2009-??????: Replace all calls for get_magic_quotes_gpc() and mysql_real_escape_string() with the formdata.inc.php functions (moderate amount of work).

02/2009-??????: Systematically migrate all scripts into formdata.inc.php functions. (large amount of work)

Specific Code changes and dates:

12/01/2009: Committed a cleaner openemr/library/formdata.inc.php to CVS and will include in patch#5 for 3.1.0. Read file for details. --Bradymiller 00:05, 2 December 2009 (UTC)

12/05/2009: Committed an even cleaner openemr/library/formdata.inc.php to CVS and will include in patch#5 for 3.1.0. Read file for details. --Bradymiller 09:08, 5 December 2009 (UTC)

12/05/2009 and 12/06/2009: Focused changes in calendar appt, calendar searching, and bookmarks to make compatible with both magic quotes settings (on or off). Files modified:

• openemr/interface/main/finder/patient_select.php
• openemr/interface/main/calendar/find_patient_popup.php
• openemr/interface/main/calendar/add_edit_event.php
• openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/user/ajax_search.html
• openemr/interface/main/calendar/modules/PostCalendar/pnuser.php
• openemr/interface/usergroup/addrbook_list.php
• openemr/interface/usergroup/addrbook_edit.php

--Bradymiller 11:02, 6 December 2009 (UTC)

12/11/2009: Changes in CAMOS to make compatible with both magic quotes settings (on or off). Files modified:

• openemr/interface/forms/CAMOS/admin.php
• openemr/interface/forms/CAMOS/ajax_save.php
• openemr/interface/forms/CAMOS/content_parser.php
• openemr/interface/forms/CAMOS/new.php
• openemr/interface/forms/CAMOS/save.php
• openemr/interface/forms/CAMOS/rx_print.php
• openemr/interface/forms/CAMOS/notegen.php

--Bradymiller 22:47, 12 December 2009 (UTC)

12/21/2009: Quick conversion in the admin facilities edit page

• openemr/interface/usergroup/facility_admin.php

--Bradymiller 09:48, 21 December 2009 (UTC)

1/22/2009: Quick fixes to allow apostrophes in drug names

• openemr/library/ajax/prescription_drugname_lookup.php
• openemr/library/classes/Prescription.class.php

--Bradymiller 09:40, 23 January 2010 (UTC)

1/23/2009: Migrated the heart of the controller/smarty stuff (does not include the postnuke smarty stuff) to formdata.inc.php. No change in functionality, just centralized the input processing and string processing(before database insertion) functions. During this testing, noted a bug in the processing (if magic quotes are on then sometimes strings get slashes removed twice before going to database, thus single slashes inputted in strings may get lost; minor but worth pursuing. For example when enter a prescription it goes through the library/classes/Controller.class.php populate() function and the library/classes/ORDataObject.class.php persist() function; hence if magic quotes are on the slashes will be removed twice)

• openemr/library/classes/Controller.class.php
• openemr/library/classes/ORDataObject.class.php

--Bradymiller 09:40, 23 January 2010 (UTC)

4/09/2009: Migrated the translation admin gui

• openemr/interface/language/lang_constant.php
• openemr/interface/language/lang_definition.php
• openemr/interface/language/lang_language.php
• openemr/interface/language/language.php

quick note: Smarty cleans up its variables via pnVarCleanFromInput() function in openemr/interface/main/calendar/includes/pnAPI.php file (this function will strip slashes if needed, however doesn't escape characters for database insertion). Smarty can prepare for database commands via pnVarPrepForStore() function in openemr/interface/main/calendar/includes/pnAPI.php file (this function ca not be used with pnVarCleanFromInput() and simply adds slashes if magic quotes not on, so will need to consider securing this further in future) (both of these functions are only likely specific for calendar smarty system).

quick note #2: Should be able to incorporate this throughout all the Controller code by simply modifying the functions populate_object(&$obj) in the openemr/library/classes/Controller.class.php file and the function persist() in openemr/library/classes/ORDataObject.class.php.(This was DONE on 1/23/2009)

Currently linked to this tracker item and this forum thread.

User Interface Refactor

1. Major clean up and refactor of the User Interface experience.
   • Full pass internal cleanup and implementation of more AJAX for modern look and feel
   • Patient centric: using demographics page as the launch pad for all patient focused information
   • Use of modal windows rather that separate browser windows for all popups
   • Model for plugin of customizations that does not require code changes *designed*
   • Reporting look and feel standardization - *Done*
   • API to support clean work flow management
   • etc ...

In Progress at MI-SQUARED

Summary goals on User Interface Refactor