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.
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.)
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 (!!!).
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).
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."
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.
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.
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.
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.
“Enterprise” software, as a rule, has horrible user interfaces. The people who buy this kind of stuff are three layers of management removed from the people who actually use it, the software is often customized, and quality of user experience is not a critical factor in the purchasing decision.
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.
If you pick up a book on best practices in development of enterprise software, it is basically a catalog of obviously beneficial things that people fantasize about in the pages of a book because they are never allowed to do them in real life.
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.)
Privacy laws and regulations restrict what doctors can do with technology. I'm mostly happy about that obstruction, just because I know who has the greatest interest and ability to influence medical IT (the insurance companies) and what their motivations are (sell private information, deny claims, only cover healthy people.)
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.
But the thing is, biological systems are incredibly complex and poorly understood. So in a biological system, you can't say "we can do X so it should be an easy step to do Y".
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.
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.
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).
“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.
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.)
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.
Agreed on the more acceptable response, but the corporate culture of the company may not make that the worst thing he could say in terms of staying employed.
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.
Agreed, there is probably no feedback system whatsoever, and the IT guy is almost certainly more powerless than the doctor. Which points to the real problem - it's usually the administrative staff that signs off on the software requirements with feedback only coming from other administrators. At least, that was the predominant trend for electronic medical records during the 90s and the earlier part of the past decade.
"we did that on purpose" is engineering's exact reasoning behind every single bug we've discovered in our system's architecture. This is not an atypical response, this is a standard experience. I personally have discovered bugs that can shut down parts of our system, and these bugs are there "by design."
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.)
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.
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.
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.
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.
Actually, I unfortunately know a fair bit about medical imaging (since I supported radiology systems for a couple years).
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 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.
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?
The medical profession has an electronic document standard in HL7 Clinical Document Architecture, Release 2.
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.
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.
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 ?
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.
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.
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").
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.