Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I have two questions:

  Since the EMR is updated constantly, data from devices
  whose clocks are way off would simply never be recorded.
  Others might bury current information in older files.
  Worse, they may insert the data into the EMR when the
  patient they concern has left the given clinical
  environment and another has come in.
1. Why does the central EMR trust timestamps from the devices?

  Daylight saving time corrections twice a year require
  tedious manual tweaks that the MD PnP Program, an
  initiative supporting networking standards for medical
  devices, estimates cost American hospitals over $17m
  annually. At Massachusetts General, a patient-monitoring
  system deletes an hours' worth of data when rolling back
  from 2am to 1am every autumn, while drug pumps are kept
  permanently on standard time, so they are (at least) one
  hour off for half the year.
2. Why are they using time zones at all?


Hi. Written EMRs and built medical devices (10-12 years exp between them). In many cases messages from devices and external systems are processed asynchronously, so there isn't much choice but to trust remote timestamps.. I may be getting data minutes or hours later. Just a distributed system challenge.

The time zone issue is a human one. Historically clinicians schedule doses at "Every 3 hours" or "Once per day, 8am". Humans figure out what that means, but a dose scheduling system that shifts 8am an hour after daylight savings (because it interpreted the schedule as "every 24 hours" is going to run aground with nurses when it tells them they're late). However, every 3 hours is pretty obviously an interval and likely shouldn't shift by 30% of the interval!

This isn't a distinction that clinicians are used to making, but as someone who had to write some of the first dose-scheduling systems focused on clinical accuracy, we ran into this challenge and did a lot of thinking about which schedules really meant 'intervals' of specific units of time and which ones meant 'due at these calendar times every day'.

It's an interesting example of a problem that introducing technology introduces/exposes while showing up to fix other things.


Hi. Written EMRs and built medical devices (10-12 years exp between them). In many cases messages from devices and external systems are processed asynchronously, so there isn't much choice but to trust remote timestamps.. I may be getting data minutes or hours later. Just a distributed system challenge.

So I'm guessing you might solve that by asking the device what its internal clock is at the time of synchronization, and adjust the logs by the offset between device time and EMR time (with manual device time changes included in the log)?


Sure. If there was a 'time of synchronization'. There's generally not. The device often doesn't know when/if/who is consuming it's data. Likewise the EMR systems don't generally have any access to the device other than receiving a stream of messages some non-deterministic after they were produced.


As someone who works with devices which require good timekeeping, I'll add another question: if the devices are communicating with a central server, why doesn't that protocol include a time update from the server?




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: