Why Does the DICOM Standard Exist? (opens in new tab)

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.

Be glad for DICOM. In digital pathology we don't even have that. Every manufacturer has their own format. We don't even have proper OS libraries, there is a LGPL library that hasn't been updated for 2 years and GPL one that's up to date but slow as molasses.

EDIT: yes, I meant OpenSlide and BioFormats. BioFormats is in unoptimized Java. Oh yeah, and DICOM for pathology exists and some software tools use it exclusively but none of the manufacturers do. As the only standard some organization press for standardizing on it - forcing all vendors to provide convertors. But those are often slow, buggy and produce huge files.

FWIW, Innolitics has a better data dictionary (information object definitions) for DICOM than the official standards website. https://dicom.innolitics.com/ciods

DICOM has its issues, but it’s much better than HL7.

Reminder to not put these things on the Internet (~2,600 results):

https://beta.shodan.io/search?query=dicom+server+response

We're continuing to see hospitals and other healthcare-related organizations expose services that fall through the cracks due to the relative obscurity of these types of protocols in IT.

I worked on DICOM images sent to Blackberry apps in 2006 or so. It was a pain then. Assume not much has changed.

It's like TIFF, or like USB Storage.

Sometimes when it doesn't really matter what is chosen, one powerful entity can just pick and it doesn't matter. Even if maybe option B is very slightly better, clarity that we're all doing A is arguably better than some do A and some B and all suffer.

Unicode / ISO 10646-1 is an example like that. Some people don't like Han Unification, some people think UTF-16 reserved codepoints is an abomination, but mostly everybody is happy to live in a world where Unicode and ISO-10646 are effectively the same thing seen from different angles, not competing standards (Yes that could have happened)

Other times though there is no single entity powerful enough and willing to insist on one way forward, and no natural agreement on whether to do A or B. Instead parties that want to do A, and parties that want to do B just agree either is fine. The result is "standards" like USB Storage, TIFF or DICOM that leave far too much as unresolved choices.

Example: Some scanner manufacturers agreeing TIFF had designed scanners that start from the top-left of the eventual document, others started top-right or even bottom-right. If TIFF said "Images are top-to-bottom" the bottom-right scanners become expensive because they need a huge RAM buffer. Vice versa if TIFF says "Images are bottom-to-top". So... the actual TIFF standard says either can be true, you just flip a tag in the header to declare which way up the image is. Decoders have to carry all the burden of dealing with this, or be incompatible with some images to the confusion of users. ("Why is this picture upside down?")

These standards are marginally better than nobody agreeing anything, but only marginally. They're like that mediocre fusion restaurant you end up at when half the group wants Chinese and half wants Indian. Nobody likes this (hypothetical) fusion restaurant, so now nobody is happy, is that really better? I guess it's an improvement on spending the evening arguing pointlessly, because at least you can eat now.

I work with DICOM and HL7 and these things bring me to daydream about becoming a farmer and never looking back... Public healthcare IT is not where you want to be.

I think some of the frustration towards DICOM is misattributed. Yes, there are many instances of the standard being implemented poorly, and yes it is not always the most convenient having to index into your metadata using hex digits. But at least there IS a well documented, universally adopted standard that captures the most important information relevant to medical images right there next to the pixels. If this weren't the case, I think it would be much harder to have reliable interoperability between the highly complex + diverse types of systems that need to talk to each other in order to conduct an imaging workflow. There is a reason it exists and is so widely adopted -- and if you dig in to the details, a lot of thought has been put into its design. I highly recommend the book https://www.amazon.com/Digital-Imaging-Communications-Medici..., which believe it or not is a very entertaining read on the subject.

As standards come DICOM is actually pretty good. Sure, manufacturers will do their damnest to mess it up but interop tends to be surprisingly good because - just like with HTML - people tend to write for the lowest common denominator on reception. A typical PACS system will talk to a large number of machines all producing different output for different specialists to look at.

I've looked at about 10 companies using DICOM over the last couple of years and interop was typically the least of their worries. Think about the level of complexity here: anything from single frame BW at high res (say an X-ray) to time series of volumetric scans (for instance CAT).

The smarter companies will use one of the better FOSS libraries to implement the standard, the not-so-smart ones will try to roll their own, burn a ton of resources and will end up playing catch-up.

Seeing those diagrams brought back swarms of memories from 20+ years ago working on UML diagrams on HL7 committees. Ewww.

I used to work with DICOM about 7 years ago. It was a complete shitshow. Most of the important data was in "private fields". Imagine all websites using CSS, but they all use different vendor-specific attributes like "-moz-border-radius: 5". Might as well use a proprietary format at that point.

In the pre-DICOM days, I made money by making video capture cards. Back then, the only standard to get images from CT and MRI machines was the composite video on the 75 ohm coax going to the operator's console screen. Laser cameras (medical image film printers) worked the same way.

Actually that's not entirely true: there was also a 3M / Kodak defacto standard using a parallel RS-485 bus.

I'll just leave this right here: https://www.ihe.net/