OpenEMR WIsh List

OpenEMR Development
1

drbowen wrote on Wednesday, March 23, 2005:

More forms, More forms, More forms.

Forms should have reasonable defaults that print well and are meaningful for insurance reviewers.

Problem oriented forms that are more intuitive with a lot of drop down lists to help non-typists.

The ability to print mutiple visits and have the output organized with all the forms from a particular encounter grouped together.  Currently all the encounters are listed together, the vital signs listed together etc.

A comprehensive report should be available with or without all the demographic data.

We should be able to print reports with some demographic data, but the SSN should generally not be included or at least be optional.

Ability to print reports for specified date ranges.

There are plenty of practices using OpenEMR who are not "medical practices".  There are chiropracters, physical therapists, and others.  These practices will need their own specialized forms.

And of course an easy to use form generating tool would be invaluable.

Sam Bowen, MD

2

rwjblue wrote on Wednesday, March 23, 2005:

*  Role based security.  The ability to grant people access to certain functions and not others.  For example I would like to have my intake person preform all scheduling, but I do not want that person to create encounter forms.

*  The separation of scheduling resources and users.  A scheduled resource should be able to be a room, a facility, or a provider.  This should be independant of any users of the system.  It would also be nice for multi-location offices to allow a separate security context for each location.  For example Jane schedules for facility A, but not facility B.

*  Pluggable themes.  This was a capability of the Synitech version of OpenEMR.  Why was it removed?

*  Forms generation tool, and best practices guideline.

I am going to be dedicating some time to these functions .

Robert Jackson

3

drbowen wrote on Wednesday, March 23, 2005:

I agree about role based security. 

This needs to be flexible.  Smaller offices like mine have front office staff who are cross trained to perform vital signs and stage patients.  These indivduals would need to be assigned more than one role at a time. 

This is generally true of all smaller offices.

A best practice guidline would be an invaluable tool. It would be nice to have a context sensitive set of guidlines.

As an example, the bronchitis form should conform to best practices and include best practice guidelines.

Sam Bowen, MD

4

drbowen wrote on Wednesday, March 23, 2005:

Why did the themes disappear?

How about autocratic rule?

Sam Bowen, MD

5

drbowen wrote on Wednesday, March 23, 2005:

While we are on the topic.

A theme editor would nice.  Each practice could then create to their hearts content.

The different colors of each programable element could be selected from a dropdown list and the list could editable.

Sam Bowen, MD

6

drbowen wrote on Wednesday, March 23, 2005:

Spell checking.

PHP has a built-in spell checker.  It would probably involve having an include of the library.

We could have a compiled medical dictionary as part of the documentation.  That way each practice could contribute their accumulated medical words to the OpenEMR dictionary.

Medical dictionaries (of words and phrases) generally contain about 500,000 independent words and phrases that are usually included in a standard English dictionary.

I think I spell pretty well but my typing really sucks.  As you tell from my posts I tend to leave out words and mistype things.  This substantially slows down my progress using OpenEMR during clinical encounters.

Sam Bowen, MD

7

rwjblue wrote on Wednesday, March 23, 2005:

In regards to the role based security here is what I was thinking:

Create a roles table which would contain two fields: RoleID [Autonumber], and Description varchar(255)  which would contain records like:

1 - View Demographic
2 - View Encounter
3 - Change Encounter
etc…

Create a user_roles table containing the following fields:

userID varchar
roleID int

This table would contain records like:

robertj - 1
robertj - 2

If we use a structure like that we can have extremely granular security that is very extensible. 

I have this mechanism in place with another piece of software that I have put together and it seems to work very well.

It would definately take a bit of work to integrate it, but when it is all said and done I think that it would be a great improvement.

Robert Jackson

8

emilykillian wrote on Wednesday, March 23, 2005:

1) Spell check

2) Printouts that are organized and easy to read

3) A warning that comes up after a certain amount of inactivity

For example, If OpenEMR isn’t used within an hour, it logs the user out, but doesn’t notify him or her. He or she tries to add a patient note - gets it typed in there, hits save - and boom. The note isn’t there and the user is at the login page again. Then he or she has to log in again and retype everything. With a warning, the user would know before starting to type that he or she has timed out.

4) Pop-up box that reminds clerical users to update a patient’s demographics and insurance after a certain amount of time (preferably at least once a year).

I would think that this could be linked to the box that’s for the financial review date.

9

wpennington wrote on Wednesday, March 23, 2005:

The section RFE (Request for Enhancements) section of OpenEMR is a desirable place to put this information.  I suggest that each request for feature enhancement be acompanied by a way to fund the software development of that feature. 

OpenEMR is open source software.  If a user wants or needs a feature from OpenEMR, they can develop that feature, or hire a consultant to develop that feature.  Open source is different from proprietary applications because the users control what features are added. 

I believe that adding Role Based Access Control (RBAC) to OpenEMR is a 7-9 man month project.  The actual development will be shorter, but I evaluate a project as the time to design, develop, test internally, allow limited user testing, fix bugs, release and verify that the client is satisfied with the project.  In meeting this standard, I believe that it will take 7-9 months.  I also believe that Role Based Access Control would benefit OpenEMR, but the unresolved question is who should pay for adding RBAC, and who is willing to contribute. 

I prefer adding feature requests when supplemented by a means to fund the building of those features. 

10

rwjblue wrote on Wednesday, March 23, 2005:

I believe that you are absolutely correct.  As suggested earlier we need a few things for coordinated development.  One of those things is a task list/todo list.  This will help developers new to the project have an idea of where to start.  I cannot speak for everyone here, but I am not looking for handouts.  I have specific needs for our deployment of OpenEMR that I believe will help others.  I am perfectly willing to code all of the suggestions that I listed above.  I was simply attempting to gauge the usefullness of those features.

Robert

11

andres_paglayan wrote on Wednesday, March 23, 2005:

Hi Robert,
about role based security,
there is this module GACL,
http://phpgacl.sourceforge.net/
should make things much easier
My recommendation is take one task at a time,
I always get swamped when I work in many

12

andres_paglayan wrote on Wednesday, March 23, 2005:

I agree that the RFE is defenitely the right place for the wish list.
https://sourceforge.net/tracker/?group_id=60081&atid=493004

13

sunsetsystems wrote on Wednesday, March 23, 2005:

Wow, nice find!  This looks very promising.

– Rod <rod at sunsetsystems dot com>

14

rwjblue wrote on Wednesday, March 23, 2005:

Thanks for the advice.  That project looks like it could make my job much easier.

Thanks again,

Robert

15

drbowen wrote on Thursday, March 24, 2005:

The RFE seems to be the logical place.

Yet the RFE doesn’t seem to allow for discussion of the relative merits of different proposed improvements.  Isn’t that the function of a forum?

Sam Bowen, MD

16

drbowen wrote on Saturday, March 26, 2005:

Improved OpenEMR security.

Encryption of sqlconf.php.

Context sensitive help on forms.

17

jimbo456 wrote on Saturday, March 26, 2005:

I have just setup a medical billing company on the OpenEmr software. A wish list for me would be a master module that will setup and manage several companies. This master module will need super user rights to all companies. To do this now we need individual directories and database for each company. Inefficient, why not one directory install with multiple databases and a master db to manage.

Jim Proctor

18

drbowen wrote on Saturday, March 26, 2005:

Two way laboratory communication with incoming HL7 stored in the database in a way that we could graph values like hemoglobin, creatinine, A1c.

A telephone call manager that helps track telephone calls until resolved. Like a "help desk" or contact menagement program.

Bar code generation and reading to improve filing accuracy of scanned documents.

Patient check in screen to allow entry of chief complaint in the lobby to start a new encounter in the patients own words.  HIPPA precludes us from asking these questions.

Tracking of check in times, time to vital sign recording, time to initiation of practitioner contact, time to check out.  These are quality measures valuable to all practices.

An in office IRC to allow realtime communication of problems.  Like "Mr. smith just checked in with a chief complaint of crushing sub-sternal chest pain."

The screen at the bottom of the main page used by practitioners   for authorizations (authorizations.php) gets horribly full. We sometimes have 50-60 names in the box.  A short list of 5 names is inadequate.  It would help immensely if each patient was assigned to single practitioner and have only the assigned practitioner’s patients come up in the authorizations box.

Sam Bowen, MD

19

drbowen wrote on Saturday, March 26, 2005:

Jim Proctor,

This is an interesting request.  There are issues involved with HIPPA.  While you, as a billing contractor have access to some of the data, comingling data from different companies may raise issues with the Feds.

I’m pretty sure that giving you “Super-user” rights to any medical practice as a non-employee of the practice will likely cause legal difficulties.

Yet, having a complimentary program to do what you ask, would be a good thing for the billing department of any practice.

I would think that you need a module that can connect to a client database and be able access and manage demographics, CPTs, HCPCs and ICD-9 codes.

I think you should not have direct access to patient medical information such as viewing the notes directly.  You could be granted restricted access to resolve a particular billing question on a case by case basis.

These things get back to the access control questions that were listed above.

It seems that you need a separate module or program intended specifically for billing companies that give limited access to patient related data.  This module would need all of the usual accounts receivable management tools that we are used to with our current biling program.

Outstanding claims.

Aged outstanding claims.  (15d, 30d, 45d, 60d, 90d, 180d) By insurance company responsibilty, By patient responsibility.

Dunning letters and reports.

AR (accounts receivable)

AR days outstanding.

Underpaid claims reports. (yes sad but true, not all insurance companies are honest).

Claims of unknown status.  (How much money seems to be in the electronic dumpster)

Graphing tools for AR, AR days outstanding, productivity of the practice as a whole and individual practitioners on patient visits, charges, collections. 

Generate/print dunning letters and billing statements.

Worklists based on aging reports to contact insurance companies and patients over unpaid claims.

These are things that come to mind. The practice management tools would be gleaned from the SQL-Ledger accounts. While ICD, CPT, HCPCs will likely come from the "Super-Bill".

The HIPPA questions would have to be posed to an attorney experienced in this area.

Sam Bowen, MD

20

drbowen wrote on Saturday, March 26, 2005:

The patient finder should return the lastname, firstname, and middle name/initial.

It would be nice to have a nickname field since some patient have nicknames that htey like to be called, some of which have no relationship to their real names.