When my ideal EHR has finally been developed, I believe that it will be remarkable just how primitive even the best of today's EHRs really are.
It's Tuesday, February 12, 2022. It's cold in Los Angeles. My name's Lewis Friday but everyone calls me "Doc." I'm covering the evening shift in our pediatric practice. My partners are Ana Diaz and George Warren.
We've been in practice for 10 years and we're busy. Evening sessions are popular with working parents.
I arrived at the office at 4:30 p.m. and grabbed a small tablet. Using its front-facing camera, the tablet software recognized me and automatically signed me in. It "knows" that I am scheduled for the evening shift today so it gathered all my messages plus those things that should be brought to the attention of the evening shift physician.
Opening the clinical app, I'm greeted with a list that includes all my unreviewed lab results, my e-mail and phone messages and a list of the patients coming this evening. Each item includes a summary of the patient's problems, meds and allergies, along with the date of their last visit and who saw them. I also see the reason for today's visit, their immunization status and other items that are due.
I have a few minutes before the first patient so I start returning phone calls and e-mails. I tap on a message that came in by e-mail and compose a reply. Next I tap a phone message and the software dials the patient and enables the speaker-phone. A couple of messages could be handled better by Ana so I forward them to her with a voice annotation.
One of the items in the list is blinking red. It's a critical value from a test that George ordered. The system tried to reach him by phone and e-mail but he didn't respond immediately. The system has been configured to escalate critical values to whoever is covering if there is no response within 15 minutes. I tap the alert and call the patient. After discussing the results, I ask them to come to the office tonight for a checkup. At that point I conference in the receptionist to take over and make the arrangements.
It has been a while since I had a patient with the condition suggested by the test results so I could use some advice. I've got an app for that. I'd like the information before the patient arrives but I don't need it immediately so I request the app to start searching and alert me when it is ready but at the latest, 20 minutes before the time the patient is expected.
The time is now 5:30. The first patient of the evening is in the room.
For the exam room I'm using a larger tablet that is more suitable for charting. My charting app displays an outline of items that occur commonly during visits along with things that I have decided I want to make sure I document before completing the visit. It's easy for me to describe most findings in considerable detail with just a few taps but this case sounds like it's going to involve a complicated history so I tap a button and start an audio-video recording. I want to capture exactly what the parent has to say and I want a visual record of the patient's appearance to supplement the notes I'm making.
My plans for the patient include a couple of additional tests, a prescription and a follow-up visit. I don't prescribe this medication very often and the dose is weight-dependent. I have a rough idea of what the dose should be so I request my charting app to check my approximation and suggest a dose if I'm too far off. By including the tests and prescription in the plan, the lab orders and the prescription are already generated. All the pharmacies in the area are in the database and so is the patient's preferred pharmacy, so as part of "writing" the script, I ask the parent to verify where the script should go and it is sent there automatically. The follow-up appointment immediately appears in a queue at the check-out desk. The staff can finalize the details with the parent in just a few seconds.
Later that evening, while I'm seeing patients, I notice that a couple of the apps are running slow. It turns out that a server failed but since our systems run on a fully parallelized operating system that distributes the computing load over all the idle computers, there was no actual outage. Things just took a bit longer than usual. An earthquake could flatten the building and we would still be able to get up and running from a temporary location as soon as we could establish communications.
It's now 10 p.m. The patients have been seen. All the charting was done in real-time. There are no loose ends that will have to be finished later. All of the patients were released because no reason could be found to hold them.
The story you have just read could be true, only the names have been changed. It describes the way I would like my EHR to work. My primary goal is to retain my sanity and effectiveness, not what some external entity insists that I should be doing. To the extent that there are mandatory items, I expect the software to handle those things behind the scenes.
The system I use now already has some of this functionality but the deficiencies make it somewhat difficult to chart every patient in real-time; there is always work left to do at the end of the day. Many of the capabilities that an EHR would need to perform as described in this story are not presently available; they await basic computer science research and development. When my ideal EHR has finally been developed, I believe that it will be remarkable just how primitive even the best of today's EHRs really are.
Find out more about Daniel Essin and our other Practice Notes bloggers.