Perhaps nowhere in the blogosphere does one find more spirited healthcare IT debates than on the subject of e-prescribing. Go to KevinMD.com and see a recent post, Why are most physicians writing their prescriptions by hand? The debate in the comments section ran for almost a month after its posting.
To supporters of e-prescribing (mostly IT folks) it’s a no-brainer. No more non formulary scripts, no more messy doctors handwriting, far fewer errors, data capture for performance review, etc. You can check your prescription against the patient’s drug allergies and check for drug-drug interactions. When your patient arrives at the pharmacy the electronically transmitted prescription is waiting for him/her. What’s not to like?
Opponents of e-prescribing (mostly docs) will be glad to tell you. Why take something so simple and make it so complicated? The technique of paper script writing has withstood the test of time for over 50 years. A paper script takes only a few seconds to write. An e-script may take over a minute. For e-prescribing the doc has to do all the work (and foot the bill), yet the beneficiaries are everybody else except the physician.
The debate is a classic example of how IT folks and MDs see the world differently.
Our experience preparing to implement e-Rx has been very revealing. About 18 months ago we began to research the only integrated e-Rx product available for our EMR. I brought a very primitive preconception of e-Rx to the table: Complete the script on screen just like we are doing now, push SEND instead of PRINT, and that’s it. There should no significant changes to our existing workflow.
I was going through the online demo when I noticed something I thought was unusual. The e-Rx app was “updating” the patient’s chart long before the prescription was written. Exactly what was it updating?
The answer I got was very concerning. The e-Rx app accesses a pharmacy database called Surescripts, which contains data on recently filled prescriptions. When the e-Rx app is run it creates a behind-the-scenes “parallel list” of medications for each patient based on recently filled prescriptions. Well, not exactly…the database includes only those meds on which a pharmacy claim was filed. If the medication was purchased with cash it doesn’t show up in the Surescripts database, so it doesn’t get uploaded to your EMR either.
Why did this bother me so much? Every other method of chart updating currently used by our EMR – manual data entry, document scanning, patient portal, HL-7 update – has a historical precedent in the paper chart system. The e-Rx update does not. We have never had pharmacies push data to us before.
“Welcome to the world of health information exchange!” the IT folks say. In fact the tech support information I found promised even more functionality in the future. If a patient fails to pick up the prescription within 30 days, “the system” will notify the physician. From an IT standpoint it looks great, and soon it will get even better.
Not so fast. To the physician this looks very different than it does to the health IT professional.
E-Rx (at least the application we need to use for our EMR) introduces a potential new standard of care into the doctor-patient relationship. Current standard of care recognizes only one source of information regarding patient medications – the patient himself. If the patient forgets to tell me he/she is taking a critical heart medication that is the patient’s error, not mine. But what if the e-Rx app uploads data to my EMR showing that the patient has recently filled a prescription for heart medication? I obtained 2 medical-legal opinions and both concur that the physician is responsible for knowing what is uploaded to the EMR regardless of how the EMR handles that data once it arrives.
To make things worse, the list is not accurate – since the Surescripts database only includes medications paid for by insurance, our hypothetical heart medication might not be there either.
The soon-to-arrive 30-day notification feature has the same problem. What if the system notifies me that a patient fails to fill a prescription? Am I now liable for the patient’s non-compliance? Must I then assume the expense and liability for making “nanny phone calls” to these patients to remind them?
There are also workflow issues. Uploading prescription data forces us to create a medication reconciliation step to match the database med list with the list provided by the patient to resolve any discrepancies. Maintaining the medication list is already the single most burdensome part of our data entry. This would make it much worse.
What looks great through the eyes of IT doesn’t look so good to the physician. Don’t misunderstand me. Like all physicians I support steps that improve patient care and improve patient compliance. But unlike the IT folks we understand that more data is not necessary better. Too much data creates “white noise”, interfering with our ability to assimilate the useful data. Furthermore, more information creates more expense; it is inappropriate to expect physicians to assume such a large proportion of the burden. Some future model of health care delivery, such as an accountable care organization or medical home, may be able to handle this issue better.