William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu
Read other articles by this author
We are all familiar by now with the phenomenon of clinical users being unhappy with their EMRs for a variety of reasons. These reasons often include that there is a mismatch between the EMRs workflow and the existing clinical workflow. I saw an example of this during a recent physical therapy session in which I overheard one of therapists, who had been on extended leave, being tutored in the new EMR system that had been implemented during her absence. Among other issues it was noted that the new EMR had no place for vital signs which were now to be recorded under Comments. After a while the returning PT was asked what she thought of the new system. Her succinct reply was “I hate it!”
Once stuck with an EMR one option is to keep the distinct clinical and EMR workflows and constantly or intermittently convert from one to the other. For example, to deal with an EMR whose design assumes data elements will be available in a particular order that is different from the order obtained clinically, the user might jot down the clinical data on scrap paper and then enter it later instead of contemporaneously. Or the user might write down various previous results from the different parts of the EMR where they reside in order to have them all in one place for review. (As an aside I was intrigued to see a medical device recall of a laboratory data transfer system that struggled to explain the difference between a “previous result” and “the most recent previous result”, since all of the stored results were previous to the new one.)
A second option is to change the clinical workflow to align it with the EMR. This might be met with more enthusiasm if the EMR design had been based on some serious analysis of clinical workflow and how it might be improved, and if the users had actually been consulted. If the EMR workflow is superior in one or more ways, then this could be a good thing. It is however more commonly observed that the designers of the EMR appeared to have no clue about clinical needs. Here superiority might be greater efficiency in completing a task (faster). Note that time saving does not automatically result in lower cost which only occurs if the time saved is converted into additional revenue (more patients) or the number of personnel is reduced. The EMR driven workflow might also result in a more consistent capture of some data element. This can be forced by having the EMR not advance until a data element is entered. This might be fine unless that item was unavailable making the EMR then not useable. (I confess to occasionally entering nonsense in a webform when some entry is mandatory, although not when something as important as patient care is involved. In most cases nonsense works fine because the software needs something in that box, but not necessarily something that makes sense.) Back to my recent physical therapy experience, the users also complained from time to time that a record was locked up because someone else didn’t log out, and now nothing could be done until that person was found. EMR driven workflow might result in an actual improvement in individual quality of care, although this has rarely been demonstrated.
Of course, these kinds of issues are not limited to EMRs and we might see them in any number of software products we interact with. In this regard, it was recently pointed out to me that an FDA data entry for Substantially Equivalent has changed from SE (an obvious choice) to SESE (a less than obvious choice). Substantial equivalency is a term of art related to bringing Class II devices to market by “clearance”. Such devices are not “approved”, but we need not address this further here. So the question was, why does the database now show SESE, and does this have any new meaning. An inquiry revealed that the new database required only 4 letter codes making the self-explanatory SE no longer a valid code. Thus, the database design was driving the new practice, as opposed to good practice driving the database design. Sound familiar?