The Doctor vs. Char Limits
well.blogs.nytimes.com
well.blogs.nytimes.com
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.
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.
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.
He clearly wasn't coached to say "I'll pass it on" and was floundering to respond to a person who was upset over what the help desk guy could easily recognize was a real flaw in the software, while obviously not feeling remotely secure in saying anything that might even suggest that this was a flaw.
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...
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.
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 (!!!).
EDIT: Could you email me? The only email address in your profile bounced...
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.
Pathology really needs a web-based system also. Our existing Lab IS's are all enterprise monstrosities.
"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.
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.
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.
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.
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.
Assume the doctor has a working system that enables them to do their job, without being distracted by having to learn new, irrelevant procedures. Any new "better" system has to provide really tangible benefits to be worthwhile learning. If that new system has been designed by administrators, for the benefit of administrators, then it's little wonder that the doctors are resistant to change.
If one isn't able to do that, I would seriously question their ability to properly diagnose complex ailments.
From the perspective of a non-geek who works in a medium-to-large company, bad “enterprise” software is just an irritation that goes with the job, like bad coffee. You may complain about it but you don’t seriously expect it to be fixed.
For instance, talking to prospective users. The importance of this has been stressed over and over again and is no longer disputed. In fact, when an in-house team started designing changes to an accounting app my friend had to use, there was an official user expert designated to work with the developers. The user "expert" was her manager, who had never used the application that was being changed, had never used a similar application, and had never even done a job similar to the one done by the users. What's more, she forbade the developers to speak to the users because she didn't want the development effort to affect their productivity. Oh, it did affect their productivity eventually, believe me it did.
(It's an exaggeration to say it's uniformly terrible; I had a good experience with the one enterprise app I built, but it was for a network operations team, so they understood a lot about software and about the need to be generous with time and access.)
A guy in the oil business once told me a story about why Bangladesh's gas fields have not been thoroughly exploited yet. Basically it was a big tangle of political crap -- and according to him, Bangladeshis are very happy not to have the gas fields exploited, because they assume that both the current leadership and the opposition party are so corrupt that all the money would be stolen anyway, so it's better if the gas is not exploited until the far future when some of the money might go to the people. I have no idea if that's true or not, but it captures why I'm mostly glad that the use of technology in medicine is stuck in the dark ages. Until there is some stakeholder involved who gives a crap about patient rights and privacy (the doctors care about effective treatment, but not rights or privacy) it's best if nothing changes at all.
If one was reasoning about a computer in the way you have to reason about a biological system, there wouldn't be any reason to think that since you can create with a browser unlimited character field it, you can create a medical transcription system with an unlimited character field.
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.
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).
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.
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.
How on earth do they store medical imaging, compress it down to 128x128 GIFs?
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...
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.
There's a ~1980s protocol called DICOM which is largely used to transport images around. It is quite complex for what it actually, has lots of vendor and device inconsistencies, and because medical imaging devices are expensive and have a long duty cycle, you can have a 10-20 year spread of equipment on your network.
Some of the actual imaging technologies (MRI, CT, US) are inherently low resolution per image in a study (due to the limits of physics), but a study can be composed of a bunch of images, and it can end up 5-10GB. The high-resolution individual images tend to be x-ray, especially digital mammography.
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...
Essentially, sex is biological while gender is social. Transsexuality is a disparity between what someone was born biologically as (sex) and what they identify as (gender).
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 ?
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
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.
(TLDR probably applies to doctors too.)
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.
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.
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").
I know that I often treat edge cases with the least care. This is certainly a situation where the opposite required.
I was just suggesting that there should be more consideration of how software will be used in ways that hit limitations.
How viable is that (genuinely curious)? How easy is it for a doctor to start a private practice?