The Doctor vs. Char Limits

http://well.blogs.nytimes.com/2010/12/30/the-doctor-vs-the-computer/?hp

by robg • 16 years ago

131 67 16 years ago

well.blogs.nytimes.com

Semiapies9• 16 years ago

Not just absurd text-entry limits, but UI designs affecting data-use habits.

"Nobody, for example, leafs through a chart anymore, strolling back in time to see what has happened to the patient over many years. In the computer, all visits look the same from the outside, so it is impossible to tell which were thorough visits with extensive evaluation and which were only brief visits for medication refills. In practice, most doctors end up opening only the last two or three visits; everything before that is effectively consigned to the electronic dust heap."

That's a fucking terrible design.

DanI-S• 16 years ago

So is this:

The system encourages fragmented documentation, with different aspects of a patient’s condition secreted in unconnected fields

I'm pretty sure that problem was solved in the 60s, with the concept of hypertext. Decades of progress resulting in the Internet have somehow escaped these guys.

pyre• 16 years ago

The thing that isn't clear to me: Is this some sort of medical profession electronic document 'standard?' Or is this doctor just running up against the limitations of a single vendor's solution to an issue that has no standards?

Semiapies9• 16 years ago

Good question.

nradov3• 16 years ago

The medical profession has an electronic document standard in HL7 Clinical Document Architecture, Release 2. http://www.hl7.org/v3ballot2009may/html/infrastructure/cda/c... It's an XML format so there is no character limit on narrative sections. Apparently that one vendor just decided to impose an arbitrary limit for no good reason.

joe_the_user3• 16 years ago

Could it be for backward compatibility with something else?

A lot of medical data processing is spread through a huge series of SQL and mainframe databases with lots of hacks to keep them roughly compatible.

A friend worked medical database where "sex" was a seven field containing values from {"F", "M", "Male", "woman"...} etc.

This is horrific but it's possible to imagine that it arose as a compromised between various equally terrible options...

adolph• 16 years ago

HL7 is primarily used as an interchange format, not storage. Does any currently used system actually use the CDA or EHR model?

drinian2• 16 years ago

1,000 characters? What, are they paying for storage by the byte? Was this system designed in 1960? For that matter, were any doctors involved in the design of the system?

How on earth do they store medical imaging, compress it down to 128x128 GIFs?

akavlie• 16 years ago

Medical imaging is probably in systems and hard copies completely disconnected from (and inaccessible by) the database.

drinian2• 16 years ago

You're probably right, although that's another problem. I've heard (this is not my area) that most of the big, expensive machines all use their own proprietary image formats.

Although I once had some emergency dental work done in New Zealand, and they were able to give me a laser-printed copy of their digital X-ray along with a printout of my EMR as I was walking out the door.

rdl3• 16 years ago

Right -- the medical images go into something called a "Picture Archive and Control System", or PACS, which is separate but should be linked to the EHR/EMR. The PACS is basically a file server with some metadata which speaks a stupid old protocol (DICOM) to the x-ray, and which also speaks to expensive computers with FDA-certified high-res (WUXGA or higher) B&W or color monitors (like, $10-20k for a monitor, and 2-3 monitors per workstation).

Absolutely none of it is that difficult from the perspective of a green field software development effort, but there is huge complexity in making the PACS or EHR operate correctly with ~every idiosyncratic device, other EHR or PACS, or configuration request at every site in the world. Because the IT systems are often sold with a lot of consulting services to implement, and with medical imaging devices (for PACS), there isn't a lot of incentive to make everything plug and play.

I think the best solution would be for a very large healthcare organization to actually require a standardized system at a low price, and make it available to everyone. (an organization like Kaiser or Sutter Health would probably have enough scale). Develop something which works with entirely comforming devices, has much lower configuration, and is user friendly and cheap, at the cost of customization. In the long run, it would be cheaper -- it's just that the people in the medical IT purchasing industry don't think like product people, they want consulting and services and handholding.

There have been plenty of people killed or seriously injured by errors directly related to medical IT systems. Just in radiology, just recently, http://www.nytimes.com/2010/01/24/health/24radiation.html?pa...

yummyfajitas• 16 years ago

An MRI of my abdomen only outputs 256x512 images. Medical images suck.

dedward• 16 years ago

An MRI maybe - but a digitized X-ray is much, much higher than that.

pmorici• 16 years ago

A 1000 caracter limit is pretty common for a long form text field in PeopleSoft applications and for what ever reason PeopleSoft is really popular for building horrendous HR, business process and other records keeping business software.

dowskitest2• 16 years ago

I think this is a good reminder to thoughtfully consider how we handle edge cases.

I know that I often treat edge cases with the least care. This is certainly a situation where the opposite required.

Semiapies9• 16 years ago

Why do you see this as an edge case?

niels_olson3• 16 years ago

doctor, here. This is definitely not an edge case.

dowskitest2• 16 years ago

As soon as they defined that 1000 char limit, they set a hard edge. The use cases that hit that limit are then the edge cases, at least in the minds of the developer(s).

I was just suggesting that there should be more consideration of how software will be used in ways that hit limitations.

kevingadd• 16 years ago

“Well, we can’t have the doctors rambling on forever,” the tech replies.

Is medicine like this elsewhere now, too? The idea of having the quality of my medical care determined by grade-A morons in an IT department terrifies me even more than having the quality of my medical care determined by bureaucrats at the HMO main office.

Knowing which specific insurers/hmos/etc have restrictions like this on medical documentation would also be great when choosing where to get your coverage, but I bet regulations like HIPAA would prevent people from naming names.

Semiapies9• 16 years ago

A guy at a help desk says something inane like that to dodge being recorded ("for quality assurance") as bad-mouthing the product. He didn't code that app or set that field size.

Setting a field size that stupidly small could have a lot of causes, from a lazy coder who figures 1000 characters is enough to an actual directive from an executive saying that they don't want long assessments. (I've had higher-ups in a client's company tell me to do just that, in other contexts.)

In any case, it remains fucking terrible.

burgerbrain• 16 years ago

A more acceptable response would be "Thank you for your feedback, I'll pass it on."

In fact "we did that on purpose" is possibly one of the worst things he could say. What authority does he have for making that assertion, was he on the design team? He's putting (rather rude) words into the mouths of the people who built the system.

joe_the_user3• 16 years ago

I don't think there's any dodge there.

He could have said "we don't care, we don't have to". In a lot of ways, that is what he said. It's just appalling...

mistermann2• 16 years ago

This is depressing in so many ways...just a few:

The software he is using is obviously extremely poorly designed:

"It turns out that in our electronic medical record system there is a 1,000-character maximum in the assessment field."

- Unreal. No further comment necessary.

"In practice, most doctors end up opening only the last two or three visits; everything before that is effectively consigned to the electronic dust heap."

- Opening individual windows for each visit is ridiculous, this should be viewed through a historic report at least (as well as a thousand other subtle smart features).

"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."

- Why is a doctor be typing this stuff in? This should be spoken and recorded permanently, and transcribed by a qualified person into text.

And, maybe it's just me....I don't expect doctors to be experts in software design, but I would like to think doctors would be of average to above average intelligence...these shortcomings should be obvious to him as poor design as a reasonably intelligent person who has interacted with many forms of software in his day to day life and recognized as such - but from the article, he seems to think these are natural tradeoffs that must be made when switching to an electronic format.

brendano• 16 years ago

Medical electronic record systems are almost always poorly designed like this one. That's why doctors perceive such deficiencies as "natural."

mistermann2• 16 years ago

I would hope that my doctor uses mainstream technology (internet, iPad) and could differentiate between what is "common" and what is possible.

If one isn't able to do that, I would seriously question their ability to properly diagnose complex ailments.

aamar• 16 years ago

The problem is a bad feedback loop. Doctors need to demand an adequate user-experience, and buyers of these systems need to include user-experience "intangibles" into their decisions.

I'll play sort of a devil's advocate here as someone who's worked in this field: the feature-gaps identified aren't all that bad.

- 1k-assessment limit: It's not ridiculous; assessment-notes are usually 0-2 acronym-laden sentences, probably under 200 characters in general. Writing a 1k-long assessment note seems extremely unusual and I think in many situations would be completely loathed by co-practitioners, who need to very quickly read visit notes (the assessment is just one field out of dozens or hundreds). An inexperienced doctor could easily be reprimanded for such verbosity. However, there are many different working and documentation styles which work better for certain patient populations, specialties, institutional needs, etc. -- this doc may absolutely be justified in wanting to be thorough in this situation. A call from an experienced doc should be investigated and most probably addressed in future versions of the software.

- Reviewing past visits: The EMR probably does have some kind of history report/index view into the list of past visits, but the problem here seems to be that the index doesn't have the right data in it. The doc wants to review in detail the "thickest" or most important notes, so you need to display that into the index. It's a good feature idea, but not an obvious one.

- Dictation: It's disruptive and awkward to dictate in front of patients. So typing/writing while talking to the patient is generally more efficient, even if the doc has to wrap up after the patient has left. For work that is entirely done when patients are not present, dictation is a fine solution and in fact is used by many, many docs, integrated into EMRs, etc.

One issue, not explicit in the article but possibly relevant, is that managers often use constraints in enterprise software in order to control end-users. Field-lengths sometimes come out of these ("They're wasting time! They should move onto the next [patient/customer/widget/etc.]!"). But the problem there is poor communication & lack of agreement between management and workers, rather than an outright deficiency in the IT itself.

megablast• 16 years ago

Most doctors have themselves to blame, they hate change, they hate tech, they hate having to learn something new. Even if it is to do with there specialty, they have to be forced by the government to study new stuff. There is a huge industry around getting drs to go study new stuff, which they are paid to do.

Doctors hate change, they want to keep things as they are. For most non complicated consults, people are much better of with a smart system rather than going to talk to a bored dr, but drs do not want to give up their control.

NTH• 16 years ago

I agree - the author seems to think that problems with a particular design are intrinsic to any electronic solution.

miniatureape• 16 years ago

These services will be in place for years and more and more institutions will depend on them. The computer systems we design for health care will shape health care service.

Add Joseph Weizenbaum's Computer Power and Human Reason to the list of books that the developers of these systems should be required to read.

naner• 16 years ago

So the software is shit, like most special purpose business software. The tech's response isn't what justified the software limitations, it is the other way around. Nobody really wants to design or build this stuff so this is what they end up with. I've seen it hundreds of times. (I used to do consulting for small businesses and interned with an engineering contractor before that.)

Semiapies9• 16 years ago

We clearly need a way to make medical data systems sexy enough that talented, skilled folks build startups to try to horn in on the market.

No, I'm not being flippant or joking.

It would be a fantastic thing if even a handful of people see this story, go, "I could shit out better software then that!", look into HIPAA and other complications, consider a moment, then say, "I could still shit out better software than this," and get to work challenging the status quo.

shrikant• 16 years ago

T. H. I. S.

I would narrow it down to "nobody wants to design this stuff" - in most enterprise software shops (mine, for e.g..), the 'sexy' jobs are either purely on the technical side ("let's code!"), or purely on the business side (account/relationship management).

Nobody wants to to the bridge stuff - the actual hard work of translating the business requirements into a half-way decent technical spec that the "let's code!" group can get cracking on. And this is true from both the buyer and seller's sides.

I suppose that this is because in such places, people's contributions are 'objectively' evaluated by either revenue generated or LOC, and the poor business analyst has no such conveniently measurable metric attached to her.

niels_olson3• 16 years ago

I'm a doctor, this sort of thing happens all too often. In my case, yesterday, a module of AHLTA crashed in the middle of my note and I had to restart to continue. The mouse functions in AHLTA don't support cut and paste, but luckily no one coded out ctrl-c and ctrl-v, so I was able to save a copy of my new patient's three separate complaints under ctrl-v while the system reloaded. Our system is designed with the idea of writing the note with the patient in the room (we don't even have a separate office, just the exam room and a corpsman). Fortunately my patient was herself in IT (one complaint was ... low back pain) and she was very understanding. But I'm also faced with the problem that I either choose to look at the patient or the computer. The computer is not at a convenient angle for this.

So I'm forced to either spend less time with patients and write the note afterwards, physically not look at them, see fewer patients, or write my notes in the evening after the patients have started to fade and blur together.

I actually brought in my iPad yesterday, but didn't even get through the door before I realized there would be no HIPPA-compliant way to move the information from my iPad to AHLTA, especially since I don't have ready access to encryption tools. I thought about issh, but it only adds a third computer to the security perimeter.

Anyone interested in developing a web-based medical records system with a doctor who can at least work through code, I would love to talk with you.

rdl3• 16 years ago

For 2008-2010, I had the pleasure of working with doctors who had to use AHLTA, AHLTA-T, and various MC4 systems (I supported a teleradiology system which interfaced loosely with it), in places where the doctors also had to carry the M9. This was an exciting job and I am glad to not be doing it anymore.

There are plenty of ways the iPad could be used in a HIPAA-compliant way to access EMR/EHR, and I know of a few startups working on it. I think DoD and VA would be great users of things like this, but realistically innovation is probably going to happen in non-US markets first, and in government US markets last, due to the long approvals process and purchasing cycle. One of the easiest would probably be for telemedicine projects, possibly funded by USAID or charities or military CA, to support clinic operations -- some of the civilian hospitals in Afghanistan actually had better IT systems than the US military hospitals (!!!).

lukev2• 16 years ago

Sounds like an interesting problem... I sent you an email.

EDIT: Could you email me? The only email address in your profile bounced...

niels_olson3• 16 years ago

that's my email, it works. I don't see anything from lukev and your email is unlisted.

Since I can't edit my original post any more, let me also add that I did a summer internship with Edward Tufte and have done analytic design consulting work and helped build and design one web app (tmedweb.tulane.edu).

Hope you can get back to me.

mkramlich• 16 years ago

Posts like yours are gold for folks trying to build a health software-related startup. thanks for sharing. However, I'm personally avoiding that sector due to government/legacy/bureaucracy issues, but I hope to hell that others innovate the heck out of it, while at the same time not making it worse than before (dumb character limits, for example.)

2mur• 16 years ago

Hey Niels- I'm a military doc too so I feel your pain on AHLTA. Fortunately, I only have to go to AHLTA to read notes, since in pathology we use a separate system for entering reports.

Pathology really needs a web-based system also. Our existing Lab IS's are all enterprise monstrosities.

ZachPruckowski• 16 years ago

This article sounds like it's trying to say that electronic medical records are a bad idea, but all I'm hearing is "our vendor's software sucks ass". I mean, none of these limits are that tough to fix. If there's a need to tell which visits on a list are long ones and which are short, we could color-code based on duration or just display the duration of each visit in the list, for instance.

Semiapies9• 16 years ago

This is what happens when users get conditioned by really bad software in a specialist market.

pragmatic• 16 years ago

Start your own practice and get your own software?

How viable is that (genuinely curious)? How easy is it for a doctor to start a private practice?

Devilboy• 16 years ago

If you use your own system you're cut off from the rest of the medical universe. These systems are integrated with the pathology guys next door, the pharmacist down the road, the medical imaging center and so on. Everyone benefits from this so if you decide to use your own homebrew system you'll make life more difficult for everyone else around you.

jrockway• 16 years ago

Yeah, but if we used TEXT instead of VARCHAR we might need two disk reads to look up the data instead of one! Fuck human life, think of that poor hard drive!

bena• 16 years ago

Healthcare Informatics is a ghetto (to paraphrase Zed Shaw). No one who cares enough about healthcare cares enough to learn how to develop decent applications and no one who knows how to develop decent applications cares enough about healthcare.

So what you get is a bunch of people who would rather be doing something else but for some reason cannot. Strictly middle to low tier developers. Anyone who is decent gets out of the industry quick due to the huge amount of inertia the established companies have.

Someone mentioned HL7 CDA being an XML format. It is now. HL7v3 was published in 2005. HL7v2 was standard before that and if you have to deal with equipment or software made before 2006-2007, you will need to dive into the fun that is HL7v2.

nradov3• 16 years ago

Just to be clear, it was the CDA R2 portion of the HL7 V3 standard that was published in 2005. Other parts of HL7 V3 were published earlier, and some parts are still not done yet. There is no HL7 V2 version of CDA.

Even older versions of HL7 V2, such as V2.3 published in 1997, specified a minimum supported length for individual observations of 64K (OBX-5 field). So we can't blame HL7 for this particular problem. Of course many vendors have defective HL7 interfaces.

I can't speak for other vendors, but at my company we have been able to attract top tier developers (and are hiring more).

tgflynn2• 16 years ago

Are there any speech to text systems for medical records ?

It seems like speech recognition technology has reached a pretty high quality level. Of course there would be some transcription errors. What if the system had an editor window that required the physician to verify and sign off on the transcription ?

Wouldn't speech be a better primary interface for this application ?

nradov3• 16 years ago

My company includes back-end speech recognition in our transcription workflow. http://www.axolotl.com/news/57-axolotl-adds-speech-understan... Human editors review and correct the draft report, and then it goes to the physician for a final review before becoming part of the patient record

Some physicians also prefer to enter text directly into our web application with third-party front-end speech recognition products such as Dragon. http://www.nuance.com/for-healthcare/index.htm

tgflynn2• 16 years ago

It sounds like your system should be light years beyond the problems that are being discussed in the article and in this thread.

LargeWu• 16 years ago

This serves as a great reminder that great software is about a lot more than great code.

For the most part, this sounds like a large but basic CRUD app, which is basically a solved problem from a technical point of view. Most of the key decisions in the software development process are not necessarily made by programmers.

davidw• 16 years ago

He's not "The Doctor" - he's "a doctor". The Doctor would have fixed the computer with his sonic screwdriver.

ok-computer• 16 years ago

I'm not sure this is _why_ there is a limit of 1000 characters, but one possible reason would be to limit the amount of unstructured data put into the assessment field. This can be a way to force people to use structured data fields and more generally to avoid excessive verbosity.

(TLDR probably applies to doctors too.)

Lanark• 16 years ago

A ton of usability research in this area has been done by The Microsoft Health Common User Interface http://www.mscui.net

It's a pity (and rather ironic being Microsoft) that none of the major healthcare IT suppliers seem to want to follow a common standard.

willholley• 16 years ago

As a vendor in the UK, we have been integrating the CUI for the last few years. The quality of the guidance is mixed - there is good evidence that having a "Patient Banner" in a consistent format prevents "right thing, wrong patient" problems. However, a lot of the evidence supporting the other guidance is sketchy. They also lean heavily on MS implementations of the guidance which I would think most vendors will avoid because it does not likely fit into their technology stack (Silverlight / WPF).

However, the real problem is that the market does not value good usability. We are lucky if a potential customer has even heard of the Common User Interface, let alone specifying it as a requirement on a tender.

The "ghetto" effect described by another poster is largely down to the "market for lemons" around healthcare IT, in the UK at least (many different vendors promising a silver bullet to hospitals with no experience in procuring such things - they just pick the cheapest / "least risky").

The Doctor vs. Char Limits

Related Stories