A stunning story was published in the New York Times entitled "The Doctor vs. the Computer."
A more appropriate title would have been "The Doctor vs. the Computer Fool."
The computer is simply a tool and is not the doctor's opponent; rather, the people under whose auspices the IT was designed and implemented are the physician's foes here:
The Doctor vs. the Computer By DANIELLE OFRI, M.D.Electronic medical records promise efficiency, safety and productivity in the switch from paper to computer. But there are glitches, as a patient of mine recently brought to light.
My patient needs prostate surgery. It is my job, as his internist, to estimate the risks this surgery poses, decide whether he can proceed with the surgery and make recommendations for his medical management before and after the operation.
He is an extremely complicated patient. His hypertension requires three concurrent medications. He’s taking pills for diabetes, but he really should be giving himself insulin injections. His kidneys are wending their way toward dialysis. A few years ago he had a reaction to a diabetes medication that caused congestive heart failure. His aortic valve is narrowed — not severely, but enough to keep me on edge.
Estimating my patient’s surgical risk and planning for his operative care is not a straightforward process.
The complexities are anything but linear and deterministic, and judgment borne of experience is essential. No algorithm will replace this process in my lifetime, I suspect.
After our physical exam, I sit down to write a detailed evaluation, because I want the surgeons and anesthesiologists to fully understand the complexity of his situation.
In medicine, if you don't know your patient and their history, your patient's dead.
As I type away, I feel like I’m doing the right thing, explicating my clinical reasoning rather than just plugging numbers into a formula. I’m midway into a sentence about kidney function when the computer abruptly halts.
I panic for a moment, fearful that the computer has frozen and that I’ve lost all my work — something that happens all too frequently. But I soon realize that this is not the case. Instead, I’ve come up against a word limit.
It turns out that in our electronic medical record system there is a 1,000-character maximum in the “assessment” field. [Brilliant! - ed.] While I’ve been typing, the character number has been counting backward from 1,000, and now I’ve hit zero. The computer will not permit me to say anything more about my patient.
I see no reason for any degree of politeness or sensitivity regarding this mission hostile "feature" of a clinical documentation system. The person(s) who either designed the system this way and/or set constraints such as this were fools - on first principles - for imposing such a limitation.
... In desperation, I call the help desk and voice my concerns. “Well, we can’t have the doctors rambling on forever,” the tech replies."We" can't?
Yes, I guess "we", a.k.a. the computer Einsteins who've invaded clinical medicine (or more precisely, who've been permitted to invade clinical medicine), a domain in which they are most often manifest laypeople, cannot let the doctors "ramble."
Uses up too many electrons - or something.
Case closed.
In a way this story reminds me of capricious, mission hostile IT limitations I heard about ca. 2002 or '03. I was demonstrating the Saudi Arabia-Yale Genetics Research Database (SAYGR) I'd authored in 1993-5 to world-class AIDS researcher Emilio Emini, in my role as Director of Scientific Information Resources, Research Information Systems division, Merck Research Labs where Dr. Emini was employed at that time.
SAYGR by design placed no artificial limitations on the number of descriptors for an entity, nor on the number of user-defined entities (such as lab test results and descriptors of the results) that could be created, even out in the field, by an enduser. Yet I'd developed it with early 1990's relational database technology.
Emini remarked that SAYGR was much more advanced than the database tools he was provided by the research IT dept., which fixed the number of descriptors to five or perhaps ten per item (probably thus avoiding the need to set up relational tables to make the programmer's job easier). This limitation was often insufficient for the needs of his advanced AIDS research. Again, brilliant.
I will add that there are many good jobs awaiting arrogant computer fools -- if only they'd be thrown out of the medical arena and replaced with IT personnel of a service mentality, who understand the limitations of lack of clinical knowledge and experience, and the asymmetric responsibilities, obligations and liabilities of clinicians compared to their own banal data processing jobs.
Deciding on lifeboat capacities for the Titanic, gas tank safety measures for the Ford Pinto, fail-safe systems for the Chernobyl nuclear power plant, and final launch decisions on the Space Shuttle Challenger in cold weather come to mind.
-- SS
1/4/11 addendum:
To those who might think a 1000-character text field limitation of a modern EHR is to save storage space that would have to be "reserved" or set aside to hold longer comments, just consider that your hard disk does not "reserve space" a priori to hold long files. The operating system allocates space dynamically as needed, up to rather massive limits per file set via internal OS and microprocessor addressing characteristics.
My aforementioned SAYGR application, initially developed with early 1990's relational technology, limited comment and impression fields as well - but to appx. 65,535 (64k) characters maximum. The workstations it ran on in the field had precisely 16 megabytes of RAM and 500 megabyte hard drives. (Yes, mega-, not giga-.)
I believe health IT vendors in 2011 can do far better than 1000-character impression fields.
Others have commented on possible workarounds to this limit. To them, I remind them of this simple wisdom I first posted at my series on mission hostile health IT:
"You should not have to work around something that is not in the way."
-- SS
