OpenEMR Wish List

Like any successful and active open source project, OpenEMR is a work in progress. Some desirable features are missing because no single party has yet been willing to cover the entire cost of developing them.

We are addressing this need by coordinating funding from multiple users. You can participate by studying the list below and finding an item that's important to you, and deciding how much you might be willing to contribute towards having it completed. Then, send email to rod@sunsetsystems.com with this information, and we'll contact you and the other contributors when it appears there's enough combined funding to make it happen (or if anything else happens regarding the item that is interesting). Please also tell us any ideas or needs you may have regarding the specifics of implementation. If you have interest in multiple items, please send a separate email for each.

In addition, you may have wish-list items that are not covered here. In that case please also send us mail as above, and we'll add them to the list.

The contributions that you propose are not binding. The idea is to tell us about your degree of interest at the time you write to us. We will reconfirm your interest and enter into more formal agreements with you and the other contributors when the time comes to do the work.

So without further ado, here's the list.

Item: Customizable Clinical Templates
Status: Partially funded
Suggested by: Larry Ozeran

OpenEMR sorely needs a way for doctors to easily create their own clinical encounter forms. Once created, these forms should be very fast to fill out without a lot of typing, and should produce reports that resemble traditional clinical notes.

Dr. Ozeran has suggested an approach for doing this which looks very promising, using an easily understandable template language. It just needs some refinement and funding. The following mockups illustrate:

• Creating a Template
• Using the Template
• The Final Result

Note: One user points out that this template language should be improved to include diagnosis codes based on the various checkbox and list selections. We might also want to consider Clinical Decision Support (see below) concurrently with the template feature.

Item: Simplify Billing
Status: Done except for paper claims
Suggested by: Rod Roark

The way FreeB currently works, a "standard" XML-RPC interface was designed over which the EMR/PM system communicates with a billing system (FreeB). This interface is overly complex, slow, and difficult to debug.

What we can do instead is have OpenEMR write X12/837p files directly. X12 is already a standard, and doing this would be much more straightforward than conforming to the FreeB interface. On top of this we can create utilities (not specific to OpenEMR) to convert X12 to other formats (HCFA 1500, UB-92), deal with printing, and view the X12 output in pleasing ways. SQL-Ledger interfacing should be retained and ported from the current code.

The end result would be a billing system that is much more usable and understandable than the current one, and which would require no additional effort to install.

You'll find related discussion here.

Item: Spelling Checker
Status: Not funded
Suggested by: Andres Paglayan

With a built in dictionary where users can add their words and phrases.

You'll find related discussion here.

Item: Calendar Customizations by Practitioner
Status: Not funded
Suggested by: James Brown MD

The ability for each practitioner in a clinic to have their own customizable "calendar template". This would include the ability to specify the duration/granularity of appointment time slots, and to specify different "booking rules" for different days or according to the time of day. For example you may allow new-patient appointments only at certain times.

You'll probably have some special requirements of your own in this area, so please be specific if you email us about this item.

Item: Drug Interaction Checking
Status: Not funded
Suggested by: Innocuous; Sam Bowen MD

Sam says:

Drug Drug interaction should be an automatic feature every time a new drug is added to the medication list. Names of the medications will need to be standardized (using a search function of the medication database) or at least the tool will need to ignore case for matches. Also it will work best if the tool can recognize brandnames and associate them with generic names.

The easiest way to do this is list:
Toprol XL : metoprolol
Then search metoprolol for drug-drug interactions.
Drug Drug interaction lists tend to come based on generic names.

Adding a manual button to initiate searches to check before adding a drug to the list would be fairly easy.
Click a button in the problem list area labeled "drug-interaction"
A pop-up runs a dialog:
search the database for the name of the new drug
enter

business logic checks against the drug-drug database and issues a warning and how severe the interaction may be.
(A link to read about the interaction would be nice here.)

You'll find a lengthy forum discussion here which also includes discussion of decision support (see below).

Item: Clinical Decision Support
Status: Not funded
Suggested by: Innocuous; Sam Bowen MD

Sam says:

I have approached this so far by designing forms that are driven by chief complaint.

I start with a chief complaint such as "bronchitis".

I then research a general way of taking care of "bronchitis". Currently I use "Saunder's Manual of Medical Practice". This book is very general and oriented towards family practice and urgent care.

I then create the form using the primary diagnostic clues as stated in "Saunder's Manual of Medical Practice", include the differential diagnoses, "clinical pearls" that help delineate different conditions, and a short list of diagnoses in a drop down box.

Then I go through the process of creating an OpenEMR "form". I think these might be more appropriately referred to as "clinical modules".

I would prefer to incorporate the search engines that you use in your "fee sheet". I could look up the diagnosis codes and fee codes from inside the "clinical modules". The billing function could then be initiated from inside of the encounter using the "clinical module" and the fee sheet search tools that you have already developed.

Your addition of the ability to associate a chronic diagnosis with a particular encounter is one of the first steps in this decision making process.

It does require standardization of the diagnoses being used. I think you should "require" the use of the fee sheet diagnosis search tool. None of this will work if the business logic can not make a match due to poor spelling or typos.

Say, as an example, I am seeing a 74 year old man with type II diabetes that is out of control.

I look up:
diabetes mellitus : 250.02 (poorly controlled type II DM)
I enter this as a chronic diagnosis.
I start an encounter using this diagnosis.
at the end of an encounter as I "finalize the visit". I get a pop up box that reminds me:
The following parameters need to be checked:

*Hemoglobin A1c* (type II DM) quarterly
*Lipid panel* (Type II DM) anually and quarterly if abnormal
*Liver function* quarterly if on (search the med list for HmgCoA reductase inhibitors, thioglitazone (Avandia, Actos), etc.)
*renal function* (Type II DM) quarterly, warn if the last creatinine is/was 1.4 (men) or more and if 1.3 (women) or more. Critical warning if the medication list also shows any medication containing metformin.
*retinal exam* due every 6 months
*microalbumin to creatinine ratio* due annually or quarterly if elevated
*PSA* male over 50

One can see how ths will require some work. Ideally, a laboratory information system will become part of OpenEMR and these searches based on certain lab values will be checked by the "Decision support module" and reported only if data is missing.

In the "bronchitis module" "expert decision models" can be incorporated. These "Expert Decision Models" can arrive at the correct diagnosis with high degrees of certainty. This certainty level can be expressed as a probability.

This depends on setting up the forms correctly Signs and symptoms can "checked off" with explanatory text boxes.

The "Expert program would run off the presence or absence of the signs and symptoms (simple check boxes will do).

A "help" button to explain to the physician how the decision is being made and why. (Doctors don't respond well to being kept in the dark.)

This type of decision making is why I have been setting up the "clinical modules" the way I do.

You'll find a lengthy forum discussion here which also includes discussion of drug interaction (see above).