I work in the medtech/health IT field at a startup doing a lot of clinical analytics. There's a very blunt and obvious explanation of what's wrong here, and it's the very unpolitical one.
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.
> I work in the medtech/health IT field at a startup doing a lot of clinical analytics. There's a very blunt and obvious explanation of what's wrong here, and it's the very unpolitical one.
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 think your take is remarkably accurate. I have a good friend who works at a world-renoun hospital in the US and the stories he tells! Politics rules decision making in the hospital. Leadership (including the docs) are constantly clamouring for more power. Normal market forces that would normally incentivize efficiency are no match at all.
Seconded. I may or may not have left a similar medtech job but this job may or may not have been in the belly of the beast.... a very well known teaching hospital. Politics may or may not have run rampant and the leaders charged with modernizing the organization may or may not have appreciated technology or may or may not have known enough to support those who did. Oh well.
As I told a developer earlier this week, trying to disrupt healthcare is like starting an avalanche by tossing pebbles at a boulder. Between institutions, carriers, and the godawful state of interoperability technologies (I've been on the standards committees, I accept my share of the blame), it's essentially impossible to really advance the state of the art, even though there's a real need for technology that helps enable the organizational advances in clinical practice we've seen over the past several years.
There are political issues, but there is also an impedance mismatch between "medical programming" and 99.9% of all other programming.
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.
The issue is that "failure of commission" is visible and punishable while "failure of omission" is not. Not providing the best care isn't directly punishable. Not obeying a heart rate alert is punishable.
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.
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.
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?
Two centuries at least of engineering experience to build on, for a start? Nuclear plants are relatively straightforward extensions of existing civil, electrical, mechanical, and chemical engineering principles--it's all just steam engines eventually.
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.
Nuclear power is, as far as I know, a consistent problem, meaning that it's not like the requirements and shape of the problem changes that much.
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?
We know how to create reliable software; we just don't want to pay for it. We prefer for software to be cheap than for it to be reliable, so that's what we get. In the rare cases where we do spend the extra money on quality, e.g. embedded software in vehicles, we do get reliable software.
I'm not sure I agree that about the mismatch issue. I would certainly agree that for the majority for programming nowadays, quality takes a back seat to quantity. On the other hand, there are still many jobs where quality is very important, like dealing with the mechanical/aerospace industry, security related software, and financial software. Those businesses don't seem to have problems finding the right people and working with a different set of constraints.
I'll admit I don't know if I'm correct or not, but a single counterexample doesn't really show anything.
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.
Besides the counter-examples already mentioned, healthcare is already relatively unsafe - there are more people who die from medical errors compared to plane crashes, despite whole industry focus towards safety. Nobody wants IT experiments that magnify these numbers.
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.
"In health care, changes in the way we organize our work will most likely be the key to improvement. This means training students and physicians to focus on the patient despite the demands of the computers. It means creating new ways to build teamwork once doctors and nurses are no longer yoked to the nurse’s station by a single paper record. It means federal policies that promote the seamless sharing of data between different systems in different settings."
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.
"It means federal policies that promote the seamless sharing of data between different systems in different settings."
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.
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.
easier said than done. every system has its own perspective of the patient, but you can't simply share that. there has to be a canonical format that works in multiple contexts, but all of the so called standards have been horrible.
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!
One of the reason why this has been so difficult is the mind-bogglingly high dimensionality of the data.
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.
I think the data format is more the problem. What you describe is a problem, but of the annoying sort. 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. Granted it would be time-consuming because of the high dimensionality but it is doable. Instead they each have their own data format and in some cases binary and proprietary which is the worst combination. And they may not be willing to share a data format spec for some reason so you have to reverse-engineer their format.
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.
I would actually think otherwise. The message format standard commonly used to pass HL7 messages right now are quite easy to parse, it is basically a CSV file using pipes and carets as field separators. Any technology worth integrating right now speaks HL7 one way of another already. Even if some reverse-engineering is needed, it is a 100% technical endeavour that does not need any political buy-in (except budgeting) - this is what I like to define as "annoying sort of a problem".
> 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.
I think the big assumption I was making, and probably should have said is that you have complete control over your own internal schema. The sort of control that allows you to modify that internal schema to incorporate a new vendor's schema regardless if it is more or less complex. If you don't have that control then yes it is a very difficult problem.
Why is it garbage? It seems to me that most programmers who care about their craft would make a halfway decent UI by default.
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.
Its garbage because its written by big companies with slick salesforces like oracle, etc. The design/UX is an afterthought; the main thrust of these companies is suits closing the big deal. The interfaces built by these companies are almost never designed by anyone with taste, done in java, and look like your typical j2ee architecture with circa 2006 web interface sensibilities.
This is the "enterprise software problem," to wit: All enterprise software sucks because it's sold to administrators and not to users.
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.
Some of these solutions have code from 15-20 years ago. After the original authors left the company with deep knowledge, a complete UI redesign went from uphill battle to sheer cliff climb. Once every generation comes and goes, rewrites just get more complex. Even then, the code then was probably based on standards from that long ago, and its quality will most definitely slow you down. Now couple that with the problem of high turn over, and no one wants to handle the shit pile. We keep shoveling things over to get paid.
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.
And retail and restaurant POS software. They all seem to like primary colors and lots of big, gray buttons.
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!
To me the question comes down to money. How much is it going to cost to create a modern, technology-aided health infrastructure that is actively utilized, in a top-down fashion? I think the answer is a lot more than we would guess, and a lot more than anyone is willing or able to pay.
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 EMR industry has a huge bureaucratic barrier to entry, which is why you don't see it technologically progressing at the rate of other industries.
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.
I want to add that a lot of value of the EMR system comes from integration - i.e. smooth data flow between touch points / care areas / visits / institutions. So it is rather hard to disrupt the industry using the typical "disruptive technology" idea because your niche solution may not play well with the rest of the system. And the incumbent has every incentive to make integration with a potential disruptor as difficult as possible.
A few months ago, I went to a dentist in Palo Alto for the first time...by far the most hi-tech dentist office I've been in...though it's been awhile for me. I guess I was most impressed with the digital x-ray machine, in which they could snap shots, and we'd see them pop up right away in front of the flatscreen in front of me.
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.
From the recruiting presentations I saw while at university: they primarily do large scale information grouping and retrieval. It seemed like their systems (at least the ones they were public about while trying to recruit from undergrads) were aimed at taking large numbers of random facts about actors ("this person has made a lot of phone calls to this person", "this person was seen in place a", etc.) and making them all traversable as a sort of information-visualization graph. It seemed likely rather math-y and very interesting.
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.
As a former user there are two primary features: Network Graphing and Concept Linking
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 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.
Don't worry about that, I work at Syapse too and I have an MA in Chinese lit from UMASS. You could be totally self taught like me and as long as you have skills and a good attitude you will be considered. Everyone there is super nice and open minded.
Thanks, looks like a great product.
I'm a medical oncologist doing targeted sequencing for breast cancer at an academic center in Australia. We're small by American standards but there isn't a similar service in the country as far as I know. At the moment we're doing it for free as we have some research funding and are still refining the sequencing workflow.
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 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've been in the sector for about 11 years and I've grown to take very dim view of the entire industry.
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.
While not in the healthcare space, I have the same default view of many industries. In many cases, the entrenched problems are not specifically technical in nature, and just waiting for some smart person to point out "feature X will solve Y!" and everything falls in to place. Yet... in many cases when I'm talking to startups, this seems to be the mentality. I tend to notice it in younger folk (probably moreso as I get older), but it's actually a little bit annoying (or can be - not always so).
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.
"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 believe in developing a product, especially the UI, by constantly getting feedback from the user but I'm racking my brain on how to do that for a product for medical professionals.
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.
There's OneMedical.com, a kinda startup as far as I understand. $140/year doesn't sound too much, so I signed up for it, will see how it goes, don't have an opinion for now.
As far as I understand, they do only physicians stuff, have offices in major metropolias. Their main point I liked was that they finally do documentation/appointments/labs online, and treat online as first-class. Anyone had experience with it?
60 comments
[ 3.3 ms ] story [ 93.9 ms ] threadHere'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.
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 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.
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.
https://xkcd.com/927/
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.
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!
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.
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 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 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.
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 want real statistics...anyone with interesting source?
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.