7 ms·

An alternative headline is "Tool Makers Make Tools That Don't Help Doctors". I know a ton of colleagues who flinch every time someone mentions that this'll just

by Fomite 8y ago

An alternative headline is "Tool Makers Make Tools That Don't Help Doctors". I know a ton of colleagues who flinch every time someone mentions that this'll just hook into the EMR system, because they know everything will be broken and tedious for years before another vendor comes along. At a conference I was at recently, I'm nigh positive "Decision Support Tool" was a dirty word.

escherplex 8y ago
Also, for seasoned professionals you have to factor in malpractice and insurance coverage as contributing to the inertia.
- skwb 8y ago
  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.
  - telchar 8y ago
    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.
    - conanbatt 8y ago
      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.
jrumbut 8y ago
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.
- zdragnar 8y ago
  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.
  - jrumbut 8y ago
    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.
    - zdragnar 8y ago
      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.
yellowapple 8y ago
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.
- conanbatt 8y ago
  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.
  - yellowapple 8y ago
    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.
EB66 8y ago
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.
- Zelphyr 8y ago
  > 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.
  - EB66 8y ago
    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.

by Fomite 8y ago

escherplex 8y ago

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

skwb 8y ago
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.
- telchar 8y ago
  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.
  - conanbatt 8y ago
    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.

jrumbut 8y ago

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.

zdragnar 8y ago
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.
- jrumbut 8y ago
  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.
  - zdragnar 8y ago
    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.

yellowapple 8y ago

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.

conanbatt 8y ago
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.
- yellowapple 8y ago
  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.

EB66 8y ago

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.

Zelphyr 8y ago
> 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.
- EB66 8y ago
  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.