9 ms·

Having personally worked with the DICOM standard, I'll say it's not the worst, but definitely not the best spec to work with. The main issue I've found is the

Having personally worked with the DICOM standard, I'll say it's not the worst, but definitely not the best spec to work with. The main issue I've found is the manufacturer's implementation. They range from okay to barely meeting the minimum standards. One thing that always annoyed me was the time stamps. They're mandated by the standard, so there's always a timestamp, but it's often useless. For example, it seems some scanners don't get their time set, over the network or otherwise, _ever_, so you might have a bunch of scans performed a few years ago on scanner A with an accurate timestamp of say 2017, but in a new scan from last week that was taken by scanner B, which hasn't had its clock configured properly, it reports a date closer to the start of the unix epoch rather than 2020. Of course some of this is out of the manufacturers control, but temporal data is critical to analyzing changes to patient over time. I think this is one area where the DICOM standard couldn't be a bit more strict with a lot of positive impact.

booi 6y ago
This is one of those times I feel like the cell networks (or other network) should broadcast an accurate time without the need for an account/SIM and a cheap chip to receive it. I would say there's a lot of medical facilities that don't want to connect their equipment to the internet for time information and for good reason.
- rlpb 6y ago
  This already exists: https://en.wikipedia.org/wiki/Time_signal#Radio_time_sources https://en.wikipedia.org/wiki/Time_signal#Radio_time_sources Edit: a page more specific to this use case is probably https://en.wikipedia.org/wiki/Radio_clock https://en.wikipedia.org/wiki/Radio_clock
- snthd 6y ago
  It's called GPS :-) You can use a GPS as a time source for an NTP server (on your airwalled network).
  - rlpb 6y ago
    Unfortunately the GPS signal is generally too weak to be used indoors - especially in a larger building like a hospital.
    - stragies 6y ago
      Do you need to be more than 1km underground, or away from outside walls? Just put the GPS-receiver on the far end of an RS485 serial connection. First google hit: https://www.worldtimesolutions.com/products/gps_rs485_time_source.html https://www.worldtimesolutions.com/products/gps_rs485_time_s...
      - duskwuff 6y ago
        That'd depend on the hospital building out an RS485 infrastructure to support the device, though, which is a nontrivial ask. Piggybacking off of a cell network is honestly probably the right solution. It doesn't have quite as high resolution as GPS, but that's hardly necessary for the sort of timestamps we're discussing -- even a resolution of a minute or two would be a huge improvement on "hope the tech who installed the equipment set the time correctly".
      - rlpb 6y ago
        Remember that anything that is harder than setting the date and time is unlikely to be done in practice, since we're looking for something easier than that. Routing cabling out of a room seems unlikely.
    - walshemj 6y ago
      You put your ntp stratum one where it can receive the signal
- m-p-3 6y ago
  Why not simply rely on GPS time? Seems like a stable and universal time source that could be used anywhere.
Damorian 6y ago
This is why I hate DICOM. DICOM itself is fine, it's just that every device manufacturer mucks it up. I remember once working with a device that claimed to meet a certain supplement. Got some sample data from a real world device, implemented the standard in our system, and started playing with it, but every image I got back was just a garbled mess. After tons of attempts, I eventually got in contact with a developer at the manufacturer who told me they encrypt the image data so that it can only be used by their supporting software...
- BubRoss 6y ago
  Is that even legal?
  - Damorian 6y ago
    I suppose it could be false advertising to say you support a standard but only in a way that's meaningful to your software? As a 3rd party developer, it's hard to demand another company build something into their API, based on standards or otherwise. The best you can do is throw around your market share and lean on your mutual unhappy customers to make it happen.
  - tedivm 6y ago
    I don't think it is, at least in the US. What most people forget about HIPAA is that the P stands for "Portability". The entire point behind it was that someone should be able to take their records from one hospital, doctor's office, or imaging clinic and then bring it to another one without having to go through another scan. DICOM was the industry's response to those portability requirements that our government put into place.
    - mattkrause 6y ago
      Are you sure about that timeline? DICOM 3 (which was the first version using the DICOM name) dates back to 1993. HIPAA was signed in 1996. I thought the “portability” part was meant to cover changes in jobs and life circumstances.
- 6y ago
stinos 6y ago
One thing that always annoyed me was the time stamps So much this. Now your example can still be countered somewhat by taking notes and writing down which scan was taken when. This is usually common practice in research. But it can get worse when trying to integrate integrating MRI scanner software with external systems which do get a correct timestamp (or at least, different one) and which are used for research experiments like presenting stimuli and recording behaviour all together with getting MRI data. Scanner software usually doesn't provide any means of starting it except for clicking in the UI so that means the people doing such experiment have to start 2 or more pieces of software manually (and hope they don't forget one). Now if one session lasts 10 minutes and it's not uncommon to do test sessions (with no scan) or test scans (with no corresponding experiment) or make a mistake (start scan with wrong parameters, abort, start again) and a complete test takes a couple of hours, imagine the fun of linking all of that session data together correctly based on just timestamps. I don't even know how much time has been lost or many mistakes were made (and possibly published) because of that. But it won't be 0, it's just too easy to mess up. Of course some of this is out of the manufacturers contro Only partly. Some of these systems are always connected to the internet anway so then at least try to make sure NTP works.
- PascLeRasc 6y ago
  Do you know what software is usually used to get fMRI timestamps? My last position was in an fMRI lab, and we had this in-house piece of Windows 98 software that did real-time recording down to <10ms, but it was a huge codebase to maintain and pretty much impossible for me to migrate it to Windows 10. The output file was pretty hard to decode too. I've always wondered what else is out there.
  - stinos 6y ago
    Not 100% sure what you mean with 'fMRI timestamps' but since you say 'recording' I assume it's the TTL/optical trigger produced at the start of each volume? And since you mention windows 98 and < 10mSec the in-house software is maybe using the parallal port? From former experience with such software: that's usually a mess, especially on later versions of Windows where direct access to such port was being ruled out. Anyway the principle is you use an A/D converter to digitize the signal then save it (either the complete signal or just timestamps of rising edge, the latter can also be done directly on some A/D cards). In the system I'm currently working on I'm using National Instruments PCI-X cards their C SDK to get the data but that's just because I need I/O channels for other things as well and because it has to include online processing of data. Otherwise you could just save the data at a nice and slow rate using Labview or Matlab or ... (pretty sure there are open source solutions as well). And there are many alternatives to National instruments as well of course. All woth resolution down to a couple of nanoseconds if needed. But note that it's still not trivial to get an accurate 'time of day' timestamp from it (should that be needed): at the recording site there's no way of knowing exactly when the data acquisition starts. And there can be clock drift.
brnt 6y ago
Dicom gets a lot of flak, but as you say, the thing that makes it bad is shitty implementations and shitty vendors. After a while, you realize there aren't any nonshitty vendors in the medical field. And then you count your blessings that at least dicom gives you the beginning of interop.
downerending 6y ago
Pretty much all of the medical instrument software I've ever seen is awful. I'd always imagined that that was because it was written by EEs. No less scary for that, though.
dmarchand90 6y ago
My software gig largely involved converting DICOM files into the format used by the company. I very very very much can relate with all this. Basically almost every client needed a custom script to correct the issues in their use of DICOM

booi 6y ago

This is one of those times I feel like the cell networks (or other network) should broadcast an accurate time without the need for an account/SIM and a cheap chip to receive it. I would say there's a lot of medical facilities that don't want to connect their equipment to the internet for time information and for good reason.

rlpb 6y ago
This already exists: https://en.wikipedia.org/wiki/Time_signal#Radio_time_sources https://en.wikipedia.org/wiki/Time_signal#Radio_time_sources Edit: a page more specific to this use case is probably https://en.wikipedia.org/wiki/Radio_clock https://en.wikipedia.org/wiki/Radio_clock
snthd 6y ago
It's called GPS :-) You can use a GPS as a time source for an NTP server (on your airwalled network).
- rlpb 6y ago
  Unfortunately the GPS signal is generally too weak to be used indoors - especially in a larger building like a hospital.
  - stragies 6y ago
    Do you need to be more than 1km underground, or away from outside walls? Just put the GPS-receiver on the far end of an RS485 serial connection. First google hit: https://www.worldtimesolutions.com/products/gps_rs485_time_source.html https://www.worldtimesolutions.com/products/gps_rs485_time_s...
    - duskwuff 6y ago
      That'd depend on the hospital building out an RS485 infrastructure to support the device, though, which is a nontrivial ask. Piggybacking off of a cell network is honestly probably the right solution. It doesn't have quite as high resolution as GPS, but that's hardly necessary for the sort of timestamps we're discussing -- even a resolution of a minute or two would be a huge improvement on "hope the tech who installed the equipment set the time correctly".
    - rlpb 6y ago
      Remember that anything that is harder than setting the date and time is unlikely to be done in practice, since we're looking for something easier than that. Routing cabling out of a room seems unlikely.
  - walshemj 6y ago
    You put your ntp stratum one where it can receive the signal
m-p-3 6y ago
Why not simply rely on GPS time? Seems like a stable and universal time source that could be used anywhere.

Damorian 6y ago

This is why I hate DICOM. DICOM itself is fine, it's just that every device manufacturer mucks it up. I remember once working with a device that claimed to meet a certain supplement. Got some sample data from a real world device, implemented the standard in our system, and started playing with it, but every image I got back was just a garbled mess. After tons of attempts, I eventually got in contact with a developer at the manufacturer who told me they encrypt the image data so that it can only be used by their supporting software...

BubRoss 6y ago
Is that even legal?
- Damorian 6y ago
  I suppose it could be false advertising to say you support a standard but only in a way that's meaningful to your software? As a 3rd party developer, it's hard to demand another company build something into their API, based on standards or otherwise. The best you can do is throw around your market share and lean on your mutual unhappy customers to make it happen.
- tedivm 6y ago
  I don't think it is, at least in the US. What most people forget about HIPAA is that the P stands for "Portability". The entire point behind it was that someone should be able to take their records from one hospital, doctor's office, or imaging clinic and then bring it to another one without having to go through another scan. DICOM was the industry's response to those portability requirements that our government put into place.
  - mattkrause 6y ago
    Are you sure about that timeline? DICOM 3 (which was the first version using the DICOM name) dates back to 1993. HIPAA was signed in 1996. I thought the “portability” part was meant to cover changes in jobs and life circumstances.
6y ago

stinos 6y ago

One thing that always annoyed me was the time stamps So much this. Now your example can still be countered somewhat by taking notes and writing down which scan was taken when. This is usually common practice in research. But it can get worse when trying to integrate integrating MRI scanner software with external systems which do get a correct timestamp (or at least, different one) and which are used for research experiments like presenting stimuli and recording behaviour all together with getting MRI data. Scanner software usually doesn't provide any means of starting it except for clicking in the UI so that means the people doing such experiment have to start 2 or more pieces of software manually (and hope they don't forget one). Now if one session lasts 10 minutes and it's not uncommon to do test sessions (with no scan) or test scans (with no corresponding experiment) or make a mistake (start scan with wrong parameters, abort, start again) and a complete test takes a couple of hours, imagine the fun of linking all of that session data together correctly based on just timestamps. I don't even know how much time has been lost or many mistakes were made (and possibly published) because of that. But it won't be 0, it's just too easy to mess up. Of course some of this is out of the manufacturers contro Only partly. Some of these systems are always connected to the internet anway so then at least try to make sure NTP works.

PascLeRasc 6y ago
Do you know what software is usually used to get fMRI timestamps? My last position was in an fMRI lab, and we had this in-house piece of Windows 98 software that did real-time recording down to <10ms, but it was a huge codebase to maintain and pretty much impossible for me to migrate it to Windows 10. The output file was pretty hard to decode too. I've always wondered what else is out there.
- stinos 6y ago
  Not 100% sure what you mean with 'fMRI timestamps' but since you say 'recording' I assume it's the TTL/optical trigger produced at the start of each volume? And since you mention windows 98 and < 10mSec the in-house software is maybe using the parallal port? From former experience with such software: that's usually a mess, especially on later versions of Windows where direct access to such port was being ruled out. Anyway the principle is you use an A/D converter to digitize the signal then save it (either the complete signal or just timestamps of rising edge, the latter can also be done directly on some A/D cards). In the system I'm currently working on I'm using National Instruments PCI-X cards their C SDK to get the data but that's just because I need I/O channels for other things as well and because it has to include online processing of data. Otherwise you could just save the data at a nice and slow rate using Labview or Matlab or ... (pretty sure there are open source solutions as well). And there are many alternatives to National instruments as well of course. All woth resolution down to a couple of nanoseconds if needed. But note that it's still not trivial to get an accurate 'time of day' timestamp from it (should that be needed): at the recording site there's no way of knowing exactly when the data acquisition starts. And there can be clock drift.

brnt 6y ago

Dicom gets a lot of flak, but as you say, the thing that makes it bad is shitty implementations and shitty vendors. After a while, you realize there aren't any nonshitty vendors in the medical field. And then you count your blessings that at least dicom gives you the beginning of interop.

downerending 6y ago

Pretty much all of the medical instrument software I've ever seen is awful. I'd always imagined that that was because it was written by EEs. No less scary for that, though.

dmarchand90 6y ago

My software gig largely involved converting DICOM files into the format used by the company. I very very very much can relate with all this. Basically almost every client needed a custom script to correct the issues in their use of DICOM