6 ms·

That's a good point... things like "every 4 hours" gets complicated around the time change if you need things to align with a clock

alophawen 5y ago
Not necessarily, just track elapsed time and ignore absolute measures.
- sirmarksalot 5y ago
  And what sort of instrument might you use to track elapsed time?
  - gpm 5y ago
    A computer? Like the stopwatch app on your phone does. (I think I'm missing your point)
    - cornstalks 5y ago
      I think the parent's point was that most medical staff (in my experience) use normal wall clocks to track time. I've never seen a per-patient stopwatch.
      - gpm 5y ago
        I guess I'm naively assuming that there is some sort of patient management software which keeps track of what needs to happen when for whom, to enable things like shift changes without losing information. But I definitely don't have any idea how this part of the medical world actually functions.
        sangnoir 5y ago
        Such a system would be extremely disruptive to nursing staff- it may work well with robots though. Most hospitals track care on patients chart, which is computerized, but boils down to free-form text[1] that relies on humans interpreting,executing and updating the chart. 1. Patient care is very bespoke, with all manner of combinations for treatments, including contra-indicated medications. It's similar to why it's hard to automate air traffic control (lot's of human factors at play that require human decision making).
        adrianN 5y ago
        Coincidentally, misinterpretations or loss of these free form notes is a major source of problems in hospitals.
        sangnoir 5y ago
        To err is human. Until we develop a language that is perfectly unambiguous,all we can do for now is minimize chances of miscommunication. To continue on the air traffic comparison, sometimes the pilots land on the taxiway[1] despite clear instructions 1. https://www.cbc.ca/news/business/air-canada-investigation-ntsb-1.4646179 https://www.cbc.ca/news/business/air-canada-investigation-nt...
        gpm 5y ago
        To err is human, but the solution in that case is to replace human judgment with technology > Federal officials subsequently issued new rules for nighttime landings and control-tower staffing. Now, when an adjacent runway is shut down at night, air traffic controllers will no longer let pilots make so-called visual approaches to land. Instead, they must use instrument landing systems or satellite-based systems to line up for the correct runway. Not sure this supports that "unambiguous language" is the problem. To me it sounds like the problem is "humans being expected to perfectly perform routine tasks" - and the solution is to move as much of the task away from the humans as possible. I imagine there are parallels in the medical system (but am not expert).
        bobthepanda 5y ago
        The main complaint I've heard about EMR in the US is that it massively increased the bookkeeping overhead that staff had to deal with. Particularly since it tends to fall in the realm of "terrible enterprise software no one asked the users for opinions on." Some kind of punch clock system for every action would make that even more tedious, I imagine.
      - lordnacho 5y ago
        The big problem with that is you don't know if someone has done the time adjustment. Eg you know there's a handyman who does this twice a year, perhaps he's done it before the 2am official cutover time because his shift ended earlier? Or he'll do it the next morning? Similarly it's not obvious whether your phone keeps an eye on this for you, if you're not a techie type. And if you are, how do you know what your elapsed time stopwatch does under the hood? One of my cars gets time from the radio, the other one doesn't, so around this time of year they show different times.
  - girvo 5y ago
    Stopwatch.
  - deleted 5y ago
    [deleted]
  - alophawen 5y ago
    Measuring elapsed time in golang is as easy as: start := time.Now() // Code to measure duration := time.Since(start) See the docs for a good write-up: https://pkg.go.dev/time#hdr-Monotonic_Clocks https://pkg.go.dev/time#hdr-Monotonic_Clocks In rust you use https://doc.rust-lang.org/std/time/struct.Instant.html https://doc.rust-lang.org/std/time/struct.Instant.html
    - deleted 5y ago
      [deleted]
- elromulous 5y ago
  At the risk of being pedantic. No, these are not the same. And tracking elapsed is actually harder. Consider coding these two solutions (for n "patients"), in one you simply keep a timestamp of each and check against current time. In the other, you have many timers / stopwatches in parallel. The simplicity of simply recording the time and checking it against current time absolutely extends to the physical world.
  - elromulous 5y ago
    ps yes, you can implement n timers using a single underlying timer, but that of course requires even more book keeping, which was the point of my comment in the first place.
  - shhsshs 5y ago
    The two problems are almost exactly the same if you just use a time frame that does not change (permanent daylight savings, or never daylight savings)
    - aix1 5y ago
      The "almost" makes it sound trivial but hides complexity, e.g. around leap seconds. https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second
      - walnutclosefarm 5y ago
        Leap seconds are a problem too, but in entirely different settings, and in a way that is much better encapsulated in the software engineering world. I personally think the world would be better off without them, and that we should just let the clock/calendar drift back and forth, and in the long term off, true midnight. Outside of navigation and astronomy and a few other highly specialized fields, this has no meaningful impact, and would vastly simplify automated time recording. But it's a decision that has to be made globally, not nationally or locally, and requires a LOT of coordination to get right. It is also fundamentally different in nature, in that leap seconds never create duplicate times in the time sequence. Leap seconds are changes to the sequence of the underlying elapsed time sequence; DST changes are not, but only change the representation and use of time values.
- walnutclosefarm 5y ago
  I have heard this argument from software developers over and over again - not one of whom has ever actually worked through a shift in an ICU or critical care, or med-surg ward. I doubt if any of them have ever worked ANY shift work that spanned a clock change. The problem is not in the representation of time values in the system, it is in the system-human interface, and the actual work in the hospital that is tied to wall clock time. 2:30AM means something to these workers and patients, and having a shift or day when there are two 2:30AMs, or no 2:30AM f**s things up. That the software is poorly designed to support the change exacerbates the problem, but isn't the actual cause of it.

alophawen 5y ago

Not necessarily, just track elapsed time and ignore absolute measures.

sirmarksalot 5y ago
And what sort of instrument might you use to track elapsed time?
- gpm 5y ago
  A computer? Like the stopwatch app on your phone does. (I think I'm missing your point)
  - cornstalks 5y ago
    I think the parent's point was that most medical staff (in my experience) use normal wall clocks to track time. I've never seen a per-patient stopwatch.
    - gpm 5y ago
      I guess I'm naively assuming that there is some sort of patient management software which keeps track of what needs to happen when for whom, to enable things like shift changes without losing information. But I definitely don't have any idea how this part of the medical world actually functions.
      - sangnoir 5y ago
        Such a system would be extremely disruptive to nursing staff- it may work well with robots though. Most hospitals track care on patients chart, which is computerized, but boils down to free-form text[1] that relies on humans interpreting,executing and updating the chart. 1. Patient care is very bespoke, with all manner of combinations for treatments, including contra-indicated medications. It's similar to why it's hard to automate air traffic control (lot's of human factors at play that require human decision making).
        adrianN 5y ago
        Coincidentally, misinterpretations or loss of these free form notes is a major source of problems in hospitals.
        sangnoir 5y ago
        To err is human. Until we develop a language that is perfectly unambiguous,all we can do for now is minimize chances of miscommunication. To continue on the air traffic comparison, sometimes the pilots land on the taxiway[1] despite clear instructions 1. https://www.cbc.ca/news/business/air-canada-investigation-ntsb-1.4646179 https://www.cbc.ca/news/business/air-canada-investigation-nt...
        gpm 5y ago
        To err is human, but the solution in that case is to replace human judgment with technology > Federal officials subsequently issued new rules for nighttime landings and control-tower staffing. Now, when an adjacent runway is shut down at night, air traffic controllers will no longer let pilots make so-called visual approaches to land. Instead, they must use instrument landing systems or satellite-based systems to line up for the correct runway. Not sure this supports that "unambiguous language" is the problem. To me it sounds like the problem is "humans being expected to perfectly perform routine tasks" - and the solution is to move as much of the task away from the humans as possible. I imagine there are parallels in the medical system (but am not expert).
      - bobthepanda 5y ago
        The main complaint I've heard about EMR in the US is that it massively increased the bookkeeping overhead that staff had to deal with. Particularly since it tends to fall in the realm of "terrible enterprise software no one asked the users for opinions on." Some kind of punch clock system for every action would make that even more tedious, I imagine.
    - lordnacho 5y ago
      The big problem with that is you don't know if someone has done the time adjustment. Eg you know there's a handyman who does this twice a year, perhaps he's done it before the 2am official cutover time because his shift ended earlier? Or he'll do it the next morning? Similarly it's not obvious whether your phone keeps an eye on this for you, if you're not a techie type. And if you are, how do you know what your elapsed time stopwatch does under the hood? One of my cars gets time from the radio, the other one doesn't, so around this time of year they show different times.
- girvo 5y ago
  Stopwatch.
- deleted 5y ago
  [deleted]
- alophawen 5y ago
  Measuring elapsed time in golang is as easy as: start := time.Now() // Code to measure duration := time.Since(start) See the docs for a good write-up: https://pkg.go.dev/time#hdr-Monotonic_Clocks https://pkg.go.dev/time#hdr-Monotonic_Clocks In rust you use https://doc.rust-lang.org/std/time/struct.Instant.html https://doc.rust-lang.org/std/time/struct.Instant.html
  - deleted 5y ago
    [deleted]
elromulous 5y ago
At the risk of being pedantic. No, these are not the same. And tracking elapsed is actually harder. Consider coding these two solutions (for n "patients"), in one you simply keep a timestamp of each and check against current time. In the other, you have many timers / stopwatches in parallel. The simplicity of simply recording the time and checking it against current time absolutely extends to the physical world.
- elromulous 5y ago
  ps yes, you can implement n timers using a single underlying timer, but that of course requires even more book keeping, which was the point of my comment in the first place.
- shhsshs 5y ago
  The two problems are almost exactly the same if you just use a time frame that does not change (permanent daylight savings, or never daylight savings)
  - aix1 5y ago
    The "almost" makes it sound trivial but hides complexity, e.g. around leap seconds. https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second
    - walnutclosefarm 5y ago
      Leap seconds are a problem too, but in entirely different settings, and in a way that is much better encapsulated in the software engineering world. I personally think the world would be better off without them, and that we should just let the clock/calendar drift back and forth, and in the long term off, true midnight. Outside of navigation and astronomy and a few other highly specialized fields, this has no meaningful impact, and would vastly simplify automated time recording. But it's a decision that has to be made globally, not nationally or locally, and requires a LOT of coordination to get right. It is also fundamentally different in nature, in that leap seconds never create duplicate times in the time sequence. Leap seconds are changes to the sequence of the underlying elapsed time sequence; DST changes are not, but only change the representation and use of time values.
walnutclosefarm 5y ago
I have heard this argument from software developers over and over again - not one of whom has ever actually worked through a shift in an ICU or critical care, or med-surg ward. I doubt if any of them have ever worked ANY shift work that spanned a clock change. The problem is not in the representation of time values in the system, it is in the system-human interface, and the actual work in the hospital that is tied to wall clock time. 2:30AM means something to these workers and patients, and having a shift or day when there are two 2:30AMs, or no 2:30AM f**s things up. That the software is poorly designed to support the change exacerbates the problem, but isn't the actual cause of it.