The Black List Part II (Features Which Should Be In Every EHR,...

The Black List Part II (Features Which Should Be In Every EHR, But For Some Reason Aren’t)

20
SHARE

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.

Leave a Reply

20 Comments on "The Black List Part II (Features Which Should Be In Every EHR, But For Some Reason Aren’t)"


Member
Michael Chen MD
Jun 21, 2016

As an aside, but related to the open source discussion between Adrian and Margalit….
The concept of the post itself…these are all very valid arguments as a “feature request” in an open source project hosted on GitHub. In fact, the idea of an open source project (like mine) allows an EHR to be peer reviewed by both physicians and patients. Why open source is not encouraged or adopted by physicians doesn’t make much sense to me as it is very analogous to a peer review process. Why should an essential communication tool such as the EHR be constructed behind closed doors without any meaningful input by the users? Currently, its neither a helpful tool (poor UI, clinical workflow awareness) nor does it communicate (interoperability). With your permission, Hayward, I’d be glad to transcribe these items in your post into my project on GitHub to address what has been achieved already with my project as well as future features.

Member
Jun 21, 2016

PLEASE freely share these ideas. That is the reason I posted them.

In Massachusetts, 80% of physicians are employed. As a result, very few physicians have little or no say as to which EHR they are required to use. As the medical industry consolidates around larger medical groups, and physicians are turned into “vendors” who work for these large healthcare groups, this problem will (unfortunately) get worse.

Member
Michael Chen MD
Jun 30, 2016

For all those interested, I have the list compiled in my GitHub issues list with my EHR open source code at this URL: https://github.com/shihjay2/nosh-core/issues. I’ll be adding the first part of the Black List in the near future.

Member
Jun 20, 2016

You almost had me nodding, but then …
“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.”

NO. NOT EVEN A LITTLE BIT, DUDE. NO. The clinical side DOES NOT get to have a conversation over the supine form of a supplicant patient by parsing out what info that patient can and cannot see via a portal. All in. My body, my data. You don’t get to be my parent, you’re just my doctor. If you don’t think I’m capable of understanding what’s in my record, prescribe resources (like peer communities, i.e. #bcsm or #s4pm) that can teach me how to understand and fully participate in my health/care.

Patient engagement isn’t kindergarten, yo.

Member
Jun 20, 2016

Medical care must be individualized for each patient. There is no “right answer,” with regard to deciding how much information to disclose, which is appropriate for every patient. If the patient does not trust their physician, they should seek care from a different physician.

Clearly there are times where information which is in the medical record should not be disclosed to the patient. For example, physicians will often speculate as to what they’re thinking, trying to come up with the right answer (diagnosis), and they may not want to disclose their thought process to the patient until they are certain if what they are thinking. For example, if I am taking care of a patient who has an ill-defined psychiatric disorder which could be bipolar disorder, depression, maybe suicidal or post traumatic stress disorder. While I’m trying to figure this out, I would not want to share this information with the patient as premature disclosure might disclose factually incorrect information and could scare the patient off, and then the patient will not get the care they need.

If all physicians were forced disclose all information in the medical records to all patients, all the time, the medical records would be degrade into a mindless recitation of incontrovertible facts, and the patient would get inferior medical care.

We need to remember that the first and most important purpose of the medical record is to help the patient. Billing issues, legal issues and disclosures are all secondary to making sure we keep our focus on helping the patient get the best medical care the provider can deliver to the patient.

Member
Adrian Gropper, MD
Jun 20, 2016

There’s nothing whatsoever keeping you from having your own “secret” patient notes. The EHR I’m talking about is the record that’s meant to be shared.

For example, the NOSH / HIE of One proof-of-concept that Dr. Chen and I are demonstrating has the same (open source) NOSH EHR for both physician and for every patient that wants one. There’s nothing that prevents the physician from keeping anything they want on their mdNOSH and from sharing that mdNOSH only with their coverage partners. Our system, however, defaults to putting patient data in the pNOSH unless the physician specifically acts to enter it into the mdNOSH – an action completely equivalent to a physician keeping something in the traditional EHR away from the patient portal. (As another benefit, in our model, the mdNOSH patient portal is there but the patient has no reason to visit it so patients don’t have to deal with a dozen separate portals.) In some cases, a physician who doesn’t have an mdNOSH will sign-in directly to the patient’s pNOSH EHR. In that case, private notes and legal records would have to be kept manually / separately.

What we’re proposing is not restricting the physician’s discretion and, when properly executed with standards like FHIR, OAuth, and single-sign-on, it takes no extra clicks for the physician as compared to an institutional EHR. It does however, solve many care coordination, telemedicine, and multiple portal problems for the patient.

The open source design of NOSH means that an MD or practice can customize their mdNOSH if they want to but they might notice the transition from mdNOSH to pNOSH if they customize some things. This is exactly the behavior we expect of a commodity. Both the mdNOSH and pNOSH are commodities but they can be customized by individual physicians and patient communities if they want. If the customization strays too far from the commodity, incompatibilities will arise, but that’s obvious and expected.

Member
Jun 21, 2016

I think the concept of physicians keeping a “private” electronic medical record, where they record their differential diagnosis and thoughts, and which is routinely not shared with patients is potentially dangerous and may lead to worse medical care. There would undoubtedly be a legal case in which the the secrecy of these records is challenged in courts, And the courts will need to answer the question, are these actually part of the patient medical record, will insurance companies have access to them, will patients need to jump through additional hoops to have access to them or are they really the property of the physician who has the right to keep them private from everybody. Further, if the physician does not share these with other healthcare providers, the other healthcare providers who see these patients will not understand the thinking process that the physician was undergoing when treating the patient and this will result in worse care. In the end, the patient facing records will simply be a list of lab tests, vaccinations, radiology results, all of which are now available through most institutional EHRs. There will be no medical “thought” contained in those records.

I think the idea of physicians having “a secret” medical record is anathema to the medical profession’s history and to best medical practices.

Member
Adrian Gropper, MD
Jun 21, 2016

You’re talking about two different things. One has to do with one doctor’s professional liability (license and malpractice risk) which has absolutely nothing to do with whether the secret records are analog or digital. This is not an argument against what I’m proposing. It’s a professional issue equivalent to many young docs that I knew in the early days of EHRs (and maybe still today) keeping their own notes about patients in Evernote or Word before moving some of that into the EHR.

The second thing you mention is where we differ. The loss of autonomy and patient dignity that comes with limitless sharing of health records across today’s 10 Million-patient integrated delivery networks is absolutely unsustainable. Sharing records without patient transparency and authorization at the 10 or maybe even 100 physician-level may be reasonable but it is degrading at the regional level and beyond. Also, as Watson-style machine intelligence is added to these massive integrated delivery networks and also available to the patients, the ethics of degrading the patient’s access to decision support by a machine like Watson is questionable.

Member
Adrian Gropper, MD
Jun 20, 2016

Hayward’s lists are some of the best examples of why health information technology needs to be open source software. Most of the missing “features” he lists are side-effects of unwarranted differentiation.

EHRs are the ultimate commodity – right up there with web browsers, cars, and plumbing. When’s the last time you chose your web browser based on a feature list? How much customization do you expect in your car or your plumbing? The customization of these commodities is interesting and valuable but it’s done person-by-person. The shared (among thousands of people) aspects of these commodities is never differentiated. The whole proprietary, secret source approach to EHRs makes as much sense as installing proprietary single-vendor pipes in your home.

Member
Jun 20, 2016

I understand your argument Adrian, but I don’t think cars are commodities 🙂 and not all major browsers are open source. I don’t think open source or commodity is the issue here. I would expect lots of customization in EMRs just like cars, or rather vehicles, because hauling furniture is not like hauling kids, and ICU is not like GP visits. I actually would have preferred to see many specialty specific little EMRs instead of those very popular generic things turned into veritable customization nightmares because they are trying to satisfy so many specialties. That trend was extinguished by MU.
The last thing I want to see is another monopoly raise its ugly head, whether it is open source or not, whether it says it does no evil or not….

Member
Adrian Gropper, MD
Jun 20, 2016

The part of the car or the browser that is meant to be shared among multiple people are commodities. The parts that are personal are not. We don’t make cars with extra pedals or joysticks instead of steering wheels just because we could. It would make the car overly personalized. Same with the browser. An EHR is meant to be used by 10,000 persons. It’s crazy to presume that one hospital system will have a vastly different spectrum of 10,000 users than another hospital system 100 miles away.

Member
Jun 20, 2016

I don’t think this is about personal preferences as much as it is about the job. In my opinion a hospital should not expose the same user interface to all departments or specialties or even roles. The underlying information should be the same, but I don’t see why the UI should be a compromise so that everybody can somehow work in the same tool. It should not matter what EMR (browser) you use to access the same database (Internet).
At one time hospitals used to buy best of breed software and interface the pieces.Then the “monolithic” thing happened, or was pushed upon unsuspecting victims, mostly because interfacing was very hard and paper was no longer an option. I think we made a mistake….
I think we need a universal database structure and vendors should compete on UI and functionality. And I am not talking about those cutesy plug and play little apps to graph BMI or whatever. I’m talking about nephrology EMR, surgery EMR, oncology EMR….. full blown stuff.

Member
nichollsvi
Jun 20, 2016

Considering we have Epic, I’ll make sure to bring this one up.

Member
Jun 20, 2016

Great list in general (combined with the first part), although some features may be more important to some and less so to others who may have more burning problems (the tabs issue mentioned by Steve2 is always a hot topic, for example). Also, as I said before, I know of many EMRs that have lots of these things implemented. I would assume that the author’s own EMR was built this way, in which case, why was such a good EMR discontinued?

Member
Jun 20, 2016
Member
Jun 20, 2016

Oh… I see. Thank you.

Member
Steve2
Jun 19, 2016

WE have had EPIC a bit less than a year now. Still mastering, LOL, the EMR. Your list has some good suggestions. I would like to know why we can’t tailor things more oforour specific specialty. I don’t care much about the frequency of BMs. If the pt has had an echo in the last 2 years I want it to pop up automatically. Why can’t I have tabs like I do with my browser? I have to entirely leave the prep section to go look at other stuff, then remember it to add to pre-op section. Also, I am really worried about death by EPIC from the information overload, most of which is not helpful. Why onset the system trigger automatic alarms? Last week I had a pt who had a full breakfast at 0630 and they still sent him down for surgery at 0900.

Last of all, and maybe most annoying, I know we all have to be facing many of the same problems. Why is it that every time I ask an EPIC rep what was done at other hospitals they never answer?

Steve

Member
LeoHolmMD
Jun 19, 2016

Pervasive problem. Our vendor seems to hide solutions the same way. We waste a lot of time reinventing the wheel and forward thinking ideas from other institutions are not shared. More information blocking.

Member
Allan
Jun 19, 2016

This is where the EHR should have started, but it didn’t. It started by serving other people rather than those that produce and have used the notes treating patients. Organic growth. Excellent list.