The Doctor vs. Char Limits(well.blogs.nytimes.com)
well.blogs.nytimes.com
The Doctor vs. Char Limits
http://well.blogs.nytimes.com/2010/12/30/the-doctor-vs-the-computer/?hp
18 comments
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.
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.
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.
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.
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."
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...
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...
There's no "we" when it comes to some guy working the help desk.
[deleted]
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.
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 (!!!).
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 (!!!).
Sounds like an interesting problem... I sent you an email.
EDIT: Could you email me? The only email address in your profile bounced...
EDIT: Could you email me? The only email address in your profile bounced...
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.
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.
Ach, sorry, didn't realize mine was unlisted. Ok, I tried using the HackerNewsers contact link, we'll see if that gets through.
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.
Pathology really needs a web-based system also. Our existing Lab IS's are all enterprise monstrosities.
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.
"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.
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.
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.
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.
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.
Medical electronic record systems are almost always poorly designed like this one. That's why doctors perceive such deficiencies as "natural."
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.
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.
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.
Everyone hates change and with good reason.
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.
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.
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.
If one isn't able to do that, I would seriously question their ability to properly diagnose complex ailments.
“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.
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.)
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.
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.
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.
I agree - the author seems to think that problems with a particular design are intrinsic to any electronic solution.
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.
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).
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).
He's not "The Doctor" - he's "a doctor". The Doctor would have fixed the computer with his sonic screwdriver.
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.
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.
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.
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.
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?
How on earth do they store medical imaging, compress it down to 128x128 GIFs?
An MRI of my abdomen only outputs 256x512 images. Medical images suck.
An MRI maybe - but a digitized X-ray is much, much higher than that.
Medical imaging is probably in systems and hard copies completely disconnected from (and inaccessible by) the database.
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...
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...
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.
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.
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.
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.
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...
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...
I'd assume that the actual data is kept in a column in a table (one that's only 1000 characters long) and only output in the XML format.
Reminds me of a health insurance form I filled out where it asked you for your gender, but never your sex.
For the curious: http://www.who.int/gender/whatisgender/en/index.html
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).
See also: http://www.docstyles.com/apacrib.htm#AppA
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).
See also: http://www.docstyles.com/apacrib.htm#AppA
HL7 is primarily used as an interchange format, not storage. Does any currently used system actually use the CDA or EHR model?
Good question.
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.
This is what happens when users get conditioned by really bad software in a specialist market.
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 ?
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 ?
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
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
It sounds like your system should be light years beyond the problems that are being discussed in the article and in this thread.
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.
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.
(TLDR probably applies to doctors too.)
(TLDR probably applies to doctors too.)
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.
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.
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.
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.
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").
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 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.
I know that I often treat edge cases with the least care. This is certainly a situation where the opposite required.
Why do you see this as an edge case?
doctor, here. This is definitely not an edge case.
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.
I was just suggesting that there should be more consideration of how software will be used in ways that hit limitations.
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!
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?
How viable is that (genuinely curious)? How easy is it for a doctor to start a private practice?
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.
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.