Kludgey Electronic Health Records Are Becoming Fodder For Malpractice Suits 184
Lucas123 writes The inherent issues that come with highly complex and kludgey electronic medical records — and for the healthcare professionals required to use them — hasn't been lost on lawyers, who see the potential for millions of dollars in judgments for plaintiffs suing for medical negligence or malpractice. Work flows that require a dozen or more mouse clicks to input even basic patient information has prompted healthcare workers to seek short cuts, such as cutting and pasting from previous visits, a practice that can also include the duplication of old vital sign data, or other critical information, such as a patient's age. While the malpractice suits have to date focused on care providers, they'll soon target EMR vendors, according to Keith Klein, a medical doctor and professor of medicine at UCLA. Klein has been called as an expert witness for more than 350 state or federal medical malpractice cases and he's seen a marked rise in plaintiff attorney's using EMRs as evidence that healthcare workers fell short of their responsibility for proper care. In one such case, a judge awarded more than $7.5 million when a patient suffered permanent kidney damage, and even though physicians hadn't neglected the patient, the complexity of the EMR was responsible for them missing uric kidney stone. The EMR was ore than 3,000 pages in length and included massive amounts of duplicated information, something that's not uncommon.
Don't fix what ain't broke (Score:3)
While there's problems scheduling at the VA and getting in to see a doctor, they've had EMRs for 50 years. It's all online and easy to search.
Re: (Score:3, Insightful)
Re: (Score:3)
From an EMR standpoint? I find that attitude disappointing and shortsighted.
Re: (Score:2)
Re: (Score:2)
IOW "Government did it, government can't do anything right, therefore I don't like it" - I find that attitude disappointing and shortsighted as well.
Re: (Score:2)
Do not put words in my mouth. Government can do things right. Just not nearly the amount of things people want government to do, even if it is the worst possible thing.
The whole VA thing can be fixed, simply, by allowing Veterans to get treatment in a normal hospital. But that doesn't allow our Politicians to "look" into the abuses and "fix" the problem with ... more legislation!
Re: (Score:2)
http://www.cbsnews.com/news/va... [cbsnews.com]
Re: (Score:2)
"allows more" means "not all of them" and means "veterans are still at the mercy of our decisions"
And it was in direct response to the outcry from the public after the politicians didn't do anything other than lip service to the problems being exposed.
The fact is, the VA system still sucks, still has inordinate wait times for those that do not have the "get out free" card outlined in the news account you gave.
My actual solution would be to require congress to use the VA as their sole service provider. THEN
Re: (Score:2)
VA hospitals are much, much cheaper than "normal hospitals" (and for most physical injuries, have similar results). Are you willing to accept a massive tax hike to allow vets to get treatment in a normal hospital? Even if you are, most of your neighbors are not.
And TFA is about how the EMR in "normal hospitals", all bought from free-market companies, is horrible and can cause secondary health problems. The VA's EMR is actually very good, works well and has fewer problems than the commercial ones, cost a
Re: (Score:2)
So, you're supporting the lowering of health care costs by creating worse healthcare system? That is quite an admission.
Re: (Score:2)
I gave an example and backed it up with my personal experience with the caveat that this is about EMRs and not wait times, which an EMR can't really help much with. I'm not seeing much in the way of examples to counter the statements I made.
Re: (Score:2)
OSHA. Child Labor Laws.
There is 2.
Re: (Score:2)
The VA has many problems, but is also wonderful in some areas.
Their care for physical injuries and their EMR are both good. Their EMR, in particular, is fantastic, especially compared to much of the expensive commercial crap that most hospitals use.
Their care for mental injuries and their scheduling and administration are pitiful. Some of that is because the government refuses to fund them enough, but there are plenty of other issues there.
But none of the issues are exclusive to government-run health care
Re: (Score:2)
Re:Don't fix what ain't broke (Score:5, Interesting)
Re: (Score:3)
Nice. I worked for the VA for a few years in the early 90s, which is why I know at least how they operate. I think the bigger issue in the future is going to be translating records between institutions, just like the DoD and VA can't easily move records. When each system grows organically over time and doesn't think it'll need to communicate with others, it creates a huge problem when you do.
Re: (Score:2)
companies like Epic CAN, but OMG it costs a crapton for you to interface with them if you aren't on them already... and moving to them is incredibly expensive. it's a 15-20 year+ company decision to go with one of these companies.
Re: (Score:2)
EPIC itself is kludgey and cumbersome, but it somehow works. And yes, it's outrageously expensive.
Re: (Score:2)
Having worked on an Epic migration (Inpatient and Outpatient), I can say that Epic is a frigging mess. Massively expensive, almost totally inflexible by design, crap reporting (love reporting against a document database for up to the minute data), confusing to use and even more confusing to modify.
Epic training in no way covers how you will actually use the product.
Don't get me started on the Epic employees. Virtually every employee that came on-site was fresh out of college and only h
Re: (Score:2)
It happens because Epic burns out employees. Give them good money out of school and work them till they drop.
Still seems a step up from other systems right now.
Re: Don't fix what ain't broke (Score:2, Informative)
As someone who works for another government agency and has to read their records regularly... Their records are some of the most duplicative and annoying to read out of all EMRs. They frequently list medications a patient took a decade ago! They dump basically every single bit of medical evidence into every visit. Frequently every visit has uncompleted screenings for depression, PTSD, and alcohol abuse. There are other programs that are worse, but the VAs records are awful.
We've noticed the copy-pasting, bt
Re: (Score:2)
EMRs are dangerous in the hands of lazy doctors,
I'll grant you that. I think you'll see that over time doctors get better at it especially as older doctors retire and newer ones take their place. My daughter's pediatrician walks around with a tablet PC that he drops the information into and has already recorded things like the pharmacy we go to. "Still go to the CVS on Boston Road? Ok, it'll be ready when you get there"
and having seen most of the programs available and their output, a lot of it is because of lazy programming that makes simple tasks difficult.
That's just bad design. When I worked at the VA there was a good bit of discussion between developers and the people that actually u
Re:Don't fix what ain't broke (Score:4, Interesting)
I actually am a medical doctor and I can say that the VA EMR is very very good. It's not as shiny or pretty as some others out there, but it's solid, easy to use/learn, interconnected with every VA hospital and it's the same at every VA hospital. The scheduling problems largely revolve around lazy government employees (I'm a govt employee, so I can say that!) and trying to get doctors to work in the VA system. They only recently brought the salaries for physicians, but only for new hires, IIRC. I'm sure THAT's good for morale....
I'm also an armchair bioinformaticist (or whatever) and have seen the coding and modules behind EPIC, one of the most popular and widely-used EMRs around. It IS kludgey! I forget if the inpatient or outpatient systems came first, but the second had to be kludged in. THEN, when you factor in the very widely used radiology information system (PACS) you have to kludge that in. Then you have pathology and lab medicine using an entirely different system (CoPath, Soft, PowerPath, etc) you have to tie that into the EMR and PACS. Sometimes pathology and lab medicine use two entirely different systems, even though they're in the same department!
Yes, it's a mess!
article is flamebait (Score:3)
Really. ZOMG! LAWYERS!
In the case mentioned, the patient suffered permanent damage because he did not receive appropriate care. It doesn't really matter whether it was the doctor, or a nurse, or improperly maintained equipment, or a frickin' janitor's laziness, or the EMR--the hospital is responsible for providing appropriate treatment to patients.
Yes, I'm sure there's a small number of sleazy lawyers who will latch onto harmless mistakes in the EMR to try to invent a case where there is none, just as they have always done with all mistakes, long before EMRs existed.
But the real problem is not the lawyers. The real problem is the byzantine UIs of these monstrous "Enterprise Medical Record" systems, if you get my pun ;-) After all, some data entry mistakes do cause actual harm.
Re: (Score:2)
The real problem is the byzantine UIs of these monstrous "Enterprise Medical Record" systems, if you get my pun
No, but I'm sure it's terrible.
Re:article is flamebait (Score:4, Insightful)
In other words, shitty software strikes again. Civilization won't end with either a bang or a whimper, but will be taken down by an avalanche of garbage software. Hardly a day passes where I don't want to club some moron that couldn't program their way out of an open paper bag.
Strong court judgements force change (Score:4, Insightful)
Usability metrics, anyone? (Score:4, Interesting)
I haven't read the relevant regulations, and I hope I'll never have to -- I'm not sure I have that much time left on Earth -- but I'll bet that there's almost nothing concrete in them about usability.
EMR capture happens in a time- and attention-constrained environment. Any competent development house should be doing task analysis to ensure that their system meets the time constraints found during a doctor visit.
EMR search -- oh, I don't even want to start thinking about this. The relevant tasks could be anything from an auditor fine-toothed-combing records for an insurance claim, to an EMT trying to get a blood type or allergy info before a victim bleeds out.
I've consciously avoided jobs where my code is responsible for life-and-death decisions. The problem, I guess, is that too many other good people have made the same decision, and there aren't enough good people available to do what needs to be done. I'm not sure what to do about this.
Re: (Score:3)
A big problem is most of these tried to duplicate the paper form that healthcare is used to.
Computer forms shouldn't mimic paper as the workflow changes by just putting it on a computer... Add to this some crappy other things, like a McKesson program that doesn't show you all the information if the monitor's resolution is under x900... it just cuts it off and doesn't bother to tell you that you can't see everything. Was a very happy day when that was discovered... replacing thousands and thousands of monito
Re: (Score:2)
Re: (Score:2)
I agree. I know a physician who laments taking a mere HOUR to dictate the day's procedures, with the paper charting completed at time of visit. EMR takes 10x longer according to this physician.
Re: (Score:2)
I would love an EMR that was as efficient as a paper record.
I think you probably mean, "I would love an EMR that makes my job easy." This is usually heard from doctors who are upset they have to actually take five minutes to put in what they mean and cross the t's and dot the i's of people's medical care rather than rattle off something and power sign whatever the transcriptionist types* letting the file room, techs, nurses, etc do hours of work to bring them a document and ask them to cross and dot stuff.
In many other cases, the computer system is messed up because
Re:Usability metrics, anyone? (Score:5, Insightful)
The problem is not just that, it's that those companies don't actually pay that well, either.
Writing safety-critical code is not hard - there are plenty of guidelines on what you should and shouldn't do (e.g., memory allocation is verboten). It is a specialized skill, and the job should really be done by people who have the requisite training and knowledge and often even certifications (e.g., engineering certifications).
The problem is this is very specialized, and it costs a lot of money because those people know they are taking on professional risk (not unlike many other engineers - civil, mechanical, etc., who design stuff that could fail and take lives). Of course, the IT companies behind it all? They're not willing to pay for that enhanced risk - they're going to pay market rates.
Well geez, if I'm going to be paid market, I'm not going to put my name on anything to certify because that's a specialized skill that gets paid for. (hence, things like "approved drawings" which mean some engineer actually reviewed it all and put their stamp and certification on it).
There's a reason why NASA's software for the space shuttle costs 5+ times what a normal software project of similar size and scope would cost. It's not incompetence on NASA's part, and it's not just the extensive documentation and paperwork that goes along with it, but the fact that writing safety-critical software is hard, specialized, and for every line of code, probably generates a book's worth of documentation proving it fails safe, who wrote it, who changed it, who reviewed it, etc.
Yeah. Most IT companies for health don't even come close.
Re: (Score:3)
...but I'll bet that there's almost nothing concrete in them about usability.
It's worse than that: 1) There's not even anything at all regarding usability, not even the most vague amorphous pablum; 2) Many of the regulations have the unintended side effect of pushing things toward poor usability.
They all do usability (Score:2)
Any competent development house should be doing task analysis...
Of course they do usability, duh.
But every use case is different: Routine visit? Emergency with patient not breathing? Surgery? There are endless different scenarios to be considered and tons of data that has to be captured.
Re: (Score:2)
Then you run through every use case. Confer with the actual users to see what those are.
Medicine is not the only field where you could have a highly complex system deployed that doesn't achieve anyone's requirements. I've seen that myself in banking (Fortune 500) and also in "startups".
Re: (Score:2)
Then you run through every use case. Confer with the actual users to see what those are.
Don't even think about defining use cases unless you have a few hundred experienced clinicians working with you: dozens of different specialties of doctors, nurses, pharmacists, infection preventionists, various physical and occupational therapists, etc., etc.
The list goes on and on and on. Now consider the variety of patients. Does the patient speak English? Is the patient psychotic and lying to you or violent? Do you even know who the patient is?
Re: (Score:2)
It is a difficult problem, but as a person who spends a significant amount of time reading medical records, I can't tell you how frustrating it is to try to figure out something as simple as the visit date in many printouts. Oddly, the "print date" is usually very prominent -- and irrelevant.
Seriously, WTF? The date should go right at the top, above everything else, or maybe right below name. There are some systems it's even hard to figure out the name of the patient (included as an endnote on page 2 or 3
Re: (Score:3)
I also spend a good deal of time combing through charts and it IS infuriating! I got some reports from another hospital one time, and except for the envelope in which it came, there was no way to tell where care was being given, just from the notes/reports alone. No letterhead, logo, institution name or anything. There doesn't seem to be a regulation, rule, or best practices scheme for what information should be included in every note, report, chart, result. IMHO, every page printed out should have the pati
HHS Asleep At The Switch (Score:5, Interesting)
We should have seen thermometers and scales and manometers and oxygen-level gauges (all standard tests on any pnysician visit) automated to send the information to the currently-opened patient record in the examining room over secure WiFi a decade ago...insofar as I can see, there are still no such products. These Electronic Medical Record (EMR) software products (especially from the "leader") are designed to impose the maximum load on professional staff, because it's easier to code them that way. I'm surprised they aren't designed to require staff to use green-screen, text-only monitors!
So, yes, lawyers are making money. And, I'm glad those lawyers are starting to attack the EMR system providers. But the Department of Health and Human Services (and, truth be told, the Republicans who think that underfunding government agencies to cripple them is a good idea) are a root cause of the problems..
Re: (Score:2)
This is another example of government not doing their job. We have needed a single, comprehensive standard for the form and format of Medical Health Records
Why is that the government's job? Shouldn't that be the job of ISO, ANSI, or the AMA (all NGOs)?
Re: (Score:2)
Re: (Score:2)
Because they failed. Standards organizations don't get involved unless the companies in that technical field want them to be involved.
It looks like medical records companies don't want standards -- probably because they would prefer to seek an effective monopoly through proprietary standards. However, enforcing open standards benefits society and that's why government should be involved.
Government doesn't
Re: (Score:2)
This is another example of government not doing their job. We have needed a single, comprehensive standard for the form and format of Medical Health Records
Why is that the government's job? Shouldn't that be the job of ISO, ANSI, or the AMA (all NGOs)?
As far as I've seen, it's the same government employees attending ISO, ANSI and NIST forums. They are not functionally separate organizations.
Re: (Score:2)
Don't interject reality into his partisan rant. It's clearly the Republican's fault. Because, OMGZ, the 1%!!!! GWB!!! Iraq War!!!! Dick Cheney!!! Big oil!!!
Huh?
Re:HHS Asleep At The Switch (Score:4, Interesting)
The entire issue needs to be readdressed (and won't be). The 'old' system was pretty bad - spotty, inconsistent data that was impossible to read. But it was quick and easy. Worked OK if what you were doing really didn't make much of a difference, as was typical for medicine until fairly recently.
In the US, there are two overriding issues with the EHR - getting a bill out and getting a bill out. Everything else is really secondary. To get a bill out one has to follow a byzantine series of steps and (poorly documented, inconsistent) guidelines on what needs to be there and what doesn't. These guidelines change from time to time and from place to place (but we won't get into that here). The data needed for a physician bill includes a laundry list of things that are very likely completely irrelevant to patient care but have been stuck in the pile because 'more is better'.
And that was before EHRs became mandated.
Then, CMMS (Centers for Medicare and Medicaid Security) was told by our Congressional Overlords that EHRs were good and, more important, would save money and flay the beast of fraud and waste. So with little further ado they created even MORE guidelines and rules for billing and for just being an EHR (the "Meaningful Use" rules).
Then, they put a fairly tight deadline on this. For the hundreds of smaller companies in this business and the thousands of small hospitals in the country this has been a pretty much unmitigated disaster. Crappy legacy systems bolted on to insane "Meaningful Use" systems. Vendors buying out vendors and slapping disparate and inconsistent bits together (our idiot vendor, Healthland, has the nursing home module running under Net 1.1, the main module running under 1.0 and has managed to rig it so that you can't run both on the same machine without using VMs). User Interfaces straight from the 1990's. Work flows that are a hybrid (that's the nice word) of paper and poorly designed computers.
It's kinda like trying to design an airplane using a modern computer system and an abacus.
This unholy mess has been forecast with unerring accuracy. Our malpractice carrier flat up told us that we will probably get sued on the basis of EHR mistakes. The system is going to go through a decades long period of shakeout and Sturm und Drang while this gets sorted out.
Sucks to be us, I suppose.
Work for EPIC and save lives! (Score:2)
I shut up and didn't make any remarks about that poor Thomas Eric Duncan dude . . .
Re: (Score:2)
In the US, there are two overriding issues with the EHR - getting a bill out and getting a bill out.
There's a distinction here that is being missed between a Electronic Health Record (EHR) and a Practice Management System (PMS). The PMS usually handles scheduling, billing, claims, remittances, and maybe registration -- the business side of healthcare. The EHR holds the patient's actual clinical data. These systems can and should talk to each other: the EMR will need the ADT (Admit/Discharge/Transfer) feed from the PMS and the PMS will need the procedure codes to bill for from the EHR. However, the PMS
Re: (Score:2)
While you are correct, it is a bit of a distinction without a difference. In practice, they are typically created by the same company, rely on interlocking databases and use the same information. As you point out, the insurance data is actually a bit more universal than the clinical side but the big issue really isn't that the systems don't talk to each other - it is that, at least on the clinical side, they suck.
It is hard to put information in the EHR, hard to get useful information out of the EHR, hard
Re: (Score:2)
Which leader? McKesson, Epic, or Meditech? (I know there are others) but from my view of the world, it looks like Epic is taking over in the past 5-10 years.
Epic does have a crapton of clicks for staff to go through, but McKesson is just outrightly terrible, buying up programs and then trying to mash them together... These two applications must be on the same computer. App A needs Java 1.4 and ONLY Java 1.4 on the PC. App B needs 1.6 and ONLY 1.6 on the PC, Go make that work out. (there are solutions like T
Re:HHS Asleep At The Switch (Score:5, Insightful)
Really? And let's say that instead of a normal adult visit, we're talking about a pediatric visit for a child or infant with a congenital heart defect. Will the oxygen-level gauge transmit whether the reading was from a finger or a toe? Will the manometers also transmit: 1) what side the pressure was taken from, 2) whether the pressure was taken from the arm or leg, 3) whether the patient was sitting, standing, or supine?
Yeah, that's the thing. When the /. crowd starts saying there should be a "single standard" for medical records, those of us who actually work in the industry just roll our eyes... You have no idea of the complexity of the problem, nor of how fast things change on the cutting edge of the specialties.
Re: (Score:2)
I suppose, with your rationale, we should have dozens of different standards with conflicting rules over the header of a TCP/IP packet...as we DID have
Re: (Score:2)
Your ignorance of the issue is appalling.
You're the one who is ignorant of the issue. I deal with it all the time. And, frustrating as it is, I, unlike you, am aware of the history of the various attempts, and the reasons they have failed. Primarily, you have absolutely zero concept of the overwhelming complexity of the data involved, how rapidly it evolves, and the cost to society if we retard that evolution via regulation. (The example I gave was a deliberately simple one, the simplest imaginable, so that anyone could understand it.)
And, oh, by
Re: (Score:2)
Idiocracy in action. It's scary how much reality is coming into focus from that movie. It's worth watching again soon and crying about the direction we are all headed...
"Put this one in your mouth and this one in your an*s"
*guy puts one in mouth*
"No wait, put this one in your mouth and this one in your an*s"
Re: (Score:2)
Why store the patient's Age instead of Birth Date? (Score:4, Insightful)
They don't (Score:2)
I've seen several EMRs and I've never seen one that asks for patient age; it's always Date of Birth. And any one system won't request it a second time, the problem is when a hospital is using multiple systems that don't interface the EMR with each other.
Re: (Score:2)
You think you're funny? Laugh it up. An age? Simple subtraction, right? Not quite...
Start with kids under an arbitrary cutoff limit (often customizable by HC org, department, and/or provider whose ages need to be given in months. Then you get bitching from neonatologists who want the age of kids under some other arbitrary limits to be displayed in days. This is for a relatively simple concept.
Now, multiply the whole thing by about 25,000 concepts (many more complex than "age"), riddle the whole thing with m
Re: (Score:2)
Your comment is a testament to why EHR software are so bad. Because engineers with no knowledge or experience in the field of health care think they can simply decide to automate or standardize stuff, because of "things called computers", without knowing if said things should be automated or standardized. (also, four other engineers without knowledge in the field mod it insightful just like your comment here on slashdot, and consequently bad projects go ahead).
So let me give you just one small reason (among
Re: (Score:2)
However, long outdated programming practices is the norm in EMRs.
Long-outdated programming practices were traditionally merely the norm in EMRs. But now thanks to subsidies, Meaningful Use requirements, and certification procedures, they are effectively mandated by the federal government.
Re: (Score:2)
What doctors have you been talking to? Doctors definitely DO NOT like entering text. If they are typing out pages and pages of stuff, hopefully it's because that is relevant information.
That said, I think the summary is talking about when physicians copy and paste histories from one note into the next. The history and presentation probably hasn't changed, so why type it all out again? Just copy and paste! However, then you run into the problem when the history starts off with "Mr Slashdot is a 36 year old m
Link (Score:3)
http://www.computerworld.com/a... [computerworld.com]
or
http://www.healthcareitnews.co... [healthcareitnews.com]
Complex workflows + doctors = disaster (Score:5, Insightful)
It's not limited to electronic medical records -- it's the insane user interfaces in modern software that were obviously coded by a developer who never has to use the systems for work.
I'm not a doctor, but know many. Most of them are not happy at all with the shift to EHR, for the reasons cited. Most of the doctors I see for actual visits are attached to the large state university hospital nearby, and so they all use the same EHR system (I think it's McKesson.) The doctors often spend half the visit clicking through mandatory screens and cursing the computer. The insanely complex workflow is the problem. I work in airline IT, and the main reservation system providers do absolutely everything in their power to eliminate duplicate keystrokes and actions when booking a reservation or doing a check-in. It's optimized so much that agents trained on the system can do the entire transaction in real time while talking to the customer, with very few pauses. The real expert agents can eliminate any delays by using the terminal provided they've memorized the insane commands to do various tasks. The main reason for this is that airlines are insanely stingy, low margin businesses. Any delay for the agent decreases customer throughput and increases the chance they will need to put more agents on a shift.
In the IT world, I can't count the number of crappy end user applications I've integrated, where I've just shaken my head and thanked $deity that I don't have to use them for my job. And also, don't forget the ITIL-driven service desk and change management applications. The big vendors (Remedy, CA, etc.) will sell a company the "cheap" out-of-box package that implements _every single feature_ but charge them millions to customize it. Most companies don't bother, and you end up with systems where you spend almost an hour filling out a change request.
I'll bet most of this problem stems from that "out of box" deployment syndrome...where you get a product that technically functions, but is suicide-inducing unless the customer pays for customizations, in the "light a bag of money on fire" realm. How many hundreds of integration points does an EHR product have? Prescribing systems, records storage, insurance company connections, etc, etc, etc... Doctors must hate it because they can't just order a PA or nurse to do their transcriptions for them like they used to.
Re: (Score:2)
Just about every company needs to have some form of a "dogfood rule" that applies to ALL levels in the company - from the janitor to the CEO. You need to be actively using your product, and you need to prefer it above all others - even in it's most BASIC form.
Re: (Score:2)
It's not limited to electronic medical records -- it's the insane user interfaces in modern software that were obviously coded by a developer who never has to use the systems for work.
I have certainly seen that. About as often are the times developers are handed a bunch of forms, and told, "just duplicate our paper workflow". Once they finish, they're told "now add in all these features that we want which are the reason we're creating this new software." Many customers and developers really don't want to put in the effort of hiring a workflow project manager to figure all this stuff out first.
Oh yeah, don't forget MUMPS (Score:4, Interesting)
Sorry for double posting, but one other thing to note is this...behind all the whizzy new web interface screens, many EHR systems are based on some of the oldest, creakiest standards imaginable, including a programming language-and-database combo called MUMPS. Look it up - it's positively ancient, and it should be obvious why they have trouble finding people willing to specialize in writing code for it.
The VA system has one of the oldest EHR implementations in the country, and even though the GUI is semi modern, the guts of the system are this MUMPS mess. (You can download most of the source code for the system online since it's a government created product. The language was designed in an era where preserving memory was the only concern, all variables are global (!!), and keywords can be abbreviated to one letter...that should tell you enough about MUMPS right there!) Any industry you can think of that has used computers long enough has problems like this -- my area of expertise (airline systems) has standards going back 40-50 years, from when every single byte sent down a communications link was precious.
Most systems like this do a very good job of hiding the complexity from the end user, but it also reduces the amount of spontaneous change you can introduce. For example, in airline reservation systems, no one would dare change the layout of the mainframe emulator screens because so many up-level systems depend on scraping that data exactly the same way they've been doing it for 30 years. Everything an end user sees passes through many layers on the way down to the core, and systems like this are built on nested layers of wrapper code.
Re:Oh yeah, don't forget MUMPS (Score:4, Interesting)
Sorry for double posting, but one other thing to note is this...behind all the whizzy new web interface screens, many EHR systems are based on some of the oldest, creakiest standards imaginable, including a programming language-and-database combo called MUMPS. Look it up - it's positively ancient, and it should be obvious why they have trouble finding people willing to specialize in writing code for it.
When I first started in the healthcare industry almost in 1997 as an intern, my first job was writing MUMPS interface routines to extract referral data for a web interface. The system in question was running on a VAX/VMS cluster and ran a major midewestern HMO's operations.
The funny thing is when NoSQL became a buzzword a few years ago, thanks to my exposure to MUMPS, I instantly recognized it for what it was: 70's-era hierarchical database technology, repackaged for a new generation.
Re: (Score:3, Interesting)
Allscripts uses a subset of an obscure language called Arden Syntax. It is kind of like JavaScript but can do far less programmatically and often times will break the OO mold in weird ways. But, at least you can extend a Sunrise build as opposed to an Epic build which is virtually static.
I am currently working with an EMR built on top of a CRM tool. Talk abo
Editorial Fail (Score:2)
The embedded link does not work.
Good job Tim!
Perfection (Score:2)
12 clicks for basic info? (Score:2)
Riight. More UIs designed by managers who Know How It Should Go, and wouldn't dream of letting a designer or (heaven forfend!) a programmer from talking to end users to find out how they need to *use* the software....
Been there, dealt with that. The Scummy Mortgage* co, of Austin, TX, had software for its collection dept written that in in the late eighties, and the staff avoided using it as much as they possibly could.
mark
* Actual name of co available upon
Re: (Score:2)
I've seen one extremely frustrating EHR in action. And it's true, the UI is awful. I don't think it was a manger, though, it looked to me like it was designed by an techy, heh. I would have thought that generic non-techy PHB would want something like TurboTax.
And it's not just the UI, it's also the specificity that is sometimes required - like, in medical history, someone says they broke their arm. There's no selection for "broken arm," it has to be a specific bone. So, patient who broke your arm when
Feds (Score:5, Interesting)
This is one of those rare instances where the Feds CAN make a difference by mandating specific medical record formats, import and export of data, standard reporting functionality, etc.
Many EMRs are in "island" systems that you can't easily get the data out of or bring data into, stranding important information and raising the costs of moving from provider to provider. How many fucking times have you filled out the stupid medical history forms?
Where the data is kept is up for discussion, but the format and content should be standard across all systems.
Re: (Score:2)
Re: (Score:2, Interesting)
Um, that is exactly where the problem arises from, federal regulations. Have you looked at the diagnosis codes for things? There are millions and millions of them.
" V97.33XD: Sucked into jet engine, subsequent encounter. "
Yes, that is a diagnosis code. Seriously, they have one for every random act of god that has ever happened. If it happened once, it gets a code.
But here is the thing, they have these codes, so that the Feds can track EVERYTHING about you, already. This is nothing more that Metadata, and wi
Re:Feds (Score:5, Informative)
That's an ICD-10 [wikipedia.org] code, and the Feds don't generate them, WHO does.
If anything, codes like that standardize care, reporting, and billing. This way, two systems that are otherwise incompatible can have the following conversation:
What was the cause of injury? Sucked into an airplane engine
What treatment did the patient receive? (insert set of ICD codes for treatment)
Insurance company pays rates based off the ICD codes, done.
There's 68,000+ codes in ICD-10. There's going to be a few odd ones in there.
Re: (Score:2)
But thanks to systems like that designed to pick every nit, medical billing is the only form of billing that requires a 6 month training program to be able to do it and what should be a very simple transaction becomes a crazy battle of wills between the medical practice and their billing expert creatively stacking the codes for maximum payout while the insurer tries it's best to find an excuse to deny paying anything.
Meanwhile, the patient gets to be in billing limbo and honestly has no idea if a particular
Re: (Score:3)
That sounds more like a problem with the insurance company than the medical provider. I have a high-deductible insurance and I've been notified well in advance of the amount they covered and the amount that I'm responsible for (which itself may be different than what the original bill amount was). Looking at a cough may be a simple transaction, but if it turns out the person has lung cancer the ICD-10 codes will start piling up. By describing procedures in a consistent way you can ensure that billing is
Re: (Score:2)
In the U.S. it is practically impossible to figure out what a procedure will cost you. It depends on which potentially applicable code they bill it under (where the permissible codes will vary based on what other procedures have been performed and what the complaint is), how much your particular insurance provider will theoretically pay out and how much they will expect you to cover (which will vary depending on what other things you have recently been treated for), any advance negotiations between the prac
Re: (Score:2)
Know, ask, or was able to find out? In some cases the doctor will pre-approve you for a procedure. In doing to, they should be sending what will be happening and what they will bill for.
Re: (Score:2)
Pre-approval is possible, but alas, it doesn't form a binding contract. You could still get billed seperately for any sort of off the wall thing. It happens to people all the time.
Even asking will often get you looked at like you just grew a second head.
Re: (Score:3)
It's nice that there's a single international standard for these things.
Why are people bitching about the encodings instead of the stupid UIs and record formats?
Re: (Score:3, Funny)
Because they're afraid they might sustain injury by cow (other) and need treatment.
Re: (Score:2)
Or are they afraid there might not be an encoding for that?
Injury by seacow? Hmm.. "Injury by Cow (Other)". Close enough. Click!
Re: (Score:2)
it's all a conspiracy man! i'm not getting health insurance man! i'm showing up and avoiding the bill like a responsible hard working american, i'm no freeloader!
Re: Feds (Score:2)
Sarcasm was super effective
Re:Feds (Score:4, Insightful)
Oh, the Feds have made a difference all right. Not the good kind. Yes, they've mandated that the systems 'talk' to each other but then watered things down to where all they have to do is talk to some third party reporting system. Sometimes. But mostly the Feds have spent their time and dime making sure that EHRs collect all sorts of useless data and follow clinically irrelevant workflows. Then they spend their time changing the rules in mid stream.
So the vendors, especially the smaller ones, spend the majority of time trying to keep their systems in compliance and avoiding doing anything clinically useful. The big systems (Epic, GE, McKesson, etc) have their own issues but generally have the resources to deal with the idiots. Even amongst the big guys there is very little work done on how to integrate all of this fancy data into something useful for the clinician and patient. It's mostly just capturing everything that every happened.
And printing it out on paper.
Re: (Score:3)
At one point, my job was getting data out of one EHR system and putting it into another.
The standard you're looking for is HL7. Like most standards, it would do its job well enough if everyone agreed to implement it in the same way.
The real problem, however, is finding the data in the first place. A doctor can ask a patient "Who holds your medical data?" and receive a dozen different answers. Pharmacies hold some, hospitals hold more, and a giant corporate data warehouse holds a lot. Patients aren't going t
Re: (Score:2)
I'm a fan of the ID that you carry your medical information with you on a card. Go to a provider, insert the card and there ya go. They update it with whatever happens or treatments and you are on your way.
Re: (Score:2)
I'm a fan of the idea, too, but there are some practical limitations to overcome. Such a card is easily lost or stolen, and there's an unfortunately-large segment of the American population that considers such things to be a clear attempt by the government to control their lives.
Re:Feds (Score:4, Interesting)
There are already industry standards for EMR
Common Document Architecture (CDA) [hl7.org] - provides formats for the interchange of data built on the OASIS schema.
Integrating Healthcare in the Enterprise [ihe.net] - defines profiles for implementing technologies in an interoperable manner.
Open eHealth [openehealth.org] - open source baseline implementation of the above.
That's just for clinical data. There are a whole other set of standard for financial/claims records (X12) and pharmacy records/scripts (NCPDP).
The problem is that medical data is pretty complicated and often the context of the document is as important as the content. You almost always have to massage documents coming in even if they are ostensibly formatted to a standard you consume. You have to normalize units, make sure all the fields are part of the subset of the standard your system supports, etc.
And that doesn't even begin to get into tracking patient consent, tracking identity across multiple orgs, depts, and visits (MPI,PIX/PDQ), plus access restrictions and emergency access exceptions.
Re: (Score:2)
The first thing I thought of reading the summary was a CCD, which is a type of CDA from the HL7 spec you cite. Just because a document follows a standard doesn't make it usable.
I've seen huge CCDs; documents so vast they can't possibly be entirely meaningful without an analysis squad. So obviously providers are only reading the most recent additions to it. The acronym is Continuing Care Document — the operative word being `continuing' — so by it's nature it becomes very long, and the variou
Re: (Score:3)
We saw a standardization of data formats in the public safety industry through NIEM. This facilitated interoperability between public safety systems. There is no excuse NOT to have something similar for EHR.
Now, I have worked in the industry for just about two years. Pharmaceutical companies are willing to accept digital signatures on internal documents. Most, however, are less willing to accept a digital signature on a document submitted by a patient. They still require ink signatures on consent forms
Re: (Score:2)
Different situation but the same principle. I wrote and maintain point of sale software for my wife's store.
When I make a UI change, I discuss it with the staff first. Implement it. Head to the store and have them try it out. Get feedback on the utility and convenience (or lack thereof) and update the code accordingly. Iterate until the software is smooth and slick. The staff like being in the loop very much.
The UI programmers should be sitting in a patient room in a hospital, interacting with the staff who
Re: (Score:2)
The EMR discussion is not necessarily related to Obamacare.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
This. While EPIC is easy to use and does a good job of tracking mistakes, it's real power is giving the hospital a streamlined, easy to use interface for physicians to bill for services. Medical coders might go the way of travel agents.
Re: (Score:2)
Re: (Score:2)
"Heatlh" record?
In the miasma of bullshit jargon that permeates this industry, an Electronic Medical Record is that thing your doctor uses to keep his records about you. An Electronic Health Record is that mythological thing that contains your complete life-long history and is shared--instantly, seamlessly, yet with complete privacy protection--between all your medical providers.