Difference between revisions of "OpenEMR Roadmap"

From OpenEMR Project Wiki
(Created page with '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. I have listed features that are desirab…')
 
 
(10 intermediate revisions by one other user not shown)
Line 1: Line 1:
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.  I have listed features that are desirable in all electronic health records.
=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|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.
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
===Result Reporting===


<blockquote>
<blockquote>
Line 10: Line 27:
</blockquote>
</blockquote>


Multiple Note Creation Options
===Multiple Note Creation Options===


<blockquote>
<blockquote>
Line 18: Line 35:
</blockquote>
</blockquote>


Laboratory Interface
===Laboratory Interface===
<blockquote>
<blockquote>
     Office Laboratory Interface<br>
     Office Laboratory Interface<br>
Line 24: Line 41:
</blockquote>
</blockquote>


Prescription writing
===Prescription writing===
<blockquote>
<blockquote>
     Drug interaction checking<br>
     Drug interaction checking<br>
Line 30: Line 47:
</blockquote>
</blockquote>


Flow charting
===Flow charting===
<blockquote>
<blockquote>
     labs<br>
     labs<br>
Line 38: Line 55:




Remote access
===Remote access===


Referrals
===Referrals===


<blockquote>
<blockquote>
Line 48: Line 65:
</blockquote>
</blockquote>


 
===Charges and coding===
 
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)
 
Charges and coding
 


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


Hospital interface
===Hospital interface===


<blockquote>
<blockquote>
Line 82: Line 80:
</blockquote>
</blockquote>


 
===Basic Guide Lines for Reports===
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)
 
Basic Guide Lines for Reports:
<blockquote>  
<blockquote>  
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)
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)
Line 110: Line 97:
</blockquote>
</blockquote>


Basic guide lines for common printing interface
===Common printing interface===
<blockquote>
<blockquote>
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.  
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.  
Line 129: Line 116:
</blockquote>
</blockquote>


More to come ...
===Other===
<blockquote>
 
   
* Patient registration information (master patient index)
</blockquote>
* 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)

Latest revision as of 20:22, 8 October 2017

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


Remote access

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)