OpenEMR Roadmap

PAGE MOVED: http://www.open-emr.org/wiki/index.php/Roadmaps#OpenEMR_Project_Roadmap

There are many things that an electronic health record can and should do. Some of these are easy to create and others take more thought.

Active Projects

• OpenEMR Internationalization Development - as many languages as we can
• OpenEMR Certification
  • USA CCHIT Meaningful Use Certification - 2011 criteria, Target release at end of February 2010
  • USA CCHIT Full 'C' level Certification (follows meaningful use)
• User Interface Refactor
  • Full pass internal cleanup and implementation of more AJAX for modern look and feel
  • API to support clean work flows
  • Model for plugin of customizations that does not require code changes
  • Reporting look and feel standardization
• For a complete and detailed list, go to Active Projects page

Wish List, Concepts and Ideas

Demographics - OpenEMR currently has international support. We intend to give multinational support on a much broader basis. This includes the ability to select demographics that have appropriate names, address fields, postal codes, and international telephone numbers.

Result Reporting

Laboratory
X-ray

Multiple Note Creation Options

Dictation
Templates
Voice Recognition

Laboratory Interface

Office Laboratory Interface
Reference Laboratory Interface

Prescription writing

Drug interaction checking
Online formularies

Flow charting

labs
vital signs
growth parameters

Referrals

Consults
Diagnostic tests
tracking

Charges and coding

Automated charge entry - This is done via the Fee Sheet, just needs a slightly easies setup wizard
E/M Coding Assistance

Hospital interface

X-Rays
Laboratories
Inpatient Reports

Basic Guide Lines for Reports

1) Reports should be READ ONLY (no batch processing hidden as a option on a report, use a separate menu area for that or different link)

2) The menu should have a clear description of each report in sentence form. Some are obvious, but new users are easily confused

3) All reports should have an export to CVS option

4) All reports should follow the basic printing model

5) All on screen reports should have paging control including NONE as a user option.

6) All reports should have a 'save' option. There are plenty of times you want to compare this month to last month or similar and date ranges are not reliable when you can back post information. The export to CVS might be a stop gap, but not all users will want to mess with another layer.

7) The SQL bookmarks that show up as user defined reports should have user comments/descriptions available and follow the same guidelines as above.

Common printing interface

1) Any thing that would normally be printed should have a button named "Print", located in the same relative place on every form or report.

2) All Print options should go to one format, PDF seems the most likely for good format control, but other options may work as well.

3) All printed output should have a header that includes the facilities name, the report name or other type designator

4) All printed output should have footer with date/page#

5) Some configuration table could be used to control the header/footer and page size type details so that page breaks are controlled and consistent.

6) All reports should be able to be assigned to a default printer specific to that report if desired. (this might be tricky across OS types)

7) Print Preview should be a option on all printed output.

8) All forms that need to be aligned should have a print alignment button.

Other

• Patient registration information (master patient index)
• Telephone message documentation and tasking
• Internal e-mail
• Secure external e-mail for patients
• Patient Web portal
• Patient education
• Scanning
• Automated chart documentation (problem lists, medication lists, vital signs, health maintenance)
• Electronic fax reports (dictations, lab, radiology) to outside specialists
• Patient follow-up/health-maintenance deficiency alerts
• Practice population analysis tools
• Decision support tools
• Security (audit trails, user access hierarchy, passwords)