At a conference I was at recently, I'm nigh positive "Decision Support Tool" was a dirty word.
That being said, doctors do not want tools that are clunky, tools that force them to change their existing workflows, tools that run slow, can't pull in relevant data in real-time, rely on fragile HL7 interfaces, etc. Doctors want tools that work for them. Doctors do not want to be fighting or struggling with tools that are supposed to help them. While that may seem obvious, it's a very difficult bar for most software makers to meet -- particularly in the inpatient and ED space.
I can understand the author's perspective -- she's a new resident at Yale New Haven Hospital and previously ran a medical software start-up that closed up shop relatively quickly. It would be convenient to rationalize the failure of her start-up due to fears of new tech. While it may have been a fear of new tech that prevented her start-up from succeeding, it was not a fear of being made obsolete -- it was a fear that her product wouldn't do the job well.
And yet every EMR system I've ever seen is comically bad. Why the medical providers haven't revolted over being forced to use those things is beyond me.
People outside healthcare really don't understand the sheer amount of time your physician spends trawling through the medical record in the regular course of doing his or her job. You can think of the patient chart as a shared "My Documents" folder on your computer. In modern multi-disciplinary care, you have many different parties taking care of the same patient and working in shifts. In order to get up to speed with what's happening for a particular patient, you need to open up each of the recent files in "My Documents" for that patient and review it. Lab results, progress notes, schedules, etc. Then repeat a couple dozen times for all the other patients you're caring for that day. Endless clicking. Constantly flipping between windows. Burn out.
That's not too much of an exaggeration of what the real EMR experience is like today.
The worst was a thermostat.
Heaven help you if you ever lose the manual.
Everything I've optimized really well was after a week or so using the old bad solution.
Programs made for me, to automate some part of my job? Invariably break some part of my workflow that promptly gets labeled an edge case.
Well, exactly. That's half of the reason why enterprise, medical, restaurant and other similar software generally sucks.
> Every developer should do customer service and a sales call on a regular basis.
In B2C, sure. In B2B for the examples I mentioned above, a "sales call" is where the problem starts. On such a call, you'll get the opinions of people paying for software, not of those using it.
There are many reasons for it, just as making software to manage restaurants has been an impossible one. The use cases are operationally extremely different in all cases.
In UK doctors are treated much worse than they are in the USA.
First: you're dealing with humans so you have to let a lot of things possible. Which is how you easily get shitty UI.
Second: everything is a legal horror. Certification, certification, certification.
PS: and third. Most medical software is not chosen by its users but by management.
Unfortunately, and inevitably, a little tweak in medical software may as well be a tweak on a satellite in space.
Like I said, changes need to be prevented from making the software bad, but the difficulty of making changes also makes the software bad. I don't know what the solution is, but I would like to see this aspect addressed more explicitly.
Until correctness can be done easily in accessible programming languages with a decent developer pool, iteration in this space, along with other life-critical spaces such as trains, planes (and wouldn't automobiles be nice too?) is sadly a long, manual process compared to web development.
Edit: to expand a bit on correctness, think Coq but with the ease of Java or Typescript. Even Rust's safety isn't yet formally proven; that's not a knock on rust, but a demonstration of just how hard it is to do.
Even if such a thing existed, it would require a very rich set of constraints on the program to be able to encode something like "won't make the wrong decision when a patient has a pulmonary embolism and these three other conditions" and I think that's what doctors would want.
As for rich constraints, that does bring up another point- how do you quickly iterate on a system full of bad data or systems of incompatible data? To get Watson to a degree of certainty, so much data manipulation and review happened by hand that it was a wasted effort.
This isn't to say that I'm in love with what I've seen of the software my doctors use (or the puckering feeling seeing how outdated the OS tends to be). I'd be a whole lot less happy, though, if their software had the reliability of say, imgur or reddit.
And here you are, cutting-edg hospitals running 2012 versions of modern software, and paying millions of dollars for the privilege.
The direction has to be exactly the opposite, by giving the patient increasingly more control over his own health.
Coq but with the ease of
Java or Typescript
Note also that Coq/Isabelle/Agda and their successors will still suffer from a variant of the oracle problem: where should the specifications come from?
Finally note that almost virtually aviation software is formally verified in with interactive theorem proving as of 2018. The extreme levels of reliability in this space have always been achieved with other software engineering methods, including rigorous testing.
(This is what you get when you design for those who pay for your software, and not for those who'll use it.)
This doesn't mean that the doctors bury their heads in the sand, but it is a part of the reason providers are resistant to adopting these tools. Relying on their own knowledge and intuition may not be better but it won't hurt them as evidence in a hypothetical malpractice suit. The decision support tool has to be sufficiently better to outweigh this.
I hold no opinion on the validity of this line of thinking, but I can say that it is part of the calculus, at least for some.
Stupid af.
Even "better" when there's no concept of "the EMR". My foray into healthcare IT was at a hospital/clinic district that used no less than 4 EMR systems (one new and one legacy for the main two hospitals, plus one new and one legacy for all the satellite clinics). That's not including the specialized systems for ER, Oncology, Obstetrics/Gynecology...
All for the pursuit of Meaningless Use.