4 ms·

I have first hand experience with hospital IT. > Nurses aren't dumb and they certainly aren't lazy. They just have better things to do with their time than dea

I have first hand experience with hospital IT. > Nurses aren't dumb and they certainly aren't lazy. They just have better things to do with their time than deal with inconsequential IT issues. I don't want to reduce this discussion to name calling. Absolute majority of my tickets were along the lines of "user entered shit data and now they are getting shit data out, help". A minority of users would put in effort to thoroughly document actual state of affairs. Huge portion of users just did the bare minimum to tick a mental box "I did a thing". If they could find a way to discharge patient from their unit with lowest number of clicks/keypresses they would do that, even if it meant marking the patient as deceased (not much of a hyperbole, by the way). > Nurses are busy doing things like saving lives and caring for people experiencing the worst day of their life. That's the problem with medical personnel. They see the immediate act of "saving lives", e.g. putting a patient in a scanner ASAP, as their only job. All the documentation stuff is usually seen as a hindrance, sometimes as a way to cover someone's ass. Under very rare circumstances it is seen as an integral part of patient care. How do I know that? Every implementation of rule checks would be met with backlash rather than appreciation for an extra pair of robotic eyes.

gregshap 3y ago
This. Same as software engineers doing production support. It's easy to glorify putting out fires and hard to take credit for careful attention that prevents fires. Preventing fires extends a lot more lives.
Propelloni 3y ago
>"user entered shit data and now they are getting shit data out, help" [...] > If they could find a way to discharge patient from their unit with lowest number of clicks/keypresses they would do that, even if it meant marking the patient as deceased (not much of a hyperbole, by the way). That's a classic, not only in hospital IT. Apparently you expect the user to serve the process and not the other way around. That's not how it works. If the goal of the user (or the organisation) is to do as much of X as possible (maybe even incentivized) the process better facilitates that or it will be abused and/or circumvented.
- friendzis 3y ago
  > Apparently you expect the user to serve the process and not the other way around. One of the ways to classify process control is by degrees of freedom: closed-loop, semi-closed-loop, open-loop. Anything but closed-loop processes require users to serve the process. That's by definition and there is no way to escape that fully. Sometimes you can make manual state adjustments to the process, sometimes you can "correct" aggregated data fed to outer process, sometimes you can't do anything about it. In SCL/OL user is the oracle. Every business process management system (ERP) will be at least as complex as the process it models. The more generic the system, the less context-aware it is and thus typically the more complex. You can pretend that SCL/OL control system should try and infer things to help users, but in fact that impedes correctness, because users are less likely to enter purposefully wrong value (mental default or validation-passing gibberish) than they are likely to agree with prefilled default value despite it being somewhat incorrect. Especially if the inferred default value is usually mostly correct. A very crude example. Think of e.g. compass based boat steering control system. It will need occasional course correcting input to account for wind/current drift. Suppose you implement periodic prompt for course correction. Empty prompt will be more likely be filled with non-zero value. Default zero value will be more likely to be accepted unmodified, resulting in more jaggy course.
  - Propelloni 3y ago
    I don't think we are really in disagreement here, but you are talking about steering the cart through the aisle and I'm talking about taking home groceries. If your steering process is hindering my taking home groceries, I will ignore the cart. Less farcical, you are talking about means, I am talking about ends. Ask yourself what a successful organization needs to take care of. On the topic of forcing users (ie. require) to adhere to the process you better have a good explanation why the process requires hindering the user in completing the task at hand. I know there exist good reasons why we ask users to jump through this hoop or that, but we need to make sure the user knows these reasons and sees why they are not a hindrance in completing the task but part of the completed task.
    - 3y ago
Joker_vD 3y ago
> That's the problem with medical personnel. They see the immediate act of "saving lives", e.g. putting a patient in a scanner ASAP, as their only job. All the documentation stuff is usually seen as a hindrance, sometimes as a way to cover someone's ass. Thankfully, we have reasonable people in the management: people who understand that it is maintaining proper documentation (and properly shifting liability) is the one and true purpose of the system; the "medical caring" (or whatever it's called) is simply a by-product that would fall out of it naturally. If only that stupid line personnel (and they are stupid because why else would they have applied to such lowly-paid job?) would understand that and would start to change the world so that it would to match the written documents and instructions (not the other way around, that'd be blasphemous).
- hulitu 3y ago
  The sad thing is that i wish that you were joking. Again to all SW engineers out there: If there is only 1 (one) input field on the application which has focus ( in A.D. 2023, 55 after the Mother of all demos was presented, according to Wikipedia), why do i have to click on this field before typing so that the characters typed do not go somewhere else ?
hulitu 3y ago
> If they could find a way to discharge patient from their unit with lowest number of clicks/keypresses they would do that, even if it meant marking the patient as deceased Real programmers don't comment their code. If it was hard to write, it should be hard to read. > Every implementation of rule checks would be met with backlash rather than appreciation for an extra pair of robotic eyes. When you are under pressure, the last thing you want is "an extra pair of robotic eyes" which constantly gets in your way.
- IIsi50MHz 3y ago
  Or, you DO want a rule-check, where it reduces incidence of critical errors that are known (due examnation of prior failures) to be more likely when under pressure.

gregshap 3y ago

This. Same as software engineers doing production support. It's easy to glorify putting out fires and hard to take credit for careful attention that prevents fires. Preventing fires extends a lot more lives.

Propelloni 3y ago

>"user entered shit data and now they are getting shit data out, help" [...] > If they could find a way to discharge patient from their unit with lowest number of clicks/keypresses they would do that, even if it meant marking the patient as deceased (not much of a hyperbole, by the way). That's a classic, not only in hospital IT. Apparently you expect the user to serve the process and not the other way around. That's not how it works. If the goal of the user (or the organisation) is to do as much of X as possible (maybe even incentivized) the process better facilitates that or it will be abused and/or circumvented.

friendzis 3y ago
> Apparently you expect the user to serve the process and not the other way around. One of the ways to classify process control is by degrees of freedom: closed-loop, semi-closed-loop, open-loop. Anything but closed-loop processes require users to serve the process. That's by definition and there is no way to escape that fully. Sometimes you can make manual state adjustments to the process, sometimes you can "correct" aggregated data fed to outer process, sometimes you can't do anything about it. In SCL/OL user is the oracle. Every business process management system (ERP) will be at least as complex as the process it models. The more generic the system, the less context-aware it is and thus typically the more complex. You can pretend that SCL/OL control system should try and infer things to help users, but in fact that impedes correctness, because users are less likely to enter purposefully wrong value (mental default or validation-passing gibberish) than they are likely to agree with prefilled default value despite it being somewhat incorrect. Especially if the inferred default value is usually mostly correct. A very crude example. Think of e.g. compass based boat steering control system. It will need occasional course correcting input to account for wind/current drift. Suppose you implement periodic prompt for course correction. Empty prompt will be more likely be filled with non-zero value. Default zero value will be more likely to be accepted unmodified, resulting in more jaggy course.
- Propelloni 3y ago
  I don't think we are really in disagreement here, but you are talking about steering the cart through the aisle and I'm talking about taking home groceries. If your steering process is hindering my taking home groceries, I will ignore the cart. Less farcical, you are talking about means, I am talking about ends. Ask yourself what a successful organization needs to take care of. On the topic of forcing users (ie. require) to adhere to the process you better have a good explanation why the process requires hindering the user in completing the task at hand. I know there exist good reasons why we ask users to jump through this hoop or that, but we need to make sure the user knows these reasons and sees why they are not a hindrance in completing the task but part of the completed task.
  - 3y ago

Joker_vD 3y ago

> That's the problem with medical personnel. They see the immediate act of "saving lives", e.g. putting a patient in a scanner ASAP, as their only job. All the documentation stuff is usually seen as a hindrance, sometimes as a way to cover someone's ass. Thankfully, we have reasonable people in the management: people who understand that it is maintaining proper documentation (and properly shifting liability) is the one and true purpose of the system; the "medical caring" (or whatever it's called) is simply a by-product that would fall out of it naturally. If only that stupid line personnel (and they are stupid because why else would they have applied to such lowly-paid job?) would understand that and would start to change the world so that it would to match the written documents and instructions (not the other way around, that'd be blasphemous).

hulitu 3y ago
The sad thing is that i wish that you were joking. Again to all SW engineers out there: If there is only 1 (one) input field on the application which has focus ( in A.D. 2023, 55 after the Mother of all demos was presented, according to Wikipedia), why do i have to click on this field before typing so that the characters typed do not go somewhere else ?

hulitu 3y ago

> If they could find a way to discharge patient from their unit with lowest number of clicks/keypresses they would do that, even if it meant marking the patient as deceased Real programmers don't comment their code. If it was hard to write, it should be hard to read. > Every implementation of rule checks would be met with backlash rather than appreciation for an extra pair of robotic eyes. When you are under pressure, the last thing you want is "an extra pair of robotic eyes" which constantly gets in your way.

IIsi50MHz 3y ago
Or, you DO want a rule-check, where it reduces incidence of critical errors that are known (due examnation of prior failures) to be more likely when under pressure.