I recently heard a fascinating panel discussion at a top level conference, specifically about issues related to the design of electronic medical records (EMRs). The panel being interviewed represented top players in the EMR market in the US. Unfortunately, one company was not represented, specifically EPIC. EPIC is perhaps the most popular of the present EMRs in the States. There have also been many complaints about EPICs design. Perhaps their “no show” was strategic – they did not want to give any of the other EMR companies a chance to speak negatively about EPIC. In any case, I highly advise that you take the time to listen to this panel discussion.
Coincidently, the American Medical Association recently released a list of “8 ways that EMRs can be improved”. I think it is a valuable list. More importantly, it is followed up by a full descriptive document that can be seen at AMA report. The topic list from the AMA (as described in Physician’s First Watch FirstWatch@jwatch.org) goes as follows:
- Improve the ability of physicians to provide high-quality care. Poorly designed EHRs can detract from the patient encounter rather than enhance it.
- Support team-based care. EHRs must allow staff to perform their work to the extent of their licensure and privileges, as well as let physicians delegate work.
- Promote coordination of care by tracking referrals and consultations.
- Allow the product to be configured to the practice’s needs.
- Decrease cognitive workload by providing “concise, context sensitive and real-time data uncluttered by extraneous information.”
- Allow data to be easily shared with other healthcare facilities.
- Facilitate digital and mobile patient engagement.
- Allow users to provide feedback easily.
I would like to share my perspective on this critical topic. I spent 11 years creating, developing and further modifying the EMR that my previous employer, TEREM, uses. I have received very positive feedback about my EMR from multiple physicians who have personal experience with other EMRs both here in Israel and in the US and Canada. I also have read a great deal about the topic, and am aware of the basic designs of the big EMR’s in use in the States. There appears to be a significant degree of dissatisfaction with a number of the American EMR’s, possibly related to their focus on the technical (versus clinical) side of medical care.
If I was asked what the key elements are to designing the best possible EMR, I would state the following:
1) The interface of an EMR must be visually pleasant and have a logical flow that literally guides the physician or other health provider through all the steps of its use
2) It is impossible to design a single interface that is suitable to all needs. For example, the interface for an ER must be unique and will be fundamentally different from the unique interface for the gynecologists. If it is not possible to design an EMR with easily modifiable interfaces, then that EMR will ultimately not satisfy most users
3) From an internal point of view, the EMR should be entirely web-based, using whatever technology preferred. The key functionality [such as saving patient information, or accessing an x-ray, or emailing a patient, etc.] should all be packaged as an API.An API is a collection of software functions that provide universal functionality across an entire project. Even if the EMR consists of thousands of web pages, any of the programmers developing these pages must only use the functionality in the API. There cannot be two versions of an “email-info-to-patient” program. The great power of such an approach is that new webpages with new functionality and with new interfaces can quickly be designed using the standardized functions in the API.
So developing one interface for the ER and another interface for the gynecology department would be much easier. All of the hard work of programming each of these interfaces would be done by existing functions in the API. If anyone wants to see an example of my latest project, I can show you how a very elaborate page can be designed with very few lines of code, because I use an API.
4) I very much agree with the eighth point from the AMA list above, that users should be able to provide feedback easily. The way this should be done is by having a button on each page of the EMR that is called feedback. It should be possible to open this page, make a comment of any type, close the page and return to regular work within seconds. Doctors and all other users should be strongly encouraged to make such comments, even if it means paying users who make significant and important comments, that lead to changes in the interface or code.
One of the best ways to learn about the usage of EMRs, is to have the developers follow the healthcare providers once a month. The developers should be silent observers making notes every time the health care providers interact with the system. The healthcare providers should be told that they are free to say anything and everything to the developer. I personally was extremely lucky that my background in both software development and medicine, allowed me to be a constant observer of the system that I and my (brilliant) colleague wrote.
Also, I always strongly encouraged any and all feedback on my software. Ultimately, it should be the users who develop the system, if not directly by writing the code, then indirectly by constantly commenting on how to improve the software. Literally, the position and size of a single button could make the difference between a smooth interaction with the EMR and a complex one. Any developer who says that this is not a significant issue (i.e the position of a single button), does not understand how to design such software.
5) Point number five is problematic for me because it uses the term “cognitive workload”. I believe that software specifications need to use as few specialized terms as possible. There is no programming equivalent of “cognitive workload”. If you want to say that the interface should be easy on the eyes and not cause a headache, I am fine with that. I literally have no idea what cognitive workload means. Therefore, I will spend time with the doctor who wrote this specification, trying to quantify “cognitive workload”.
I have seen this many times where a user will use a term which makes perfect sense within the medical context, but is effectively unusable by the developer. For example, I once saw a request that included the term “equivalent diseases”. To a medical professional, it is clear that coronary artery disease can be in the same category as MI and CHF. But for the developer, there is absolutely no way to know how to program such a term.
The way to do it is to speak with the physician and to explain that every diagnosis needs to be formally categorized. Then, a programmer can do a search on that categorization, and match up diseases. So if you have an Excel spreadsheet, and in the first column you have coronary artery disease, then in the second column you would write “cardiac” as its category. You could do the same for MI and CHF, i.e. specify “cardiac” as their category. In this way, you could know that these three diseases all share the characteristic of being “cardiac” and thus, you could list them as “equivalent diseases”.
You may ask what happens if a single disease could be categorized in multiple ways. Cellulitis can be categorized as an infection and as a dermatological problem. The way a developer deals with this, could be to have the option to specify more than one category. So someone [a medical professional] would have to review every disease and then specify all of the categories that such a disease belongs to.
The new medical coding system ICD-10 has, if I am correct, four times as many options as ICD-9. I believe that ICD-10 has over 17,000 options. I do not know offhand if each diagnosis is already categorized in some way. The point is that there is no way for software to know what a term like “equivalent diseases” means if it is not spelled out in computer terms. Once again, because of my multiple backgrounds, I was able to overcome such ambiguities many, many times during the development of Parpar. When developers do not have a medical background, such issues can cause major delays in development.
6) I will quickly comment on the fact that the PACS system being used alongside the EMR, must be integrated in some way into the EMR. A PACS system handles all elements of storing, displaying and sharing all digital imaging information (like plain xrays, or CTs and MRIs, or even the video taken during a study of the blood vessels called an angiography). Despite the fact that the EMR and PACS systems are two distinct systems likely sold by totally separate companies, it should all look like one interface to the medical user. The user should never feel that accessing films, old and new, requires any special effort on the part of the software. Needless to say, the films should pop up as quickly as possible and be easily arranged for comparisons.
7) It has been years already where new projects consider a mobile interface as a fundamental part of a system, rather than as a patch or add-on, that is treated as an afterthought. The users need to decide what functionality they want in their mobile interface. As a baseline, there should be access to the complete medical chart, all imaging, all lab results and all consultations. The developers and designers need to take the time to make this long list of data, visually appealing on a mobile device (with its limited screen space).
The assumption should be that the user will be spending a significant amount of time using their phone and/or tablet to access the system. The interface must be appropriate for both of these devices, as well as large-screen desktops. For managers, as a baseline, they should have a whole series of statistics that describe the overall function of the clinic(s)/department/hospital. Issues such as cost and income may very well also need to be presented to the manager. Ultimately, when ever a manager finds him or herself spending significant time extracting information, the developer should be informed and a new webpage should be designed that provides this information as simply and quickly as possible.
8) All data that is covered by a single EMR installation, should also be transferred to a data warehouse. A data warehouse is a specially designed collection of data, possibly from multiple sources, that makes it much easier to analyze and review all of the data that has clinical and administrative value to the healthcare providers and their managers. So multiple hospitals, that work independently, might still all share data via a data warehouse.
During this transfer of data to the data warehouse, certain standardized statistics are generated, and reports prepared. Additional fields of information may be generated. For example, a secretary may record a patient’s date of birth. But at the time of transfer to the data warehouse, the age of the patient at the time of the visit should be calculated and saved. Later, using another interface, a manager should be able to search data by age.
I cannot overemphasize the importance of having a readily accessible data warehouse. Research time can be dramatically reduced by having a data warehouse that allows for queries according to the researcher’s needs. For example, if the researcher wants to compare postoperative hemoglobin for the same surgery across multiple hospitals, this should be a single request from the data warehouse. And all such requests should respond very quickly. And if this type of information needs to be checked often, it should be saved as a standardized report in the data warehouse, which could even be automatically run as often as the manager wishes.
9) I also cannot emphasize strongly enough the need to incorporate clinical assist tools into any EMR. A clinical assist tool “helps” a healthcare provider provide better and safer care, via software. This is a huge topic in and of itself, but there are technologies out there that allow for medical guideline enforcement or at the very least a warning system when guidelines are not followed.
Standardized templates for basic and critical information should be part of the interface. For example, no patient should leave the site of care with a head injury, if they have not been asked about blood thinners. You could easily argue that this could automatically be checked for, by looking at present medications [which should be entered at the very least at the time a triage, or pulled from previous appointments/visits]. And the software should automatically check for such a thing. Nevertheless, as the great and only Dr. Gregory House always stated, “every patient lies”. So there still is a need to formally ask this question at some point in the visit.
Over time, thousands of such guidelines and warnings and templates should be Incorporated into the EMR. As much automation must be done. To a certain extent, the endpoint of an EMR is to guide any medical professional through the complete patient visit. It might get to a point where the interaction with a computer seems too automated, nearly eliminating the specific need for a physician to manage the patient. When such a situation finally exists, it should then be far easier to have nurse practitioners or physician assistants do the majority of the management, and then have a physician act primarily as an overseer. This is an example of how technology can reduce costs, increase performance, increase safety and reduce cognitive workload.
I hope I have not totally overloaded your cognition by this point. But I really do believe that the points, as I have listed and described above, are fundamental to a properly functioning EMR, that is first and foremost a clinical tool.
Thanks for listening