3 ms·

I'm shocked and also confused in reading this. Why? Because the standards are there! The ACR/NEMA standard dates back to 1985(!) and is nowadays known as DICO

by vog 11y ago

I'm shocked and also confused in reading this. Why? Because the standards are there! The ACR/NEMA standard dates back to 1985(!) and is nowadays known as DICOM. Here in Germany/Europe, the medical imaging systems as well as the archive systems (PACS) are designed to follow that standard. DICOM covers everything, from the exact flavour of lossless(!) image compression, to the metadata structure which covers fiels more than you ever need to describe the patient, up to the archiving of data. There are even Free Software / Open Source clients which do a great job in visualizing those datasets (OsiriX is a well known example). I thought that this is an international standard. How can any hospital afford to buy crap medical devices that don't care about such an important 30-year old standard? Did I get something wrong about DICOM?

CaptSpify 11y ago
Having worked with medical software, especially dicom: Where's the incentive? I absolutely agree it's ridiculous when they don't follow the standard, but the appeal of vendor lock-in is just too much. I don't know how to change that, unfortunately. The data flows down (Disclaimer: I am not an xray/mri/hospital tech in any way, and might be wrong): IME, there's not much "importing" of patient data into the medical devices, so there's no reason for vendors to play along. The data flows from the machine, to the dr/patient/whoever, so the vendor has the ability to dump it out in any format they want.
acveilleux 11y ago
Until the early 2000s, DICOM was often an expensive option. Especially in "single vendor" shops where all hardware was from $VENDOR. BTW, the euro player were also fond of this. Even with DICOM, not all encodings (either low-level, like value representations, or high-level like transfer syntaxes and image compression algorithms) are supported by all viewers/PACS. Finally, every system assign patients their own local ID and does their own local numbering/coding for precedure IDs and so on. This adds delays and work when loading foreign images into a PACS. I won't get into the bugs. I work in the field and I've seen some low-level DICOM handling functions riddled with quirks, exceptions and work-arounds for buggy imaging machines. With all that, we still see images that are utterly broken and only openable in the original system. When doing the transfer over a network, it's often possible to negotiate down to explicit VR and Big-Endian uncompressed images which is required to be implemented and gets workable (if large, 500+MB for CT) images. With a CD/DVD, you're at the mercy of whatever syntax the creating device felt like using. If you include PET and similar, then you also need proprietary PET/CT or PET/MR fusion software to actually make use of the images.

by vog 11y ago

CaptSpify 11y ago

Having worked with medical software, especially dicom: Where's the incentive? I absolutely agree it's ridiculous when they don't follow the standard, but the appeal of vendor lock-in is just too much. I don't know how to change that, unfortunately. The data flows down (Disclaimer: I am not an xray/mri/hospital tech in any way, and might be wrong): IME, there's not much "importing" of patient data into the medical devices, so there's no reason for vendors to play along. The data flows from the machine, to the dr/patient/whoever, so the vendor has the ability to dump it out in any format they want.

acveilleux 11y ago

Until the early 2000s, DICOM was often an expensive option. Especially in "single vendor" shops where all hardware was from $VENDOR. BTW, the euro player were also fond of this. Even with DICOM, not all encodings (either low-level, like value representations, or high-level like transfer syntaxes and image compression algorithms) are supported by all viewers/PACS. Finally, every system assign patients their own local ID and does their own local numbering/coding for precedure IDs and so on. This adds delays and work when loading foreign images into a PACS. I won't get into the bugs. I work in the field and I've seen some low-level DICOM handling functions riddled with quirks, exceptions and work-arounds for buggy imaging machines. With all that, we still see images that are utterly broken and only openable in the original system. When doing the transfer over a network, it's often possible to negotiate down to explicit VR and Big-Endian uncompressed images which is required to be implemented and gets workable (if large, 500+MB for CT) images. With a CD/DVD, you're at the mercy of whatever syntax the creating device felt like using. If you include PET and similar, then you also need proprietary PET/CT or PET/MR fusion software to actually make use of the images.