"Wise men learn more from fools than fools from wise men." - Chinese proverb
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 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.
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.
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 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.
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.
... 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
15 comments:
"In desperation, I call the help desk and voice my concerns. “Well, we can’t have the doctors rambling on forever,” the tech replies."
I guess that only the computers and hospital administrators have a right to ramble on with pages of legible gibberish; with one exception, the "cut and paste" default mode of 7 page progress notes, providing the illusion that the doctor (or the "cut and paste" team) was thinking about the patient instead of about the EHR and constructing a bill for maximal services.
These devices are terrible for the care of complex patients. The device makers and their programmers designed them to help doctors manage hangnails.
Morons, aka CPOE, EHR, and/or clinical decision support (CDS), have taken over medical care, serving up impediments to safe, effective, and individualized care.
Let me clarify, the programmers who have nothing to do with medical care, have designed dangerous workflow systems, unfit for purpose.
Doctors are wimps in their failure to rebel against this takeover of their profession.
Doctors are wimps in their failure to rebel against this takeover of their profession.
This is sadly true. Search on "learned helplessness" on this blog.
-- SS
Anonymous at January 2, 2011 6:49:00 AM EST wrote:
I guess that only the computers and hospital administrators have a right to ramble on with pages of legible gibberish
These facilitators of care have only the rights that the enablers of care, the physicians, permit them to have.
-- SS
Would any physician rely on a librarian for legal advice?
Would a lawyer rely on a colleague for medical advice?
Would a mechanic rely on a gunsmith to repair a BMW?
So, how come hospitals and health care systems rely on coders to do medical charts?
Re: Cetamua said...
Would any physician rely on a librarian for legal advice? Would a lawyer rely on a colleague for medical advice? Would a mechanic rely on a gunsmith to repair a BMW?
By "coders" presume you mean programmers, not billing coders?
Physicians relying on non-clinical IT personnel reporting to non-clinician executives (CIO's) to create and control important medical devices (i.e., EHR's and related clinical IT) shares the same illogic as your examples.
-- SS
RE: SS asked:
By "coders" presume you mean programmers, not billing coders?
That is correct.
The lack of clinically knowledgeable people mingling into EHR's and clinical IT is a testimony to how dysfunctional health care is.
A cousin of mine works as an engineer for an avionics company. The idea of letting coders and software architects designing simulation systems for his industry without these guys and gals being on a VERY tight leash is utterly laughable to him.
When I told him how it was done in health care, he didn't have anything nice to say.
Cetamua said...
A cousin of mine works as an engineer for an avionics company. The idea of letting coders and software architects designing simulation systems for his industry without these guys and gals being on a VERY tight leash is utterly laughable to him.
I've been writing on similar observations for over a decade now. As I wrote ca. 1999 at my then-new site "Medical Informatics and Leadership of Clinical Computing":
This web site in large part originated from observations of MIS personnel leading clinical computing projects and wielding considerable authority over clinicians on decisions affecting medical environments and resources. These observations led to questions such as "who are these personnel, and what is their expertise? What metrics are applied to their activities?" After years of rigorous clinical and informatics training, these questions about healthcare MIS were found to leave much room for contemplation.
These questions have still not been answered satisfactorily.
Leadership by amateurs seems a disease of our times.
-- SS
The comment size in that assessment had nothing to do with RAM or disk space. There are lots of variable types used to input data. In this case it sounds like the site set up an assessment with a text variable with a size limit based on the language used to write the app. They could have used a multiple line text type field, but chose not to. None of which has anything to do with the vendor (or RAM or disk size).
Extra points for explaining why the limit is 1000. I know the reason. I guarantee that you do not.
The comment size in that assessment had nothing to do with RAM or disk space.
That's what I was trying to explain for laypeople, in layperson terms.
Extra points for explaining why the limit is 1000. I know the reason. I guarantee that you do not.
A guess. Something like this in some ancient version of Sybase?
create table foo
( string1 varchar(1000),
string2 varchar(1000)
)
Warning: Row size (2015 bytes) could exceed row size limit, which is 1962 bytes.
First of all, you are wrong about how assessment screens are set up. They are not coded by the vendor. That would give hospitals no flexibility. Vendors provide the tools that sites use to set up the assessment screen. Sites set up the prompts and link them to response types (integer, decimal, text, yes/no, etc). These are then added to screens.
Next, there is no point to intentionally setting up a text length of 1000. You're either going to limit the text length to about 80 (so it will fit on one line), or you're going to set up a multi-line text response with no limit. Most likely the 1000 limit is due to the user who set up the assessment not assigning a limit, so the limit is determined by the language used to write the app. A 16 bit language will have a theoretical limit of 256 (the real limit is actually a little less). A 32 bit language will have a limit of 1024. I think you can now see why the limit in this example was 1000.
Third, if the assessment screen layout has flaws, it's most likely not the fault of an IT person. Docs may not set up the screens, but a doc should check screens before they are used. If a doc approved this screen, that is not the fault of the vendor.
Note to readers:
Anonymous January 6, 2011 9:51:00 PM EST writes:
Most likely the 1000 limit is due to the user who set up the assessment not assigning a limit, so the limit is determined by the language used to write the app. A 16 bit language will have a theoretical limit of 256 (the real limit is actually a little less). A 32 bit language will have a limit of 1024.
"Limited by the language used to write the app?"
This statement is nonsensical. It perhaps applies to string variables in the Microsoft Basic interpreters loaded into TRS-80's in 1977, but not much else.
The length of a text string as stored in a relational database is not limited to the microprocessor/software architecture (e.g., 16 bit vs. 32 bit, or vs. 64 bit for that matter) in that manner.
Rather than go into technical detail, I'll simply state that even memo fields in the ancient dBase databases of the late 1970's running on archaic 8-bit computers could store large text fields, via pointers (addresses to the location where the long text fields resided on disk).
Further, if the anonymous commenter's comments had merit, you would only have been able to store word processing documents of 256 characters on that 8-bit TRS-80, since the value of an eight bit binary number can range from 0 to 255 in base 10. Or 65,536-character documents on a 16-bit IBM PC.
(The anonymous commenter was also incorrect in claiming a 256-character limit to a 16 bit software or hardware architecture, since a 16 bit binary number ranges from 0 to 65,535 in base 10.)
The rest of the comments are similarly in error, other than the final one - "a doc should check screens before they are used."
In fact, approval and modification of screens is usually interfered with by IT personnel in hospitals.
I note the comment at the NY Times blog post on the 1000 character limit "The Doctor vs. the Computer" here:
Comment 119 ... I am a family doctor who has the privilege of taking care of many pregnant patients as well as many persons who have hepatitis B, a common viral infection that can cause liver failure and liver cancer .. it is helpful to know the status of each patient’s immunity against certain infections ... In a paper chart, I simply would have written, “Immune,” on the immunization record, following the name of the infection. But our EHR has no way of documenting immune status. I have requested an “upgrade” by speaking the the physician liaison. [Liaison to the IT dept. - ed.] Repeatedly. For the last four years. [Emphasis mine - ed.]
That's a typical scenario.
Alas, the words in another comment at that NY Times story seems apropos:
As Konrad Adenauer, great man who would probably be confused with some old-time actor or comedian by today’s hip techno-geeks and trendies, put it so well: “The good Lord saw fit to limit human wisdom but not stupidity, and that just isn’t fair.”
-- SS
Another point I'd like to add. Even ca. 1976-7, Microsoft Basic (MBASIC) for the Intel 8080/Z80 8-bit CPU's could store 255 character text strings.
Per Wikipedia and the MBASIC manual available online:
MBASIC supported the following data types:
* 8-bit character data, in strings of length 0 to 255 characters;
* 16-bit integers;
etc.
I'd in fact used BASIC character strings of appx. 92 characters ca. 1979 on a Z80 machine using MBASIC in storing the game board for a game of 3D Tic Tac Toe I'd originally written in 1971.
I'd ported my program from an earlier version I'd written around 1976 for my college's IBM370 mainframe using the IBM Call/360 BASIC dialect. I had ported that from my original 1971 version written in Hewlett Packard BASIC on an HP-2000C timesharing system in high school.
The board below was stored in a single character string in 8-bit BASIC:
.... .... .... ....
.... .... .... ....
.... .... .... ....
.... .... .... ....
The point of all this:
You'd think that after 30+ years, producers of health IT could have done better than increasing the 256-character string limit of a TRS-80 by a factor of 4 for arguably the most crucial note a physician can write, the assessment.
-- SS
My comment threads of late seem to be attracting a lot of attention from the Boston area, both from Meditech IP's and from a private-ISP's IP, apparently using the same type of equipment and OS.
The pattern is a hit on the main site page, then an outclick to the comments sections of various posts - such as this comments thread.
This has been going on daily for many weeks now. It may be a script, it may be a person, it may be a team monitoring the blog and submitting generally inane comments (see my earlier Sockpuppet posts, e.g., here).
Per Sitemeter data I've posted at the link below, in just the past day there were such hits at Jan 8 2011 5:51:41 pm, 7:29:05 pm, 10:46:20 pm, and even in the wee hours of Jan 9 2011 1:22:06 am, then Jan 9 2011 9:53:14. This time pattern is typical as well.
The outclick is always to a comment thread where some inane comment had been received from the same IP.
The tracking data is at this link.
Instead of correcting mission hostile health IT's user experience, it seems there are those who'd apparently rather monitor blogs for 'naughty' thoughts about HIT.
-- SS
Post a Comment