Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Thursday December 12 2019, @05:27PM   Printer-friendly
from the hot-mess dept.

Submitted via IRC for chromas

Mayo study finds Electronic Health Records less user-friendly than Excel

Using the System Usability Scale (SUS) in a major study published this week, Mayo researchers found modern Electronic Health Records (EHR) to be less user-friendly than Microsoft Excel. EHR got an SUS score of 45, which also ranks below GPS (maps), Amazon, and ATMs. At the top of the scale – Google search.

[...] The study showed that “SUS scores were associated with emotional exhaustion, depersonalization, and overall burnout; as SUS scores increased, emotional exhaustion and depersonalization scores decreased, as did the overall prevalence of burnout.”

It’s important to note that some specialties at higher risk for burnout rated their EHRs more favorably than those at lower risk for burnout. “This finding suggests that the relationship between EHR usability and burnout may not be due to more burned out physicians rating their EHR less favorably.”

In short, modern physician-perceived electronic health record (EHR) usability is lacking. There’s a lot of room for improvement in the way the United States electronic health records system handles data and allows data to be accessed and utilized.

Changes in Burnout and Satisfaction With Work-Life Integration in Physicians and the General US Working Population Between 2011 and 2017, Mayo Clinic Proceedings (DOI: 10.1016/j.mayocp.2018.10.023)


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by JoeMerchant on Thursday December 12 2019, @06:29PM (2 children)

    by JoeMerchant (3937) on Thursday December 12 2019, @06:29PM (#931472)

    I've heard that common practice in industry is when a new EHR interfacing device is introduced to a hospital or other IT system, the keepers of the EHR system first configure and test the device in a sandbox environment, then when it is proven working as intended they move it into production... sounds reasonable, right?

    How long do you think this induction process typically takes? Weeks, to months - these poor overworked souls have a constant backlog and the opportunity for graft / payoffs / favors in getting desired things working faster wouldn't be there if they would perform the process in a matter of hours.

    What do you think the typical charge is for this induction service? I've heard numbers around $30K, per device, which seems to be about the maximum that the IT departments can charge before triggering a revolt and replacement of themselves.

    How many equivalent lines of code do you think it takes to do one of these connections? Most systems don't actually use text code, but there are typically 3 or 4 parameters that need to be established per site, the rest is just local custom of how to input those parameters into the system.

    How much profit are the major players in the industry bringing in? Obscene amounts [nytimes.com].

    --
    🌻🌻 [google.com]
    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 5, Interesting) by All Your Lawn Are Belong To Us on Thursday December 12 2019, @09:01PM (1 child)

    by All Your Lawn Are Belong To Us (6553) on Thursday December 12 2019, @09:01PM (#931531) Journal

    Define "interfacing device"? If you're talking about adding in support for, say, a dynamap (vital signs reader) or cardiac display, yeah the manufacturer has to have written the code to interface such devices to their EMR's db. The only common communication protocol is HL7, which never was intended for data like that (though can be bashed into performing that job). More likely it's a proprietary interface and a custom translator is built to bridge the data to the EMR. But all that stuff occurs on the dev level. And almost certainly has already written it for all the major manufacturers out there. (And they usually spec out what devices they're interoperable with, without further custom development, in the sales pitch for the system).

    On the operational level first any class of newly purchased device has to be enabled to the EHR. (Yes, we're now using Lifepak 12's. We're now using WelchAllyn portable systems. etc.) Activations like that, from the EMR vendor, can run $5-$10K per device class. Not heard of $30K, but maybe there are some devices that command fees like that. What it amounts to is putting in the license code to activate the pre-written module for interface to occur. But the $$$ also pay back the development costs for when they wrote the interface in the first place, which likely cost 6-7 figures or so. They don't get enough out of the base licensing fees for that, I guess (and why would it be fair to all the people still using dumb interfaces to charge them the dev costs for the smart devices?)

    Aside from that all it will take is one failure of that code, when it matters, to trigger an 8 figure lawsuit. So yeah, you want that code to be pretty solid. So it's expensive. But AFAIK it's not tested in sandbox environments or anything like that, because the EHR manufacturer has already done the leg work. Now, if you want some hot new custom device interfaced in... yeah, 6 figures isn't all that little to get that done. See point #1 about the liability the EHR manufacturer takes on trying to adapt unknown equipment to a system. But you're talking much more than $30K to get a job like that done, most likely. But you're also talking actual coding work to get the devices to talk and not "3 or 4 options".

    Any newly purchased device has to be registered to the EHR implementation. (You don't want someone just coming in off the street with a thermometer which can interface and be able to add data to patient records, right?) Maybe it has to be registered to a given floor, though probably not. At any rate, the device has to be able to connect to the IT envrionment and the EHR has to be prepared to accept data from that particular device. That's a matter of minutes to set up, and might be able to be set up by in-house staff. I don't think that's even several hundred dollars, even if reckoned internally... though one might take between a half hour and an hour to make absolutely sure it's correct.

    But I could be wrong, as I only work on one side of that equation.

    --
    This sig for rent.
    • (Score: 5, Interesting) by JoeMerchant on Thursday December 12 2019, @09:20PM

      by JoeMerchant (3937) on Thursday December 12 2019, @09:20PM (#931538)

      Disclaimer: I actively endeavor to distance myself from this stuff, but I have bumped past it a few times in the last 35 years...

      The only common communication protocol is HL7

      And IHE - FHIR, with some XDS in the back-end, here and there. HL7 has been around since at least the 1980s, and the 10 pounds in a 5 pound bag expression doesn't start to describe how it has been abused.

      So yeah, you want that code to be pretty solid. So it's expensive.

      Expensive, yes - solid? sometimes. More often I would describe what I've worked with as brittle, hardcoded, and prone to dysfunctional behavior with slight changes in configuration. Also: deliberately obscure, arcane, and non-interoperable with other systems. There are the bridging applications like Mirth, but they tend to claim much more interoperability than you actually experience on live connection - like advertising: we connect directly to 50 EHR vendors and 100 device manufacturer's standard protocols! but the few you try to use are only limited and long outdated versions of the protocols, but you're free to update them yourself ;-)

      Maybe it has to be registered to a given floor, though probably not.

      From my perspective, this is the nightmare - every single institution has made their own creative security constructs. The people who imagined (architected seems too strong a word) them are usually either gone or inaccessible, and when something works, then doesn't - the big shrug seems to be a standard reply.

      I could be wrong, as I only work on one side of that equation.

      Thanks for the perspective - as I said, I try not to know too much about this, but people still come to me for guidance in the area. EHR connectivity might be considered 0.2% of the functionality of maybe 10% of the products we make, but... it's becoming a requirement to sell in Germany and other places, so we're being dragged, kicking and screaming, into that world.

      --
      🌻🌻 [google.com]