I agree. This article is off the mark. On the contrary, doctors want tools that will assist them in providing better patient care outcomes. In all my career, I've never met an anesthesiologist, trauma surgeon nor a hospitalist who has ever expressed a concern that technology will make them obsolete. On the contrary, almost universally these individuals are overworked and are thrilled to hear about anything that might save them a little time or make their job easier.

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.

> doctors do not want tools that are clunky

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.

They really are comically bad (Cerner, Epic, Meditech, all of them), but they are effective data silos which is a step up from having that data silo'ed in filing cabinets.

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.

These experiences also exacerbate the perception that I referred to before that can basically be summarized as "every previous attempt at making this better ended up being completely terrible". A whole slew of people want to improve things, but a lot of the time they don't take that responsibility seriously enough -- or know, fully, what that entails -- and when they bail that leaves the next would-be "disruptor" at a disadvantage.

Right, and it turns out that the devil you know is infinitely more attractive than the next helf finished buggy piece of shit that someone assures you will revolutionise your workflow.

My doctor's office just switched to the latest MyChart system and the app on Android has a pretty modern UX, decent usability and shows all my upcoming appointments, lab results, bill statements, etc. No complaints on my end, having access to my records right after my physician enters it into their computer is nice compared to requesting packets of physical paper then having to securely store them from prying eyes...

Mychart is really slick in my opinion. Very usable Android interface and everything you mentioned. I was definitely impreased for the patient experience. Sometimes with blood tests it can be a bit of information overload. But that is why you have a doctor explain what matters. It's also nice to see and compare previous tests to see things improve in a simple format.

Because it’s the same situation as with any enterprise software - the buyers are not the users, and they are evaluated at how well they did or not do their job based on a whole host of criteria that have absolutely nothing to do with satisfied users.

Buyers? I want the makers trained as users.

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.

Same problem. Makers are not paid to think like users. Makers are paid to satisfy whoever's actually paying.

If makers dont have a fundamental understanding of how the users will utilize it, the makers are making a bad product. Every developer should do customer service and a sales call on a regular basis.

> If makers dont have a fundamental understanding of how the users will utilize it, the makers are making a bad product.

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.

In either case the developer the should get a first hand experience about the pain points. Developers tend to be isolated and build things that really doesn't fit the need that is required. Ask the potential customer and they will come. (Maybe, but at least the developer has a better idea of things to build)

Its really strange how much punishment doctors seem to receive and how much they're willing to take. The hours alone would be laughable in any other industry.

The hours are, to some extent, imposed by the various medical governing bodies either directly or by artificially restricting the supply of doctors. These bodies are composed largely of doctors so the problem is to some extent self imposed. In the UK doctors are not governed by the working time directive because the UK negotiated an opt out so hospital doctors work ridiculous hours. As far as I can tell this problem does not exist to the same degree elsewhere in Europe.

>In the UK doctors are not governed by the working time directive because the UK negotiated an opt out so hospital doctors work ridiculous hours.

In UK doctors are treated much worse than they are in the USA.

In Poland it is also very common for doctors to work crazy hours.

Most consumer software is tragically bad. For example, the automatic cat feeder I have has probably the second worst user interface I've ever seen.

The worst was a thermostat.

Heaven help you if you ever lose the manual.

Because 2 main things.

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.

Its my believe that its impossible to build the killer EMR, or at least, nobody has approached that.

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.

I think the common thing between restaurant POS systems and EMR is that they aren't optimized for the user, they're optimized for management.

One of the problems I see here, and would love to find a way to solve it, is that software is best developed interatively. I see a lot of software that has some cool ideas, it just needs some tweaks to get rid of ridiculously annoying flaws, or needs to put some more control in the user's hands.

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.

Safety first, full stop, no exceptions.

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.

Well that's totally true, but even then I have no idea what the legal mechanism is for making a formally verified language in the context of a medical device looks like, or even decision support software like the grandparent was discussing.

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.

Formal verification is a barrier to quick iteration (parent comment) not just for medical software, but anything "mission critical" where the mission is "worst case scenario, don't kill someone". Hence my point about train switching and avionics. Legal mechanisms are beside the point, I think.

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.

> Safety first, full stop, no exceptions.

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.

Having seen several talks from some patient advocates recently, I'm skeptical that's a good idea.

I think health services are some of the most misunderstood by the population above everything else.

Patients are the worst at their own health, and often deluded about their ability to manage it. Gwyneth Paltrow and homeopaths don’t rake in money because people make great decisions. When you “empower” patients past their competence you get Steve Jobs in the ground. If he had just been another schmuck, he’d probably still be alive.

Health services are in service of the patients, not on your commoner opinion of what health should be and how it should be imparted.

And being in service of the patient often requires not doing what the patient wants, because the patient is not a medical professional and doesn't know shit.

Most people taking homeopathic medicine want their symptoms to get better. It’s not as though they have some different definition of a “good health outcome,” they’re just mislead about the effects of the what they’re buying.

Placebos work. Sad but true.

   Coq but with the ease of 
   Java or Typescript

Don't hold your breath. There is currently no technology on the horizon that holds a promise to bring use even close to what you ask for.

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.

I was thinking more of that would be (a or the) barrier to rapid iteration in medical software, not that it is likely to be achievable. Given the rigorous testing required in its place, we don't get web dev agile style iteration in medical software.

I don't think safety issues are preventing anything here. You don't have to iterate on live systems or real patients. You can test and develop on mockups and simulated scenarios taken straight from real life. But you need to be able to get regular feedback from actual end-users.

This is not unique to software. Physical objects also benefit from iterations in development. That doesn't mean you have to update things you've already sold. The iteration happens when people buy the next version. This used to be how software was sold too.

I believe GP's point is that you won't even make the first version of the software good if you aren't allowed to iterate on prototypes, with feedback from actual end-users.

The first version doesn't have to be good. It just has to be plausibly better than not having that software or device.

Sure. But most of the time, the first version is worse than having no software, by the virtue of interfering with existing workflow.

(This is what you get when you design for those who pay for your software, and not for those who'll use it.)

Also, for seasoned professionals you have to factor in malpractice and insurance coverage as contributing to the inertia.

I've found mostly these are given mostly as cover. Those are important considerations, but: A) most CDS is considered educational, and therefore is not supposed to replace an expert's opinion B) insurance coverage is sorta BS because most health systems are moving away from pure fee for service revenue models. Besides, I feel like you should maybe do your job as a doctor to ensure the best care for your patients than hyper optimizing your own reimbursement.

Nevertheless there is concern about any data that goes into an EMR. There is always concern about what happens in the worst case scenario where something very bad happens to a patient and their whole record is examined in a courtroom after the fact. If, say, a machine learning model predicts that thing X will happen to the patient and it wasn't acted on, a hypothetical lawsuit may go worse for the provider than if the predicted risk of thing X weren't part of the record.

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.

Some very good points. In the practice of medicine, and in particular in the litigious US, you cant ask questions you wont act on. You are liable for the responses, so might as well not ask.

Stupid af.

And of course "just hook into the EMR" is fraught with problems as it is, what with HL7 quirks and proprietary APIs and homegrown interfaces and all that jazz.

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.

Yes, its a mess. And its because none of them work for the specific use cases very well. For all the things told about it, EPIC is still the best out there.

Indeed it is, though that ain't really saying much. EPIC was one of the ones in the "new" category for us (for the satellite clinics specifically; the actual hospitals instead went with CPSI - aka "COBOL, Perl, and Server Issues"). It was definitely the least bad of all the EMRs and EMR-like systems we used.