Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Doctors Reject Tools That Make Their Jobs Easier

blogs.scientificamerican.com

Post reply on HN
Print view View original

81–90 of 131 posts

Re: Why Doctors Reject Tools That Make Their Jobs Easier

#81

Post by conanbatt »

cf498 wrote: post #32
Fomite wrote: post #23

Earlier quoted context omitted.

Yeah - I work a lot in healthcare associated infections, and a good 80% of the stuff I read about "We're from Silicon Valley and we're here to help..." just ends with me going "They're going to kill people."

I think this is something that isnt that present in our profession as it should be. If you are an electrical engineer, it is clear and present, that your products might kill someone if you screw up. The same goes for a mechanical engineer. And it will be your responsibility. If you screw up and should have known better, you might even go to jail for negligence. We on the other hand have the Therac-25. We claim to be…

Software engineering is more like witch-doctoring than to civil engineering. It is not remotely price-efficient to prove completeness on programs.

If you expect your doctor's software to be perfect, be prepared to pay for 2 software engineers salaries per doctor.

Re: Why Doctors Reject Tools That Make Their Jobs Easier

#82

Post by gwright »

telchar wrote: post #59
Thriptic wrote: post #38

Earlier quoted context omitted.

Very few modern insurance plans pay per procedure and that will be done away with entirely as time goes on. Typically physicians are paid a flat rate per patient or a flat rate per diagnosis with a complexity multiplier. This creates an incentive to NOT perform imaging unless it's necessary.

In what country? The US is still mostly per per procedure. There are codes for procedures and for diagnoses and they both get factored into the bill.

Take a look at DRGs. In the US they were first used for payments in the Medicare system but they have expanded outside that program over the years:

https://en.wikipedia.org/wiki/Diagnosis-related_group

Re: Why Doctors Reject Tools That Make Their Jobs Easier

#83

Post by [deleted] »

WalterBright wrote: post #61
Zelphyr wrote: post #58

Earlier quoted context omitted.

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

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.

[deleted]

Re: Why Doctors Reject Tools That Make Their Jobs Easier

#84

Post by zdragnar »

jrumbut wrote: post #62
zdragnar wrote: post #54

Earlier quoted context omitted.

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. E…

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…

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.

Re: Why Doctors Reject Tools That Make Their Jobs Easier

#85

Post by TeMPOraL »

brownbat wrote: post #76
projectileboy wrote: post #63

Earlier quoted context omitted.

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.

Re: Why Doctors Reject Tools That Make Their Jobs Easier

#86

Post by TeMPOraL »

daveFNbuck wrote: post #64
jrumbut wrote: post #51

Earlier quoted context omitted.

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 sa…

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.

Re: Why Doctors Reject Tools That Make Their Jobs Easier

#87

Post by TeMPOraL »

zdragnar wrote: post #54
jrumbut wrote: post #51

Earlier quoted context omitted.

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 sa…

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. E…

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.

Re: Why Doctors Reject Tools That Make Their Jobs Easier

#88

Post by watwut »

ALittleLight wrote: post #48
throwaway287391 wrote: post #33

Earlier quoted context omitted.

> Apparently one of his tests for vet interns is to tell them "This bird is sick. Figure it out". Then he gives them a perfectly healthy bird. Their bias always makes them find something. Seems like the "bias" in that case is likely due to an authority figure intentionally misleading them in the context of a "test", where one naturally assumes they're not being deceived by the very premise of said test? If an actual…

I'm not a vet, but if I were and someone said "This bird is sick." I hope the first question I'd ask is "Why do you think so?" Not to doubt the person but to figure out what the presenting symptoms were.

It is not abstract general someone. It is very concretely more experience professional and teacher whose judgement you trust more then your own. And no, if you dont go much out of way to be approachable or have reason to be afraid of him, no matter how small, they will not ask more. Because most interns know they are beginners and don't know yet.

Re: Why Doctors Reject Tools That Make Their Jobs Easier

#89

Post by TeMPOraL »

onetimemanytime wrote: post #35
gowld wrote: post #29

Earlier quoted context omitted.

Checklists make patient outcomes better; they don't make surgeons' work easier.

I guess killing the patients as soon as the cut them open would be easier for the doctor :), but their job us to heal patients. Anything that improves on outcomes is good. The OP might have suggested that instead of new tools, just use the old checklist system.

There's also trust issue. Doctors, who like everyone can be opinionated, had to be convinced one-by-one that checklists actually work and are worth messing up their work habits - unlike the many other things people are trying to sell hospitals.

Re: Why Doctors Reject Tools That Make Their Jobs Easier

#90

Post by maybecorrect »

conanbatt wrote: post #67
Zelphyr wrote: post #58

Earlier quoted context omitted.

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

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.
Post reply on HN