Know What Time It Is? Your Medical Device Doesn't 290
An anonymous reader writes "A man with one clock knows what time it is, goes the old saw, a man with two is never sure. Imagine the confusion, then, experienced by a doctor with dozens. Julian Goldman is an anaesthetist at Massachusetts General Hospital in Boston. After beginning to administer blood-thinning medication during an urgent neurological procedure in 2005, Mr Goldman noticed that the EMR had recorded him checking the level of clotting 22 minutes earlier. As a result, four hospitals in the northeast had their medical devices checked, and found that on average they were off by 24 minutes. The easy solution that devices could have used since 1985? NTP."
It won't help (Score:4, Informative)
First, they will use Windows Active Directory for NTP because someone will say "it's authoritative for the whole network". And their clocks will be off.
Then they will run into config hell, and blaming that for clocks being off - they will load balance the domain controllers. Which is precisely what you're not supposed to do with NTP. And their clocks will be off.
Then, some small but relevant IT subgroup will secede, claiming that they need "real" NTP. "Network Security" folks are typical suspects here. So their clocks won't match the rest of the gear (which is still off, remember?)
If you have poor enough technology discipline that your clocks are 24 minutes off already, you're probably screwed.
Re: (Score:3)
First, they will use Windows Active Directory for NTP because someone will say "it's authoritative for the whole network". And their clocks will be off.
Then they will run into config hell, and blaming that for clocks being off - they will load balance the domain controllers. Which is precisely what you're not supposed to do with NTP. And their clocks will be off.
Active Directory time synchronization works properly if you have a competent sysadmin and set it up correctly. If you don't have competent sysadmin it doesn't matter the technology or vendor you are using, you will get it wrong.
Active Directory domain controllers don't need external load balancing, they automatically distribute work out of the box. When configured correctly they also set up a proper NTP time hierarchy.
Re: (Score:2)
Translation: "you are all f&*$ed", cos you KNOW that can't happen.
NTP - wrong answer (Score:3)
Medical devices should not have Internet access.
Receiving time from a GPS receiver is much safer. That's a broadcast signal with a fixed message format.
Re: (Score:3)
From my experience in hospital environments, radio reception is often VERY poor. You've got lots of metal in their construction that tends to block signals. Doubtful you'll have any luck receiving a time signal via GPS unless you plan on running antennas all the way up to the roof of the building.
As I posted already, NTP is a perfectly good way to solve this problem. You simply have ONE system designed to be your time server, which synchronizes over the Internet via NTP, and then all the firewalled off dev
Re:NTP - wrong answer (Score:4, Insightful)
Better yet: this is not an application that requires microsecond precision--within a minute or two is fine, particularly as long as all the clocks agree with each other. Completely private network with a master NTP server that is updated by hand every week or so should work fine.
Re: (Score:2)
You can always set up a network with trusted only devices. It requires some work but it will pay off in the long run.
Re: (Score:2)
I looked into this last year for a project and it is actually pretty hard to get an accurate time signal cheaply inside a building. NTP works but needs ethernet and TCP/IP, and either a cable or wifi (which means WPA authentication etc.)
GPS is very accurate but tends not to work well indoors, especially in rooms with no windows like most operating theatres. Around the world there are various low frequency time signals (DCF77, JYY, MSF etc.) but like GPS reception can be a problem. I live in the UK and DCF77
Re: (Score:2)
So... don't. NTP works just fine on a private network. And you don't even need a proper time source, either. As long as everything ticks within a narrow boundary of time, it doesn't really matter if the master NTP server clock is off. If it's stable, the offset between it and the real time would be well known.
NTP's just a way to distribute the time. It doesn't have to be used to distribute exact time. As long as everything's ticking to the same clock, things
Re: (Score:3)
Receiving time from a GPS receiver is much safer. That's a broadcast signal with a fixed message format.
A fixed what? [ibiblio.org]
Depends on the purpose of the medical device (Score:2)
Medical devices should not have Internet access.
That depends entirely on the purpose of the medical device. "Medical devices" covers a lot of products that serve a lot of different purposes. For some devices internet access would be pointless, for others internet access would be dangerous, and for still others internet access makes perfect sense. It depends entirely on what you are doing with it and what the risks are. There is nothing inherently wrong with hooking up a medical device to the internet, provided that the risks of doing so have been ade
Re: (Score:2)
Not a problem, as almost all GPS time sync devices are mounted on the roof. (Hint cement and rebar that hospitals are made of is bad for satellite reception)
I'm guessing you dont know much about network time sync devices and how they work. And the MRI machine has a funny cable that runs in to the control room that has the magical ability to bypass a faraday cage.
Re: (Score:2)
Good luck with that in an MRI-rated room...
hint: Faraday
hint: you don't need/want GPS in every fucking device, you need ONE GPS somewhere far away from your MRI (say, on the roof) since you have ethernet everywhere else in the entire building.
Re: (Score:2)
Consider that they need not even setup a dedicated server, most core networking gear can provide authenticated NTP by itself with a battery backed up RTC with enough accuracy to keep within a few seconds a year. Consider that some of these devices already have a network connection to talk back to the EMR software anyways.
Setting up a whole new standard is foolhardy, setting up a RF based standard in a hospital setting is looking for trouble. Adding a procedure that needs to be done is just adding cost. I
Re: (Score:3)
No, the server would go into free-run mode if it cannot receive a signal, and all of the clocks would be the same, just with a little bit of drift. And even if the servers went down, in the worst case, the devices would do the same thing, which means even in the worst case, you would be no worse off than you are now, and realistically, because NTP provides drift compensation statistics, they would probably drift far less than t
News FLash.... (Score:2)
Most devices dont. In fact it's highly rare for a device to NTP sync.
Most building lighting control systems do not do a NTP sync. Security systems, etc... all rarely do this.
It sounds like that someone finally realized that clock drift happens and is shocked about it.
Re:News FLash.... But WHY? (Score:4, Insightful)
My quartz LCD watch from 1985 was accurate to within 1 second per year. That would WAY outlast the usefulness of the medical device. There should be no way in the world that device was off by 24 minutes.
Right now, I'm dealing with the same problem in my brand new car. It has a fancy on-board computer with a screen that tells me gas mileage, service info, mp3 and radio interface, etc.... The clock is ridiculously fast (gains 3 minutes a week). My new $20,000 car should have a clock in it at LEAST as accurate as the watch I can get from a happy meal.
NTP, GPS, PTP all have problems (Score:4, Interesting)
NTP have the problem of discontinuing his UTC timestamp while a leap second occur and NTP do not broadcast the actual UTC-TAI offset (historically because he broadcast UTC directly but this is now more a problem that an advantage). GPS and PTP broadcast (something very closely related to) TAI and a UTC-TAI offset, witch is the right thing to provides the precise actual time without discontinuity.
But all of them, NTP, GPS and PTP, have the problem of not broadcasting the historical leap second table, making the client of those protocols alone unable to safely compute a precise date in the past. I hope next NTP protocol will broadcast TAI, and that NTP, GPS and PTP will be able one day to broadcast the leap second table. I am certain that there is still some reserved bits somewhere in those protocol to make that working.
Re:NTP, GPS, PTP all have problems (Score:5, Insightful)
Look if the options are 24 minutes of random error or say 24 seconds of consistently biased error in all the devices in the hospital, I'll take the consistent bias any day. The point of all of this is so that a nurse walking into the room and seeing a blue lipped coma patient can determine things like how long has it been since the monitor whose leads fell off last recorded an accurate O2 saturation.
clocks (Score:2)
"A man with one clock knows what time it is, goes the old saw, a man with two is never sure."
That's why the sailor's adage is to take one clock or three to sea. With one, well, that's all you've got to go on. With two, you never know which one is right. With three, usually at least two agree.
Not so simple (Score:3)
We are talking about medical equipment that would have to be certified by the FDA. That would mean that every GPS receiver and every implementation of local NTP would have to go through a rigorous and costly certification process. The following issues would have to be certified;
1. Is the device accurate.
2. How does the device interact with the software.
3. How does the device interact with every device receiving data. This is the hard part.
Secondly, is it even necessary? The issue seems to be that there is an offset between the clock on the equipment and actual time. How about at the beginning of the operation the doctor writes down all the times as stated on the medical equipment. If necessary these offsets can be applied later to normalize the times. This reminds me of the time when the US spent tens of thousands of dollars to build a pen that would work in zero gravity(it was pressurized with gas). When a cosmonaut was asked how they coped he said "In Russia we use pencil". Sometimes high tech just complicates the issue.
Bad administration is a major problem with this (Score:5, Informative)
This is often a case of poor administration, perhaps more frequently than poor design.
For example, I was recently tasked with reviewing the performance of several hospitals in the diagnosis and treatment of stroke. Under national guidelines (UK) a patient with suspected stroke must have had a CT scan within 30 minutes of arrival at hospital, with blood-thinning treatment administered within 60 minutes (if appropriate).
The problem was that the times on the CT scanners were discrepant by +/- 45 minutes from true time - so the images were tagged with the incorrect time. Further, the CT viewing workstations had times up to 2 hours discrepant. The CT scanners were Windows or Gentoo depending on the manufacturer's preference. Similarly, the CT workstations were windows, and were all bound to the hospital domain.
The time discrepancies made my assessment very difficult - and I had to correct for each individual scanner, and assume that the clocks hadn't drifted over the 6 month period of the audit.
I also found several safety issues because of this - e.g. if it was 1am, and a patient had a CT scan, some workstations would be 2 hours slow, so would read 11 pm on the previous day. These workstations would refuse to load the CT scan because the files were filtered by "WHERE [StudyTime] NOW".
I raised a support issue with the workstation vendor who simply said "These are windows workstations. You should ensure that they are appropriately bound to your domain, and configured to sync with your time server or domain controller". So I called IT to configure this, "No way. These are medical devices, we can't change the configuration - and anyway, what will happen if the clock is fast, and the sync pushes the clock back, so that there are 2 occurrences on the same time. That would cause chaos. Even if the manufacturer supports it, there's no way we'll set it up". Of course, their concern doesn't actually exist, because most time sync algorithms (even on Windows) are clever enough to avoid "double time".
There was similar obstruction with the CT scanners. The vendors simply said - we support and encourage synchronisation with a time server. IT or the radiology administrators simply stonewalled the ideas. They refused even to correct the clocks on teh scanners - so the clocks are still wrong to this day (even more so, due to accumulated drift).
Of course, even if the time can be set right - there is disagreement as to how daylight-saving is managed. Some equipment, esp. older embedded kit isn't daylight-saving aware. Do you set it to Summer time or winter time? In most hospitals I've been in, it's been an inconsistent mixture - often with lots of clock drift added, so you can't actually be sure.
Just incompetence (Score:3)
When I had a hospital gig, we knew back in 1995 that time would need to be syncronized amongst all the servers etc. We ran a local time server synched to a Tier 1 NTP server which was fortuitiously about 180 miles away. It has since gone to restricted access, but it's nailed to the USNO, and is still a Stratum One server. I bet they still use it as reference.
But even in 1995, NetWare servers were well behaved and accept NTP, and we set workstation time on login. As other servers came on, we went through the inevitable 'my server is more accurate' and blew them off until the Sun server showed up,and they refused to use our NTP. Fine. Took two weeks to resolve a 300ms difference, and then I watched as they re-fixed the error and synched with the NTP server they initially refused to use. In fariness, it was not SUN engineers involved, but they were arrogant enough to qualify.
Time is important to networks.
We did not, however, have any way to manage time on 'devices', such as infusion appliances etc. I do NOT think of an EMR as a 'medical device'. Nor do I think of the EMR sytem that way either. But if time isn't being synched on your network, you got some other problems, I suspect, that are not making your work easier or efficient as a network admin.
Never Trust the Client (Score:3)
I would never trust the reported time from any device. Use the time that the recording system receives the data as the time of record (and poll data often.) Who cares what time the device thinks it is, along as it tells you the current data "now" and YOU know when "now" is?
Run your own NTP if it matters (Score:5, Insightful)
Re:Run your own NTP if it matters (Score:5, Informative)
Easy, get a GPS receiver and use its time. The point is that the times all need to be the *same* (so things that happen at the same time are recorded as such); accuracy is secondary. Even if every week or two some guy goes and fixes the clock on the server, that should be acceptable.
Re:Run your own NTP if it matters (Score:5, Funny)
Tinfoil hats, third level, on the right.
Re:Run your own NTP if it matters (Score:4, Funny)
Odd, I got here and a guy gave me a nice long sleeve jacket, but there's no tinfoil.
Re: (Score:2)
Re:Run your own NTP if it matters (Score:5, Informative)
Re: (Score:2, Funny)
That's exactly what we want you to think, Mr. Luis Howard Alvarez, currently sitting at the second table on the left from the side door at Starbucks on Cullen Street in Kansas City, Missouri.
Re: (Score:3, Informative)
You should be a little less paranoid about GPS.
Just because you can find the time and your position using GPS doesn't mean someone can track where you are.
A GPS device is a receiver, not a transmitter.
GPS satellites constantly broadcast the time, and their location. A the GPS in the device takes this data from several (4+) satellites, does the math, and calculates the position.
For this to work the time has to be absolutely correct. So you can use the time to set your clock.
Without some sort of transmi
Re: (Score:3)
Yeah, I see that going over well... How does it keep time? Oh GPS. Don't worry, we aren't tracking you. No thanks, I'm going to get a second opinion.
Modded insightful, even.
Protip: GPS receivers do not transmit. Unless you buy one that is attached to, you know, a transmitter like a cellphone.
Crikes.
--
BMO
Receivers transmit (Score:3)
Re: (Score:3)
Differences other than the fact that it's much lower power and that it's not transmitting any meaningful information?
Even assuming you had a ridiculously sensitive receiver capable of of listening to GPS receiver's local oscillator you can't differentiate - you can only detect receivers operating at frequency X, and since just about every damn cell phone has GPS these days that's damn near useless for tracking anyone, you've got thousands of blips anywhere with people, and they're not stationary like your T
Re:Receivers transmit (Score:4, Informative)
There is nothing in the vans.
They just have a list of those who haven't paid the tax and go 'round harrassing people. It's easier and doesn't cost as much as a van full of equipment and high-paid engineers.
Emperor
Clothes
None.
--
BMO
Re: (Score:3)
And how do you go back in time and fix all existing machines, and who pays for it. Even in a new machine this is expensive in an era when everyone's trying to cut costs.
True dat. This is really the big problem. I worked on an ICU monitor system design many years ago (1978 IIRC). The design was cool, total cost of development and productizing back then would have been maybe $100K. But the company discovered that it would cost several $million to get through the various levels of certification and approval to allow hospitals to use it. And once it's developed, even a resistor change would have required the same process again. Based on the projected market, amortizing t
Re:Run your own NTP if it matters (Score:5, Insightful)
At least then all data logged will have a correct relation and timing of events can be managed if necessary.
If every computer has it's own time then it's impossible to get things straight about when did who do what. And that's critical if something happens and you need to figure out how to correct it so it won't happen again. Of course - it can also be used in the blame game.
And it's not a big problem for a hospital to use NTP if the source used is trustworthy. GPS receiver and/or a trusted NTP server on the net.
Re: (Score:2)
At least then all data logged will have a correct relation and timing of events can be managed if necessary.
If every computer has it's own time then it's impossible to get things straight about when did who do what. And that's critical if something happens and you need to figure out how to correct it so it won't happen again. Of course - it can also be used in the blame game.
And it's not a big problem for a hospital to use NTP if the source used is trustworthy. GPS receiver and/or a trusted NTP server on the net.
Don't bother, this guy clearly works in a private healthcare environment, given his complete disregard for *actually* improving the quality of care and instead his direct instinct to preserve his job and/or revenue stream. Anyone who takes more than a casual look at private healthcare can see that there are so so SO many ways to do things better that get completely ignored in favor of doing things the current way, or doing things in a way that makes it easy to dodge a lawsuit.
did I say that?
Re: (Score:3)
Canada? At least there you'll get the treatment eventually. 4-5 hour waits with an empty ER are pretty common in my city. Phoenix, AZ
Re: (Score:3)
Re:Run your own NTP if it matters (Score:5, Informative)
How would that change anything? It just makes all the clocks on the hospital go wrong when it starts to move to wrong times on the NTP server.
You can have one local timeserver that syncs with external trusted servers (nist.gov). All of your local devices can sync with your local ntp server.
Updating it from public sources is out of question too. Think about someone injecting completely wrong time to the hospital.
NTP is *pull*, not push. We've had decades now to bulletproof NTP. It will be pretty easy to nail an NTP server down so it's only going to be serving NTP.
The medical and legal professions are the most IT challenged disciplines I've ever seen, but that may be largely due to excessive gov't regulation.
Re:Run your own NTP if it matters (Score:5, Informative)
We've had decades now to bulletproof NTP
... and in fact we've already done so. [nist.gov]
There is no excuse for failing to implement it.
Re: (Score:3)
There is no excuse for failing to implement it.
They don't want an excuse.
I've watched accountants transcribe a column of numbers in a spreadsheet into a desktop calculator to sum the column. They can't even use the software they've got! What difference would it make to give them another suite of software they can't use, but which would be vastly cheaper and work just as well (or better)?
I no longer have any patience for this shit. I don't believe a word of that BS about introducing another suite would lead to insurmountable problems for the users. T
Re: (Score:2)
DNS cache poisoning.
Re:Run your own NTP if it matters (Score:4, Insightful)
Yes it does. As long as all the devices are using the same time server, the problem does not exist. You need consistency not accuracy.
Most hospitals and surgical centers I have dealt with use a master clock system that wirelessly updates time on all devices to about 1-second accuracy. That wouldn't necessarily include things like EKG or blood oxygen meters, hence the issue in the summary-- those devices do not have a central time source typically, although the telemetry systems could add it in to have a common reference.
Re: (Score:2)
2 *years*? Sounds like a management problem, not a technological one.
Re: (Score:2)
How the Hell do they even do that? Any half-way sane NTP configuration will ensure that a server won't even supply a time unless it can itself get a time from a higher-stratum NTP server.
Re: (Score:3)
You obviously have little experience in education.
My sister's a twenty year veteran elementary school teacher. I've heard all about it.
IT challenge is related to gov't regulation how?
Lawyers and doctors still use fax, because faxed signatures are accepted for legal purposes. Both legal and medical professions have draconian requirements for client and patient data protection. Just read any story related to medicine or law and note their paranoia about connecting *anything* to the Internet. If it's not regulatorily required, it's fear of being sued.
And please do tell how this unspoken rational outweighs simply being cash strapped and crisis focused?
I don't believe they are cash strapped. Their syste
Re:Run your own NTP if it matters (Score:5, Insightful)
In many cases, consistency between two clocks and moving at the correct rate is FAR more important than absolute correctness. For example, it hardly matters if the hospital's clocks all think it's Feb 3rd 213AD so long as you know that the patient's last dose was 3 hours ago. If the clock in the patient's room thinks it's an hour later than the one in the recovery room, that could matter.
Re: (Score:2)
Including the clock in the hall. Everything but the doctor's watch. Therefore, for the most part, all of them would be self-consistent. The reason this was a problem is that the doctor nearly performed a medical procedure twice because one person was using one clock as a baseline and another person was using a different clock. If all the clocks use the same baseline, they will all be the same.
Re: (Score:3)
This is correct, but you have masked the real problem with the GP post.
The clocks are wrong now.
Which means that getting them even closer to right is better than nothing at all.
GP is your classic "too smart" idiot geek: if a solution isn't perfect, it's not a solution.
Re: (Score:2)
You do realzie there is a Should the hospital not trust that? [nist.gov]
Re: (Score:2)
WTF, slashdot ate half my link text...
Grr. My point is there is a secured NTP service provided by NIST. Hospitals should be able to trust that, for outside synchronization.
Re: (Score:2)
Having everything on the same clock seems far better than having things on their own out of sync clocks.
Sure that one device says it did something at 1:15pm doesn't mean it actually did, but if another device says the current time is 2:15pm then it was an hour ago since they are both out of sync with the actual time by the same factor.
And of course whenever there's some sort of external check (a nurse looking at their watch) then to fix the device all the devices get fixed rather than just that one. So your
Re: (Score:2)
Re: (Score:2)
Flammable
Inflammable
Welcome to the English language.
Re:NTP and hospitals (Score:5, Informative)
NTP does not require access to public networks. Private time servers, usually GPS sourced via rooftop antennas, are very common.
Re: (Score:2, Interesting)
I am just playing with one said GPS unit. US$50, plus USB/Serial cable, plus conversion chips. 4h work, less than US$80 in hardware. There are ready made units for around $400, with a rubidium standard if the GPS is not available.
Not having a time standard is beyond not acceptable.
Re: (Score:3, Funny)
our society is further behind then I've calculated.
Your calculations are right. The problem is your clock is way off.
Re:NTP and hospitals (Score:5, Insightful)
You don't need to connect to an outside server. You can easily run your own time source (GPS is really easy these days), or have the devices talk to a single internal server which then securely contacts outward. If they're off, at least they're all on the same time. It's really dangerous if everything is reporting different incorrect times.
Don't even need GPS; can use FM radio! (Score:2)
Most places have an FM broadcast that is synchronized to an atomic clock. Ever seen one of those "radio clocks" that never needs the time set? It's using FM to know what time it is.
Put an FM antenna on the roof, hook it up to an NTP server, problem solved.
Re: (Score:3)
Well, there is the Radio Data Service that can synchronize time using actual FM broadcasts, but I guess I should have been more explicit.
What you're talking about is using a WWVB receiver. Also a good idea, especially since it comes directly from NIST at Boulder, Colorado.
Point remains, you don't need GPS, and you don't need Internet.
Re: (Score:3, Insightful)
The easy solution that devices could have used since 1985? NTP.
Holy hell, what about no? There's a huge reason why hospitals try to keep off networks, especially public ones. Do you really want to connect all the timing devices in a hospital to an outside public server? Because running it yourself does no good, it can just fuck up all the devices in the hospital.
Sometimes the ideas non-thinking geeks come up truly scare me.
No one said the NTP server had to be external. NTP is just a method to keep a bunch of clocks synchronized to an arbitrary master.
Sometimes the stupidity of non-technical and non-thoughtful people scare me.
Re: (Score:3)
It'd be more expensive than just having IT bring a patch cable; but there isn't anything about "NTP" that requires putting gramps' pacemaker on the internet...
Re:NTP and hospitals (Score:4, Informative)
Actually a linux server on it's own you can calibrate the system clock to be incredibly accurate. you can calculate the drift of the cmos clock and adjust to get pretty darn accurate.
http://tldp.org/HOWTO/Clock-2.html [tldp.org]
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
The issue isn't accuracy. As you mentioned, even being off by a minute or two is rarely important. The problem is that all the little medical gizmos are not and will not be on any sort of network. The security ramifications of putting every last IV pump on the hospital network are simply too great to deal with, at least at present. Nobody is going to set up yet another network for time signals.
For larger, already networked machines - at least modern ones already are talking to a time server. Just looked at
Re: (Score:2)
"Atomic clocks" can only sync at night. You don't actually think the atomic mechanism is built into the clock, do you?
Atomic clocks based on hyperfine transitions of electrons in rubidium-87 [wikipedia.org] are readily available commercially for a couple thousand dollars.
NTP Is Just a Protocol, Not a Specific Server (Score:4, Insightful)
Re: (Score:2)
*blink* how can running your own NTP server taking time from GPS "Fuck up all the devices in the hospital" ?
Re: (Score:2)
If you have multiple NTP servers, then your suggestion of "haywire" is moot. (I love your haywire suggestion by the way, that it's guaranteed to fail in such a way to cause everything to drift.... Oooohhh bogeyman!) Also, buy a dedicated device. I have GPS based NTP servers which now have an uptime of the last time I moved them (6 months). Before that, the uptime was from when they were comissioned (4 - 5 years ago). We measure their drift in nanoseconds.
As you point out though, it depends on what the appli
Re: (Score:2)
Holy hell, what about no? There's a huge reason why hospitals try to keep off networks, especially public ones. Do you really want to connect all the timing devices in a hospital to an outside public server?
NTP works on private networks too. Set up your own internal NTP service.
Because running it yourself does no good, it can just fuck up all the devices in the hospital.
I'm not sure what you're trying to say here. But it strikes me that having a common time seems to have more upside than down (at least for devices that need to have an internal time clock).
Re: (Score:3)
I don't get why people (like the parent poster) are blowing this up, out of proportion?
You don't have to expose all of the hospital devices/systems to the Internet, just to ensure they all have the same, accurate clock time!!
All you need is ONE device permitted to access the proper port for NTP protocol through a firewall, to set its own clock as the master, and then have it redistribute the date/time info to the remaining devices on the hospital's LAN!
It's not like the hospital doesn't already have Interne
Re: (Score:3)
There's a huge reason why hospitals try to keep off networks, especially public ones.
And yet device makers create equipment that requires their time to be set...
I can't help but wonder why they don't use a different report style. If you want to look at the log to see when the last event occurred, why not report in elapsed time? Like:
20 min ago: 10cc of supermed dispensed
40 min ago: 5cc of supermed dispensed
60 min ago: unit reset
Re: (Score:3)
I thought of another good solution - when the electronic reporting system polls a device, it should ask the device what time the device thinks it is, and then adjust the report from the device accordingly.
Older devices without either the option to report in elapsed time or the ability to tell you the current time would be a problem. You'd have to either ignore the timestamps until someone manually verifies the time - which would be a joke since everyone would just click "Verify" without actually looking at
Re: (Score:2)
As I understand it (which may be incorrect) a lot of units that are timed devices, just reference themselves. If you set an IV pump to dispense #mg every 5 minutes, it doesn't check the time, it only waits for that interval to pass. You don't want every device to be network attached. If you're on 5mg morphine once every 5 minutes (60mg/hr), it would be rather bad if some network based exploit changed the reported dispensed fluid to saline, and changed the rate to 10mg/min (600mg/hr). It
Re: (Score:2)
Mod the parent up. I used to program IV pumps and this is exactly what was done. You never used the wall clock or "display time" for dosages. It was always based on a rate and the internal clock always kept track of time differentials, not the actual time.
Re: (Score:2)
Can't speak for all medical equipment, but I worked on a major IV pump and it used time in exactly this way. The dosages were rate or interval based and the pump strictly used the internal clock to calculate elapsed time. There was a "clock" on the display but it was only used for display purposes, you could set it for 1:00 am Mar 3, 1983 and it would still work correctly.
Re: (Score:2)
You're absolutely correct. It seems intuitive to us that all devices should be networked. An in-house NTP server would satisfy this time sync need. As we've already seen with many other things, even a machine with no network access can be compromised by another that does.
I happened to be in a doctors office (out patient surgical suite) today. Everything had a sign-off sheet with it, where someone would check everything daily. Even the portable O2 tanks were checked to ma
Re:NTP and hospitals (Score:4, Insightful)
hospitals try to keep off networks, especially public ones
The sysadmins try, but fail. Most hospital networks and devices ARE connected to the internet in some way. Doctors want their access from the various desktop machines, of course, but many of the diagnostic machines offer things like "click this button to email the ultrasound pictures". So they do.
I was appalled to learn this a few years ago from a hospital sysadmin here on /. The thing he pointed out is that Doctors are Gods. If they say "This thing can email pictures? Well yeah, hook it up!" then the sysadmin has zero choice. Holes get punched in firewalls that should never have been punched, and the gear gets hooked up.
And because medical devices are certified only to work with a particular operating system at a particular patch level, they don't get upgraded unless the vendor comes out with a new certified patched OS. That means the ultrasound machine sitting on that cart might still be running Windows XP SP 1. It's crazy.
NTP would actually be the least of their worries. That's something they could more easily house internally.
Re: (Score:3)
" Because running it yourself does no good, it can just fuck up all the devices in the hospital."
IF your devices are set to "fuck up" when time changes, you are buying really low grade crap.
NTP server on closed network for hospital devices, it's source is a GPS timing signal. Zero internet access, provides NTP and a accurate time signal.
This is SOP in any secure environment.
Re: (Score:3)
The easy solution that devices could have used since 1985? NTP.
Holy hell, what about no? There's a huge reason why hospitals try to keep off networks, especially public ones. Do you really want to connect all the timing devices in a hospital to an outside public server? Because running it yourself does no good, it can just fuck up all the devices in the hospital.
Sometimes the ideas non-thinking geeks come up truly scare me.
So the GPS synced clocks used to generate microsecond-accurate timing distributed via NTP for utility billing, high speed trading, and a million other mission critical (read: *beyond* life critical) things aren't good enough for your EMR tablet to update on once a day? Sure thing. Keep hiding under that table.
Re: (Score:2)
Who is talking about connecting to an outside server : just have one ntp server running in the hospital, and all devices synchronize to that.
Then at least all the devices in the hospital will be synchronized, which I guess is the most important.
Re: (Score:2)
The easy solution that devices could have used since 1985? NTP.
Holy hell, what about no? There's a huge reason why hospitals try to keep off networks, especially public ones. Do you really want to connect all the timing devices in a hospital to an outside public server? Because running it yourself does no good, it can just fuck up all the devices in the hospital.
Sometimes the ideas non-thinking geeks come up truly scare me.
So the problem posited by TFA is that device clocks with the wrong times lead to improper treatment. The solution offered is a central time server utilzing the NTP protocol. You've stated that this can just fuck up all the devices in the hospital. (I'm assuming you're getting at the problem of a time server gone bad setting the wrong time for all devices in the hospital.)
So now we weigh the risk of improper treatment due to time differences between devices vs. the risk of an time server failure. To make
Re: (Score:2)
Facilitating exchange via networks is a major purpose of an EMR system, so this isn't generally the case with EMR systems, or (transitively) with devices that interface with EMR systems.
NTP inside the organizati
Re: (Score:2)
You know, as long as the devices in one hospital keep the same time, it doesn't really matter if that time is off by any amount. The important thing is to have all clocks in one building showing the same time, so that the correct elapsed time can be told with just a quick glance. In a medical context, that's usually more important than the current local time.
Re: (Score:2)
Why not just use radio [nist.gov] instead?
Nice theory, although if the couple of "atomic" clocks I have around the house are any indicator, it's not a great plan. They only can pick up the radio signal at night (something to do with the ionosphere IIRC), and this in my house with windows in every room. In a hospital? Good luck...
Re: (Score:2)
could be used to seed the local lan NTP server for hospital devices... even if it checks for error nightly, its bound to be off by a few micro seconds...
Re: (Score:2)
A proper antenna on the roof, some filters and/or an amplifier would solve the problem. Not a problem for a hospital.
Re: (Score:3, Funny)
Oh noes!!! My android phone will make me 15 seconds early to any appointment!!!! I must therefore dump it and become and apple fanboy.
Re: (Score:3)
It's better than being a rabid android fanboy you are now.
P.S. Nokia phones also did the 15 second adjustment. Google just figures it is not important and also get's its time from the cellular towers that just happen to get their signal from GPS.
Re: (Score:2)
Ah yes, because mechanical clocks that are hundreds of years old automatically adjust for leap seconds.
Re: (Score:2)
Different problem. The medical devices were all set inconsistently. The Android "problem" you describe may slowly diverge away from iPhones, but at least they are consistent.
That's what the proverb in the post implies: consistency is what matters.
PS: since when do cell phones take the time from GPS instead of the cell network? I'm pretty sure my phone synchronizes to Verizon's towers. I usually keep GPS disabled.
Re: (Score:2)
As a result, nearly all Android devices are 15 seconds too fast. Note that iOS compensates for this and shows the correct time.
Then Android devices are not 15 seconds too fast. And GPS isn't either for that matter, you just need to know the offset and you're golden. An accurate clock and a precise, well known offset means you aren't too fast or too slow.
Re: (Score:2)
Few people realize this, but Android phones don't keep time correctly [businessinsider.com]. They use GPS satellites for timekeeping, which was last updated in 1982, and since then there have been 15 leap seconds added. As a result, nearly all Android devices are 15 seconds too fast. Note that iOS compensates for this and shows the correct time.
Hmm. [looks at NIST synced PC clock] Hmm. [looks at android phone]
Nope, the two match exactly to 1 second. Unless for some reason my ordinary Android phone (of which over 15 million of this exact variety were sold) qualifies as outside "nearly all" android phones, you are spouting pure nonsense.
Re: (Score:3)
1. You don't know how GPS works
2. You don't know how network time is set
3. You don't know how atomic clocks work.
4. You don't know fucking anything about leap seconds and how they're handled by downstream users of GPS clock ticks.
Trollpost is troll.
--
BMO
Re: (Score:2)
NTP can be run securely, with decent keys.
But if someone is injecting packets into the network there are more obvious targets, like printing bogus medication instructions out or bringing machines down, maybe?
Rgds
Damon
Re: (Score:2)
My post is too long at 55 characters? Is /. using Twitter technology? If 80 column cards were good enough in 1965,. they are good enough now (Lawn:Off)