Why Health Care Tech Is Still So Bad
nytimes.com
nytimes.com
Here's the deal. Physicians and nurses and administrators are overworked and untrained to handle a modern operational model. The hospitals tend to be based around politics rather than patient care, though the party line is invariably "help the patient". Doctors will, under the aegis of "help the patient", justify hoarding equipment, setting up alarm thresholds that screw up operations across the unit, block acquisitions, and in general just make everything terrible left to their own devices.
Nurses are overworked and are charged with increasingly important parts of patient care, and at the same time are treated as annoying appendages of the rest of the medical apparatus and not given the respect or authority that they require to perform well at their jobs.
Billing is handled through arcane back-and-forths between the care providers themselves, the hospitals, insurance companies, the government, and collections agencies. I've seen at least one local children's hospital (the economics of such institutions are quite fascinating) have banking and financing services occupying the same building as care (something you'd expect at a car lot, not a place where injured children are healed). Claims may take months or years to process, which is absurd.
The whole stinking mess should have been grist for the capitalist grinder decades ago. However, clever regulatory capture by hospitals and manufacturers and labor policies restricting the supply of new physicians has managed to prevent any of the normal efficiencies from being introduced.
When trying to introduce new technology, you have to fight the most conservative and risk-averse institutions you'll ever encounter. People that do not understand basic statistics or mathematics, or that flat out refuse to recognize the value of operational data research in making decisions because "they know better". You'll be turned away because you're not one of the chosen few, and ignored unless you can convince them that they get to put their name on the new shiny.
This is but the first level of the fractal of sadness and absurdity that is modern medicine in America.
Actually, it's very political--it's the AMA--the American Medical Association.
The doctors are fighting the automation of their jobs tooth and nail because once we have data we can see that ... gee ... most of them suck. Nurses could do their job ... better.
I accompanied my wife earlier this week to two appointments with her docs. Both docs showed up wearing Google Glass, which is a New Thing at this clinic.
This use case provides an audio feed through Glass to a human transcriber. I asked both docs about it, and they said that they'd started with video feed as well but patients were not comfortable with it. Both docs were happy to spend 10 minutes each answering questions about the new thing.
Both docs were able to call up my wife's records on Glass, which saved their having to break contact with the patient, sit at the computer, enter passwords and start searching. Seamless.
Both docs said they liked it because it kept them connected with their patients and offloads composing their after-visit notes. My wife liked it for keeping connection with her docs during the visits.
I learned a lot from these two encounters. On its face, the clinic's Glass use is pretty primitive - stream audio to a human scribe and serve the patient's records to the doc's FOV. But I saw that this simple use greased the interactions to everyone's benefit. My wife found her experience considerably improved over earlier non-Glass visits.
I don't think a startup really wants to be in this space, even though it seems like a great idea. The size of the necessary workforce, the legal complexities, the complicated interface with government and regulatory bodies and the enormity of the required indemnity make life impossible. I mean Dropbox of all companies has Condeleeza Rice on their board to smooth over dealing with the government - the mind boggles who on earth a successful startup in the healthinfotech space would need on their board, but half of congress might be a start...
I would stop trying to kill yourself dealing with hospitals, it isn't worth it. They are run by either status quo bureaucrats or cost slashers. The only way to reform things is bottom-up - creating applications that patients or clinical staff will use en masse outside of a hospital's IT system eg on their smart phones.
The space is dominated by major players that have existed since the 1980's (Epic, Cerner, etc.), which also employ the technology of the same era (MUMPS, Caché, etc.).
If anyone is going to disrupt the EMR industry, it is going to be a bigger company that can sink the costs necessary to get up to speed for an entire HMO, and a couple HMO's willing to take the risk of piloting the software.
Nobody in programming gives two shits about quality. "Ship it and patch it later" is a religion.
That doesn't work in healthcare. If your software screws up, somebody dies, and you are on the hook for several million dollars. (See: Therac-25 and concurrency problems https://en.wikipedia.org/wiki/Therac-25)
So, the technology pace winds up moving much slower.
I also like that they mentioned false positives in the article being a problem. That's an understatement. A friend had to wear a portable defibrillator vest after a heart attack. It was atrocious. It sounded warnings after a shower. The battery was hard to keep in and sounded warnings when one popped out. After a week, lifesaving technology was back with the doctor because it was too irritating to use.
This wasn't some random schmuck. This was a person who used to write technical users manuals. A normal person would have had no hope.
If you're software is being used in, say, an ICU--guess what? The patient is already in bad shape.
There's some weird conception in the medical industry and public at large that the software has to be perfect the first time, every time. And that just isn't possible or economical. And then when people try to do that, they find out that getting test data or trials done is near impossible. Hell, you can't even get the standards to develop with without shelling out thousands and thousands of dollars.
The same institutions that clamor so hard for absurd reliability in software make it almost impossible to test that software safely without a gigantic war chest.
And they look the other way when they fail to provide patient care or outright butcher people.
The difference between your code and a doctor? You can fix your code after it kills a patient.
EDIT:
And no, this doesn't mean that I suggest that we all should write bad software until the bodycount suggests a refactor.
What I mean is that we should write it as well as we're able, and that we should fix it as data for improvement becomes available.
On a related note, this is why decision-making should--for now anyways--rest with a physician. We can give them better advice, but the moral accountability should remain with the human at the bedside.
There is also the moral hazard of "How many false negatives are allowed in return for how much benefit?" or, more colloquially, "That treatment will save 999 of 1000 lives, but reliably kill 1 out of 1000. Is that allowable? What are the numbers when it is allowable?"
Finally, people need to get over the sense that anything biological is 100% reliable. Biological systems are NOTORIOUSLY unreliable--it's why we need medicine. However, most people don't see it that way.
Come again? In the real world the reliability problem has been solved. Nuclear power has been around for 60-odd years now and atomic powerplants do not regularly explode. Software on the other hand, has been around for the same time, and we expect it to be bug-afflicted. What is is that nuclear engineers have but software "engineers" are missing?
Also, notice that there are a lot more software installations and people who work on them than nuke plants. Also also note that this supremely reliable technology you are trying to hold up is (rightly or wrongly) being demonized and phased out across the first world.
The point you probably want to make is that software engineering should be a more rigorous profession. And yes, we've got a ways to go there, and yes, we're making progress.
What is not reasonable is the hypocritical and self-serving risk-aversion many people have to improving processes through software.
Medical programming, on the other hand, means programming for anything medical. You cannot really pre-model the problem with a general solution, because you don't know what salient problem is going to capture social attention in the next few years. You don't know what devices are going to be created.
People might have programming standards and methods for building secure systems, but I would say it's a lot easier to work around a problem that has remained mostly still.
Another thing is cost-efficacy. You can always have better and more safe of anything, not just in programming. Aren't car accidents so tragic? They are also one of the prominent causes of accidental death. Well, why don't we mandate that car manufacturers must include better collision safety? We could. We could mandate until all our fears are gone. Then fewer people would have cars. Ecological and public transportation arguments aside, I don't like a world where the gateway of money requires a much higher bar to pass.
Wouldn't it be unfortunate if fewer patients could access the range of medical devices which have been rigorously analyzed by a team of better-than-average engineers, and consequently the public experienced net damage?
http://www.edn.com/design/automotive/4423428/2/Toyota-s-kill...
I imagine there must be at least some who have gotten it correct, and perhaps the issue is that the best coding practices for stable systems haven't been propagated far enough, but I don't think that 99.9% of companies have this ship fast and fix it later philosophy at least.
It's not an easy problem to solve I'll admit, but I don't think that stems from the tendency for most software firms to want to push out features quickly.
Another more feeling perspective is that in healthcare, errors cause real harm to individuals that you see and care for on a daily basis. Most errors can be attributable at least partially to a specific human that care for the patient. This surely has much higher psychological damage than a very occasional loss of 200 passengers that are not even your countrymen in a plane crash, or a loss of a few million dollars that is not even your own money to begin with.
I've been promoting this concept for quite some time [1]. The state of electronic medical records is not very good and integrating data from multiple systems is even worse.
[1] http://siculars.posthaven.com/health-data-integration-regula...
EDIT: To clarify, I'm in no way advocating that the government set data model or schema standards. I'm simply suggesting that the government level the playing field by mandating that if you do anything with health data you openly publish your specification and methods by which others can programmatically read or write to those data repositories. Obviously, this is separate from having the security access to do so.
Ive worked with EMR systems that have thousands of tables. Yes. Thousands of tables. I can't tell you how many hours of reverse engineering I've dedicated to groking these schemas. Not to mention on the wire protocol decoding from medical devices. It's insane and the government should not allow it to happen.
I am inclined to think an older unified data format such as XML will probably be enough to deal with this. This may require government intervention, especially since individual doctors offices are often at ransom to tech companies.
just consider the case of drug records. most standard vocabularies are based around the pharmacy's view of the data, which does not work for prescribing meds. and then there's the problem of importing data ... you're usually downloading a prescription history, but what the doctor almost always wants is a record of meds the patient is currently on ... not prescriptions from years ago. and then there's privacy issues when it comes to certain specialties that make it difficult to share prescription data freely. and this doesn't even get into all of the units problems that lazy software developers can't ever get right!
For example, a general medicine physician is interested in the body weight of the patient currently (to dose medications), but a cardiologist may be interested in short/long-term trend as it may be indicative of heart failure. Then there are ideal body weight, adjusted body weight, dry body weight, etc etc. Do you link each body weight reading to a patient? A visit? An order? Is there a freetext remarks that can be associated with a reading? Is there any status of "unable to take reading", "weighing balance faulty", null values? Some of the systems would have dissimiliar data schema.
Regarding my last statement, overall the healthcare software landscape feels like pre-2000 in the greater sofware industry where everyone is trying to build every possible product to own every market and there is little or no cooperation.
> If all the vendors spoke JSON (or some common, generic format) then you would only need to figure out a mapping for each vendor to your unified, internal schema.
This is not easy at all if your internal schema has less fidelity/dimensionality than the vendor. Expanding on my example above, suppose you have a smart weighing scale a la Withings scale that integrates with the EMR. The weighing scale has the patient's height input so it is able to send BMI <http://en.wikipedia.org/wiki/Body_mass_index> reading to the EMR as well. However, your EMR does not have a field for BMI because it is a computed/derived value of weight and height.
If your internal schema has higher fidelity than the vendor, you also are forced to impute data - this is not as bad but may cause unintended behaviours as well. A contrived example: the weighing scale only has the patient's identity information. However in your EMR the weight readings can only be stored associated with a visit/encounter (aka a hospital stay or appointment). You can associate the reading with the last open visit/encounter, but this will have undesirable repercussions e.g. during system downtime (it might become associated with the wrong visit).
There are ways to solve the above integration issue but they would cost a lot and may significantly impact the EMR all the way to end-user UI. So it is not only a technical issue but also whether the users are comfortable with the amount of complexity introduced in the UI, data imputation, etc.
There is so much money sloshing around in the industry, yet people are getting less and less for their dollars.
Everyone loves to criticize financial and telecom companies for bad behavior but healthcare puts them to shame.
You have Copay, out of pocket, deductible, co-insurance, HSA, HRA, FSA, preferred drugs, generic drugs, single source, multi source, in-network, out of network, lifetime CAP, etc.
These are essentially instruments that healthcare companies use to reduce their payouts and shift costs.
Where is all the money going? (no need to answer)
It makes me sick that this year's SXSW focus was on healthcare. We don't need more startups and MBA types trying to 'fix' healthcare.
The current healthcare problem is purely political and regulatory in nature.
I did a bit of work with some guys who wanted to do a focused "udemy for medical students" - extremely focused content from top professors. "We really need this - no one's thought of this before!, etc". I pointed out that very likely the professors had some sort of IP/publishing tie with their universities which would at least require approval (if not in fact prevent such deals from happening). "Oh no, we've got professors lined up already - we're ready to get moving!" 3 months in... a sum total of 10 minutes of content was produced - poorly. Most of the professors, when pressed, admitted they had to get approval because they had IP deals - not specifically with their universities, but many with existing publishers (note: don't ask published medical professors to create web content for you, as it'll likely be a conflict of interest with their publisher). The team didn't want to have lesser-known professors - only top published name-brand professors... so it all died. "This was a lot harder than we thought it would be" was the final parting discussion, and was my initial point I'd made when we first started - "this is going to be harder than you think it is. the core idea is brain-dead simple - there's a reason it's not being done the way you want it done, and it's not because the two of you are the first humans on the planet to think of it".
Sounds a bit harsher in retrospect when writing it, but back to healthcare - yes, the current mess is not due to a lack of smart people - it's those existing people with industry knowledge and experience not being able to work effectively.
You have that in the US but not necessarily in other countries. The UK NHS doesn't have that stuff but still managed to screw up:
http://www.independent.co.uk/life-style/health-and-families/...
which suggests there are technical difficulties also.
"One supplier, Computer Sciences Corporation (CSC), has yet to deliver the bulk of the systems it is contracted to supply and has instead implemented a large number of interim systems as a stopgap,"
Google "CSC" and "fraud" together and you'll find some interesting tidbits.
I work for Syapse (http://www.syapse.com), and we are trying to do something about this problem. As a startup, we have a laser focus - we are building systems that help practicing doctors, mainly oncologists, take advantage of genomic data. We focus on improving UI, workflows, alerts, access to up-to-date knowledge and yes, data entry.
If you are interested in this field, please consider applying for one of the open positions. We are looking for server engineers, data systems engineers, UI engineers, DevOps, etc. We are located in downtown Palo Alto, CA.
I would love to have a platform like this. At the moment the analysis, curation, reporting and suggestion of clinical trials is all done manually by me.
I think the author is right about the problems, and these solutions seem sound. These are the kinds of things ossified institutions always say, and they're actually usually right (e.g. Bill Gates's prescient Internet Tidal Wave memo which predicted the ways in which Microsoft would fail to become a dominant player on the web, or the peanut butter memo at Yahoo).
The trouble is that actually implementing changes like these at an incumbent institution is hard. Really hard. So hard, in fact, that failure is overwhelmingly the rule. In most industries, the way that plays out is that incumbents fail to change, new competitors emerge with the new processes baked into them from the beginning, and they then kill the incumbents. A few years later, those new folks ossify and then themselves get killed by the next wave. And so on.
A healthy industry offers all its players a choice: "Evolve or die. Do whichever one you want, but one of those two things will happen." There's no third option, "Do your best to evolve". The institution succeeds at changing or it dies, and that's all there is to it.
The trouble in healthcare is that incumbents do get that third option. And the reason they get it is that for the most part, there are no new competitors to kill them off.
However, the experience was marred when I went upstairs from the xray room to the dentist's operating room. He couldn't find the digital files. The reason was, he told me, because over the past few days, the office was finally upgrading its system from Windows XP...to Windows 7. I wish I had taken notes overhearing him talk to the assistant and the totally random sounding hacks and procedures they had for just getting through the computer system, I'm surprised I didn't hear "Turn off the computer, wait at least 30 seconds, then turn it back on"...suffice to say, the mystery of the missing digital files was never really solved and took up about half an hour of the appointment time.
I'm surprised a Palantir-for-Doctors hasn't yet come up...a company that maybe doesn't build anything revolutionary but makes billions from an audience with a lot of money and very low standards.
So basically the "information collation and noise reduction" part necessary for any mass surveillance system to be actually useful.
Palantir for doctors would basically just be Palantir with people's medical information and medical research plugged in, and maybe family connections, instead of "Person a called person b", "Person b has known terror connections.", etc.
The big feature is basically tagging words or phrases in a source document - like a medical report in this example and then linking it with other documents with the same tags to reveal associations.
Generally it kind of just gives you a nice visualization of what you already know. However in a networked environment when you "expand" your links by ingesting other people's tags and nodes that is where you get some interesting links and patterns.
I can't observe them when they are with a patient and its impossible to schedule time to get feedback, they are so overworked.
My theory why the UIs of these EMRs are so awful is because of this very reason: there's no feedback loop. And I'm not blaming the doctors, they have no time.
I want real statistics...anyone with interesting source?
Other than wearables, does anyone have a good solution for this?
Seriously, have you ever looked at the software your nurse or doctor is dealing with while they are supposed to be talking to you? It's hot garbage.
I believe that interfaces end up the way they do for a reason. I'm curious what the reason is for healthcare -- is it a disconnect between stakeholders in the design stage? Lack of budget?
I'm hoping you can help me learn beyond the "design by committee" or other cliches. or at least understand those cliches in a medical setting.
A friend of mine works for one of the EMR software companies, though he doesn't program any more. I've also experienced the adoption of large scale enterprise packages such as SAP and SharePoint.
As I understand it, the UI design is literally an afterthought, because it doesn't exist at the time of sale. The expectation is that somebody will adapt the software to the customer's processes by creating custom UI's, data base structures, and work flows. There is a mad scramble to throw this stuff together and make it work. I suspect there is simply no time to sit down with workers and respectfully find out how they do their jobs. And processes that worked because the employees didn't follow the procedure, suddenly stop working when coded into software.
Considering the staggering size some of these projects are (peripheral evidence of complexity like table counts as mentioned here, and more solid evidence like raw lines of code, number of UI controls from big to small), it quickly becomes economically infeasible to put a modern shine on things when you have features you could be building to make more sales.
A decent UI in 2000 looked much different from now anyway. Also, the programmers probably aren't in charge of looks/design.
It's like staring into an alternate dimension where VB6 never died and no version of Windows past 98 was ever released.
We use all our own file formats! You want to migrate to another software? Well, there's no current way to export your databases and reports to anything readable by anything in existence, but if you tell us the feature you're looking for, we'll just glom it on for you like we did with our pet project from college until it became the bloated fortress of invented-here syndrome you're using now!