
Why Health Care Tech Is Still So Bad - digisth
http://www.nytimes.com/2015/03/22/opinion/sunday/why-health-care-tech-is-still-so-bad.html
======
angersock
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.

~~~
bsder
> 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.

~~~
angersock
I rather meant to explain that the problems--and their implied solutions--are
not politically viable, mainly because of what you've mentioned. :)

------
ridgeguy
Apologies if too far OT.

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.

~~~
yumraj
Very interesting - do you mind sharing where/which clinic was this..

~~~
ridgeguy
Palo Alto Medical Foundation, at their Palo Alto location

------
Gatsky
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.

~~~
bduerst
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.

~~~
leonth
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.

------
bsder
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](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.

~~~
angersock
So, that's the shitty thing, right?

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.

~~~
HarryHirsch
_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?

~~~
threatofrain
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?

------
siculars
"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.

[1] [http://siculars.posthaven.com/health-data-integration-
regula...](http://siculars.posthaven.com/health-data-integration-regulation-
and-incentivization)

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.

~~~
leonth
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.

~~~
rpedela
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.

~~~
leonth
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>](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.

~~~
rpedela
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.

------
pcurve
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.

~~~
tim333
>You have Copay, out of pocket, deductible, co-insurance, HSA, HRA, FSA...

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/...](http://www.independent.co.uk/life-style/health-and-
families/health-news/nhs-pulls-the-plug-on-its-11bn-it-system-2330906.html)

which suggests there are technical difficulties also.

~~~
pcurve
Very interesting.

"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.

------
mbtmbt
Everything in this article is true.

I work for Syapse ([http://www.syapse.com](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.

~~~
ZanyProgrammer
I looked at your website, but alas I didn't go to Stanford or a UC.

~~~
jhedwards
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.

------
karzeem
"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.

------
danso
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.

~~~
zachalexander
OT, but what exactly _does_ Palantir do?

~~~
electronvolt
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.

------
ddw
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.

------
deepsun
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?

------
masamune__
[http://www.bloomberg.com/news/articles/2015-03-20/dozens-
of-...](http://www.bloomberg.com/news/articles/2015-03-20/dozens-of-startups-
in-obamacare-s-wake-reveal-law-as-job-creator)

I want real statistics...anyone with interesting source?

------
nighthawk24
[http://health.gnu.org](http://health.gnu.org) \+
[https://arvados.org](https://arvados.org)

------
georgeoliver
The article mentions time-consuming and distracting data entry.

Other than wearables, does anyone have a good solution for this?

~~~
douche
Yes, non-terrible data entry UI.

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.

~~~
jobposter1234
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.

~~~
aswanson
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.

~~~
analog31
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.

------
supercanuck
The important point seems to be the absence of user centered design.

