Re: [tz] Epic fail for DST fallback in hospital health records
eggert@cs.ucla.edu said:
Gawande A. Why doctors hate their computers. The New Yorker. 2018-11-12. https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-compute...
Thanks for the heads up. In case anybody doesn't recognize the name, the A is Atul. He's a surgeon, and a very good writer. His first two books are collections of his New Yorker articles. My reading on this whole mess is that the medical community doesn't take testing software seriously. It may be as simple as senior executives with budget problems aren't willing to pay for testing because they don't understand that you have to do lots of it if you expect your systems to work reliably. For background, I highly recommend Gawande's Checklist Manifesto. He led a WHO project to get airplane style checklists used in hospital operating rooms. Not much about software, lots about checklists and the pilot/cockpit culture. For info about medical software, I recommend Robert Wachter's Digital Doctor. It's the study of a screwup at UCSF hospital that almost killed a kid. Lots of info about software and UIs and testing. https://www.goodreads.com/book/show/23131174-the-digital-doctor -- These are my opinions. I hate spam.
On 06/11/2018 20:21, Hal Murray wrote:
My reading on this whole mess is that the medical community doesn't take testing software seriously. It may be as simple as senior executives with budget problems aren't willing to pay for testing because they don't understand that you have to do lots of it if you expect your systems to work reliably.
The fact that the developers have made no provision for a well known problem is simple incompetence, and I would not be surprised if they were found liable if anybody was killed. Yes the software needs testing, but the simple operational requirements should not need to be explicitly specified in the specifications? ANYBODY designing a system that has essentially to work 24/7 and perhaps as a patient is being transferred across timezones should not be an area where they simply don't bother about using a stable timing system? But then if they are using windows anyway perhaps they don't even know that the clock changes sometimes? -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
On 11/6/18 17:04, Lester Caine wrote:
On 06/11/2018 20:21, Hal Murray wrote:
My reading on this whole mess is that the medical community doesn't take testing software seriously. It may be as simple as senior executives with budget problems aren't willing to pay for testing because they don't understand that you have to do lots of it if you expect your systems to work reliably.
The fact that the developers have made no provision for a well known problem is simple incompetence, and I would not be surprised if they were found liable if anybody was killed. Yes the software needs testing, but the simple operational requirements should not need to be explicitly specified in the specifications? ANYBODY designing a system that has essentially to work 24/7 and perhaps as a patient is being transferred across timezones should not be an area where they simply don't bother about using a stable timing system? But then if they are using windows anyway perhaps they don't even know that the clock changes sometimes?
As ever it's not as simple as that. Much of this software comes from mainframe days when these problems were not so 'well known'. I doubt there were any specifications and nobody thought about transferring patients across timezones. If you get (even peripherally) involved in the debate about updating or replacing these systems you'll find that it quickly degenerates into politics. As ever the developers get the blame but they are rarely allowed to fix the issues.
On Nov 7, 2018, at 9:52 PM, Michael Douglass <mikeadouglass@gmail.com> wrote:
As ever it's not as simple as that. Much of this software comes from mainframe days when these problems were not so 'well known'.
Daylight Savings Time was "well known" long before computers were used for hospital record keeping.
I doubt there were any specifications and nobody thought about transferring patients across timezones.
This isn't an issue of transferring patients across timezones. It's an issue of "what happens when the clock gets turned back?"
On 08/11/2018 08:26, Guy Harris wrote:
As ever it's not as simple as that. Much of this software comes from mainframe days when these problems were not so 'well known'. Daylight Savings Time was "well known" long before computers were used for hospital record keeping.
My own involvement with systems having problems with changes in time relates to railway systems 25+ years ago. At that time the UK trains did not run over night but it was coming in and we switched the underlying systems to UTC. As a side 'effect' it also solved problems with cross channel train movements since the Channel Tunnel had just opened!
I doubt there were any specifications and nobody thought about transferring patients across timezones. This isn't an issue of transferring patients across timezones. It's an issue of "what happens when the clock gets turned back?"
THAT is exactly the sort of statement that causes problems with any developments. It's just like the ones about historic time rules not being important. If one DESIGNS systems these days to be able to handle common activity then the risk of unexpected problems is reduced? The hospital records problem is only partially fixed by bodging over the time change. Fixing the problem properly by adopting UTC for all record storage prevents patients perhaps getting medication too early because they have been transferred 'down the road' to a better equipped facility ... in another time zone. -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
On Nov 8, 2018, at 12:44 AM, Lester Caine <lester@lsces.co.uk> wrote:
On 08/11/2018 08:26, Guy Harris wrote:
I doubt there were any specifications and nobody thought about transferring patients across timezones. This isn't an issue of transferring patients across timezones. It's an issue of "what happens when the clock gets turned back?"
THAT is exactly the sort of statement that causes problems with any developments.
THAT is exactly the sort of statement that you have managed to completely misunderstand. What *I* am saying is that, even if you don't need to worry about patients transferred across time zones, that doesn't mean you don't have to worry about DST time shifts. I.e., I'm saying that there are *more* things you need to worry about, not *fewer* things.
It's just like the ones about historic time rules not being important.
No, it's not. There are many situations in which historic time rules *aren't* important, and for which making the extra effort to make sure those rules are correct isn't worth it. "The best is the enemy of the good", and if, for example, we were obliged not to release any of the tzdb data files without spending time making sure we had the right standard <-> summer time transitions for pre-1970 dates, we might not gotten around to releasing them at all. Perhaps there are *some* for whom "no tzdb" is better than "a tzdb that doesn't claim to be authoritative for pre-1970 tims", but that's not the case for *all* users of the tzdb.
If one DESIGNS systems these days to be able to handle common activity then the risk of unexpected problems is reduced?
In answer to your question (yes, it's a question, otherwise it wouldn't have a question mark at the end), *that* depends on how they're designed. And there's no guarantee that dealing with multiple time zones is a "common activity" for all systems that have to handle standard <-> summer time transitions.
The hospital records problem is only partially fixed by bodging over the time change.
Nobody here is suggesting "bodging over" the time change. And somebody could "DESIGN" a hospital records system that "bodges" cross-time-zone patient transfers by keeping local time and requiring that times be converted to hospital local time either manually or by entering a special "here's the time zone for this time" indication, so worrying about cross-time-zone patient transfers doesn't magically ensure that you use UTC and avoid issues with the clock going backwards.
Lester Caine said:
My own involvement with systems having problems with changes in time relates to railway systems 25+ years ago. At that time the UK trains did not run over night but it was coming in and we switched the underlying systems to UTC. As a side 'effect' it also solved problems with cross channel train movements since the Channel Tunnel had just opened!
I had a bit of training from BR back in 1981 and asked what happened at summer time changes. I was told that in the autumn trains would just stop for an hour at the first station after the change, while in the spring they would just run late. There were overnight trains then: the sleepers. And in those days it was more complicated than now: for example, one of the northbounds out of Euston (I think it was the Perth sleeper) dropped a couple of coaches at Carlisle at 2 am. (They were shunted into a bay platform and you were left to sleep until 7.) Similarly one of the Penzances dropped/picked up at Plymouth. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 11/8/18 1:21 AM, Clive D.W. Feather wrote:
There were overnight trains then: the sleepers.
There still are: GWR's Night Riviera, Serco's Caledonian Sleeper, and (if you're wealthy) Belmond's Royal Scotsman. I rode a sleeper from London to Edinburgh long ago and would like to do it again some time if Serco ever gets their act together: Murray P. New Caledonian Sleeper trains slip to May next year. Inverness Courier. 2018-10-01. https://www.inverness-courier.co.uk/News/New-Caledonian-Sleeper-trains-slip-... I just now tried to schedule a slot in the Caledonian Sleeper from London Euston to Edinburgh Waverley arriving Sunday, 2019-10-27, which could be an interesting date given the disputes over Brexit and EU DST. Unfortunately for my experiment, that train doesn't operate Sunday mornings - which is perhaps the simplest way for a sleeper train operator to address the issue.
On 08/11/2018 20:43, Paul Eggert wrote:
On 11/8/18 1:21 AM, Clive D.W. Feather wrote:
There were overnight trains then: the sleepers.
There still are: GWR's Night Riviera, Serco's Caledonian Sleeper, and (if you're wealthy) Belmond's Royal Scotsman. I rode a sleeper from London to Edinburgh long ago and would like to do it again some time if Serco ever gets their act together:
Murray P. New Caledonian Sleeper trains slip to May next year. Inverness Courier. 2018-10-01. https://www.inverness-courier.co.uk/News/New-Caledonian-Sleeper-trains-slip-...
I just now tried to schedule a slot in the Caledonian Sleeper from London Euston to Edinburgh Waverley arriving Sunday, 2019-10-27, which could be an interesting date given the disputes over Brexit and EU DST. Unfortunately for my experiment, that train doesn't operate Sunday mornings - which is perhaps the simplest way for a sleeper train operator to address the issue.
Sleepers were never a problem since they never stopped in the overlap hour. The systems I was upgrading in the early 90's could only display a days worth of traffic, and the day ended at 2AM. Stations on the lines I was working on had normally closed long before that and the systems were switched off. The new day saw a new timetable and often a paper set of updates which the morning staff had to make before services started. My system handled a 24 hour rolling timetable so the night staff could make any manual updates, although the whole system was managed centrally for a line so only one update was needed, but the politics of who does what STILL plagues the UK railways today! -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
Lester Caine said:
There were overnight trains then: the sleepers.
Sleepers were never a problem since they never stopped in the overlap hour.
Um, they used to. As I said, one of the Euston-Scotland sleepers dropped a couple of carriages at Carlisle around 2 am. I remember this because someone booked me on the wrong sleeper - the preceding one *stopped* at Carlisle at 2am but didn't drop sleeping carriages there. Luckily I was able to get off at Watford Junction and sort it out there. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
participants (6)
-
Clive D.W. Feather -
Guy Harris -
Hal Murray -
Lester Caine -
Michael Douglass -
Paul Eggert