Difference between revisions of "Active Projects"

From OpenEMR Project Wiki
Line 77: Line 77:


:''Awaiting Developer to fully analyze and fix these bugs.''
:''Awaiting Developer to fully analyze and fix these bugs.''
== Code ==


== Diagnostic Coding ==
== Diagnostic Coding ==

Revision as of 17:34, 4 August 2012

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.

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.

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 way 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)
Awaiting Developer to fully analyze and implement this.

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).
Awaiting Developer to fully analyze and implement this.

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)
Awaiting Developer to fully analyze and implement this.

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.
Awaiting Developer to fully analyze and implement this.

Improve Performance

A page tracking this project can be found at CDR Performance.
Awaiting Developer to fully analyze and implement this.

Provider patient-relationship for per-provider reporting

This is fully discussed at Description_AMC#Patient.28s.29_selection and Description_AMC#Potential_Issues (Issue #1). Currently the provider-patient relationship is taken from the Provider selection from patient demographics. Some facilities may want to actually use encounters that include physicians instead for a patient. An ideal solution is to allow different methodologies of patient-provider relations in the reports themselves with a solution to integrate this discussed on post 2 of the following thread: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/5473584
Awaiting Developer to fully analyze and implement this.

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).
Awaiting Developer to fully analyze and fix these bugs.

Code

Diagnostic Coding

Integrating DSMIV

See DSMIV Diagnostic Codes Development for details.
Awaiting Developer to fully analyze and implement this.

Documentation

API

Document the codebase via DocBlocks to allow creation of an OpenEMR API.
  • This project is ongoing and further details can be found on the OpenEMR API wiki page.

Access Controls

Finish the Access Controls Listing page.

Insurance Eligibility Check

Finish the Insurance Eligibility Check page

Lists

Finish the OpenEMR Lists page.

Offsite Patient Portal SOAP API

Document the SOAP APIs for the third party portals.

Settings

Finish the OpenEMR Settings page.

Forms

Ability to Sign Notes

This has been requested numerous times.
Awaiting developer to analyze and implement this.

XMLFormGen script upgrade

Can be found at contrib/forms/xmlformgen/
Documentation at OpenEMR Xml Form Generator
Discussed here: http://sourceforge.net/projects/openemr/forums/forum/202504/topic/5393338
  • 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)
Awaiting developer to analyze and implement this.

Internationalization

Date formatting

Functions in th openemr/library/formatting.inc.ph library are used to support internationalization of dates, which are controlled by Administration->Locale->'Date Display' settings. Still work to do in order to support this throughout entire codebase.
Awaiting a Developer to finish analyzing this and incorporating throughout entire codebase.

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.
Bradymiller is maintaining this.


TO DO:
1. Manually add '-- All --' and '--Select Role--' to the next translations adding constants cycle.
2. Continue placing comments in confusing constants (via {{<comment>}} strings)
3. Consider migrating to transifex, which is discussed here: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/5254742
4. 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.
Awaiting developer to implement TODO number three and four.

Medications

Integrate medications and prescriptions

Awaiting Developer to fully analyze and implement this.

Integrate RXNorm

There is currently a mechanism to import the RXNorm codes, however it has not been yet implemented in OpenEMR.
Awaiting Developer to fully analyze and implement this.

Messages

Message Center

Fully integrate Messages, dated reminders and authorization within the same screen.
  • Improvements needed for Message module
  1. Include counting of uncompleted messages in the Messages link counter also. (DONE and committed 4/28/12)
  2. Refresh every 30-60 seconds (same mechanism as the dated reminders module)
  3. Place a patient to link directly from the messages (as the reminder does) (DONE and committed 4/28/12)
  4. Consider not requiring a patient linking
  5. Make the 'Done'(from Message gui) and inactive (from pnote gui) consistent (DONE and committed 4/28/12)
  • 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)
Awaiting Developer to finish implementing this.

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.
A Developer is planning to work on this.

Miscellaneous

EMPTY SECTION

Security

Security Vulnerability Assessment and Fixing

This project is active and has been moved to its own wiki tracking page at Codebase Security.
Awaiting Developers to continue implementing this project.


Specialties

Mental Health

Seems to be a very large demand for this.
Awaiting Developer to fully analyze and implement this.