2016-06-19

By HAYWARD ZWERLING, MD

I have been involved in HIT for 2.5 decades as a designer and primary programmer of a commercial EMR which I developed for my practice and was sold from 2000 until 2015. As a result of that experience, and 15 years of interactions with the physicians who used my EMR, I developed some insights about which features have real utility to the practicing physician and how to design an EMR so that it is efficient and intuitively obvious how to use the EMR. I have since learned that many of those useful features and design considerations have not been incorporated into all EMRs.

In my previous posting on The Health Care Blog , I discussed some EMR features which would be expected to appear in the Progress Notes and Labs section of the EMR. In this posting, I will discuss some other useful features/EMR insights which, I hope, will eventually be incorporated into all EMRs.

Again, I want to reiterate that my list is not intended to be comprehensive and it is totally subjective. While I expect that some of the items on this list may already be in some EMRs, I am certain that they are not in all EMRs.

Search functionality:

The user should have the ability to search the entire database, on any indexed field, such as demographic data, providers, Problem list, Medicine List, Allergy list, old problem list, old medicine list, PCP and associated MDs, insurance, race, language, ethnicity, date of visits, Vital signs, Flow sheet data, radiology data, legal documents (HCP, Advanced directives, HIPAA) smoking status, etc. For example, “Find all male patients, <65 yo, who have DM-2 and albuminuria and hypertension, and have not been seen in the last year, and whose most recent HBA1c>9, and is managed by Dr. XXX, is on lisinopril, and last SBP>160” or find all patients who are on 2 specified medications. Once a search is conducted, the resultant information should be able to be easily exported out of the EMR into an Excel or cvs document, for use as the physician feels is necessary.

Search functionality:

Any physician should be able to assembly a list of patients, based on any indexed text field then automatically add a note to the chart of each of those patients (with the option to add a “To do” or a “Reminder.”)  For example, if a publication shows that a specific medication has a new side effect when it is used in patients of a certain age or gender or in conjunction with another medication, it is useful to be able to add a note to the relevant patients chart that says something like “At next visit remember to discuss the newly reported side effect of medicine XYZ, see AIM 2016;214:123”)

Search functionality:

When test results return, it should be very easy for the physician to send an order to the lab that says “Please add this additional blood test to the current sample in the lab.”

Medicine List:

The accuracy of the medicine list is crucial to patient care. The process of altering an existing medicine on the medicine list, adding medications to the medicine list, removing medications from the medicine list should be able to be accomplished with a maximum of 1-2 clicks.

Problem List, Medicine List:

There should be a “comment” field associated with the Problem list and Medicine list so as to allow to the user to enter any ancillary information they feel is necessary.

Problem List, Medicine list, Allergy list

The user should be able to add data to these essential elements of the patient’s chart in every location where the data is displayed and the data should be displayed in every location where a practicing physician might be expected to want to see those data elements, such as in the Progress Notes, Flowsheet, Labs, Orders, etc. It is irrational to make the user navigate to another location in the EHR in order to modify these data elements.

Clinical Summary:

There should be an option to keep a list of all physicians who are involved in the care of the patient and their assigned roles such as cardiologist, surgeon, etc

Graphing data:

One should be able to graph any numeric data, print the graph (for the patient) as well as incorporate the graph directly into the patient’s Progress Notes as an essential component of the medical narrative.

Referral letters:

The user should have complete freedom to decide which data elements will be included in any printed / faxed document, down to the level of an individual lab test, radiology report and Progress Note.

Patient Portal:

The physician should have the ability to decide what type of information appears on the patient portal, e.g., Labs, Radiology, Problem list, Medicine List, Allergy List, Progress Notes, Flowsheet, Vaccinations. The physician should have the option to turn off the patient portal for an individual patient, ”hide” an individual Progress Note from being displayed on the patient portal and “hide” a particular lab test from appearing on the Patient Portal. The physician should also have the option to decide when a result will appear on the Patient Portal, for example, immediately after the data is added to the EMR or 3 or 7 days after the data is put into the patient’s chart.

To Do List:

It should be possible for the user to create a “future To Do,” which disappears from the system until a specified date in  future when the item reappears on the user’s “To Do list.”  It should also be possible for the user to ask the system to display all their  “future To Dos” with a single click. This gives the physicians an easy way to track items that will happen in the future and helps them maintain an uncluttered screen.

To Do List:

It should be possible for the user to provide various “priorities” to each of the items on their “To Do” list and allow them to sort their “To Do” list by date, patient name, priority, creator of “To Do”, type of “To Do.”

Ordering test:

When ordering tests, it should be easy to tell the lab that a copy of the test results should be sent to another physician (or to the patient) and this process should require no more than one click.

Ordering test:

When ordering tests, the user should be immediately presented with the date and results from the last time the test was done. In addition, the (relative) cost of the test should also be presented to the user and an estimate of the patient’s expected incurred cost.

Miscellaneous feature:

It should be possible to print an envelope addressed to the patient at all locations in the EMR where such a feature might reasonably be needed, such as on the Clinical Summary layout, Orders layout, Lab results, Progress Notes, X-rays, Prescriptions, etc. Similarly, at the location which contains a physician’s or pharmacy’s address, there should be a button that prints a pre-addressed envelope.

Miscellaneous feature:

One should be able to create letters or emails, based on templates, and these templates should give the user the ability to automatically incorporate various bits of information in the form of “macros,” as discussed above. For example, it should be possible to build a “template letter,”, that can be used to write a letter or email to a patient, which says something like “Your recent tests are normal. Here are the results. Please see me as planned on DDD/MMM/YYYY” and this can be either printed (with an envelope) or emailed with one click.

Miscellaneous feature:

In all locations where this information might reasonably be needed by the physician, the date of the patient’s next appointment should be displayed, such as on the prescription layout, labs layout, Progress Note layout and where the physician reviews incoming data (test results, email) etc.

Miscellaneous feature:

The user should have the ability to easily redirect any notifications, like newly received lab results, to another individual in the EHR.

Miscellaneous feature:

On the fax cover page, the user should be able to include (and easily alter) a default message like “Current guidelines for DM-2 recommend that tight control is not appropriate in the elderly.” This will facilitate the ability of one physician to educate other physician.

Miscellaneous feature:

EMRs which are used in an emergency room should be able to send a message to the patient’s primary care physician, when the patient arrives in the emergency room. In addition, physicians need to be able to turn on and off these notifications both at the individual patient level and at a global level. In addition, the physician should have the ability to redirect these notifications to a surrogate.

Miscellaneous feature:

The physician should be able to determine the sort order of the Problem list and Medicine list. For example, they may want to have the list for the medicines sort alphabetically or by time of day they are administered or based on importance or toxicity, or any other way that the user wishes to have the problem list and medicine list sorted.  This can easily be accomplished by adding a numeric “sort order” field for each diagnosis and medicine.  This sort order will then be retained wherever Problem list or Medicine list is displayed.  To facilitate medicine reconciliation, it should require no more than a single click to change the Medicine list sort order to “alphabetical” and to return the Medicine list to the preferred sort order.

Miscellaneous feature:

It should be possible for the user to create a “future letter” to a patient, which is retained in the EHR until a specified date in the future, when the letter is automatically printed (with an envelope) or emailed to the patient.

Miscellaneous feature:

It is absolutely imperative that the EMR be designed to minimize the number of clicks and the need to change locations within the EMR. This situation can occur when the physician needs to see a “type” of data that is located at another section of the EMR.  One way to bring information to the physician, without requiring them to navigate to another location in the EMR, is to use the “color” of the buttons to convey information to the physician. For example, if the physician is viewing the Progress Notes, the “go to labs button” could be red if there is no lab data on the EMR.  If the patient has lab results in the EMR, the “go to labs button” could be green.  Thus, by looking at the “go to labs button”  the physician would immediately know if there was/was not lab data on file. One can use multiple colors to convey more nuanced information. For example, the “go to the appointments button” could be red if the patient’s next appointment is “today,” while yellow implies the next appointment is within 1 week, blue might imply the next appointment is more than 1 week in the future while grey means that the patient has no scheduled upcoming appointments.

Miscellaneous feature:

Another way to bring information to the physician, without requiring them to navigate to another screen, is the use of the “hover over” option.  If the physician wants to know the date of the patient’s next appointment, they simply hover the mouse over the “go to the appointments button” and  pop-up window immediately appears with the date of the upcoming appointment appointment(s).  The same feature can be used to display the most recent lab data, chart of vital signs, radiology data, the patient demographic data like phone number, etc.  Thus, it is possible to deliver information to the physician, when/where they need it, without requiring them to navigate to a different section of the EMR.  This will reduce the amount of data sent over the network, speed up the EMR and improve the EMR’s usability.

Miscellaneous feature:

Physicians should be able to generate a list of all of a patient’s previously prescribed and discontinued medications and sort the list by generic name, brand name, date entered into the EMR, date prescribed, date discontinued, prescriber and class.

Miscellaneous feature:

To reduce the possibility that a physician would click on a button that they did not intend to click on, when the mouse hovers over a  navigation button, that button should change colors to indicate that is the active choice.

Miscellaneous feature:

All EMRs should have a location in the EMR where physicians can store copies of patient handouts, medical articles, protocols, PDFs, text information, pictures and other items which they will believe will be helpful to their practice. The physician should be able to organize this information into logical sections, subsections and sub-subsections. They should also be able to search this information, print the date and copy / paste the information into a patient Progress Note, as they see fit.

Miscellaneous feature:

At the same location on the computer screen, in all locations throughout the EMR, there should be a “suggestion” button. When clicked, a text window opens and the dialog box reads “Enter you suggestion to improve this EMR below. Your suggestion, along with your location in the EMR and other relevant EMR data will be sent to the CIO, MD, who should be a practicing physician that uses the EMR on a regular basis. The CIO, MD should assemble an “EMR re-design” team to sort through these suggestions and prioritize which changes should be made to the EMR by the CTO and his/her team. It is imperative that the power to decide whether and when a new feature should be added to the EMR should reside with the clinicians, not with the technologists.

In my opinion, a suggested new feature should be added to the EMR if it creates no unresolvable security issues and proposed feature meets any of these criteria:

1) will likely be used by many users

2) has the potential to improve the efficiency of the health care provider

3) has the potential to reduce the cost of healthcare

4) has the potential to improve the quality of healthcare

5) has the potential to promote patient engagement

Technical issues, like it is “too technically difficult” or “the IT department has other priorities” or “it cannot be done” are not acceptable reasons to fail to add a new feature to an EMR. As a programmer, I know that there is always a way to circumvent almost all technical issues.

Finally, I want to again encourage you to add your EMR suggestions to this list. Maybe the large EMR vendors will read your suggestion and add the feature to your EMR.

Show more