
Why Does the DICOM Standard Exist? - jdgiese
https://innolitics.com/articles/dicom-i-facilitating-interoperability/
======
ZeroCool2u
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.

~~~
Damorian
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
Is that even legal?

~~~
tedivm
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
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.

------
yread
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.

~~~
jdgiese
I am curious what digital pathology libraries you are referring to (by any
chance, is one of them [https://www.openmicroscopy.org/bio-
formats/](https://www.openmicroscopy.org/bio-formats/) ?)

Also, I am sure you are aware the DICOM folks have been trying to get digital
pathology pulled into the standard. I am not sure how much success they have
had, but David Clunie (the current editor of the standard and a very friendly
and open-minded person) had a funny set of power point slides about this
topic. I recommend taking a look just for the humor:

[https://www.dclunie.com/papers/HIMA_2017_DICOMWSI_Clunie.pdf](https://www.dclunie.com/papers/HIMA_2017_DICOMWSI_Clunie.pdf)

------
tialaramex
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.

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

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

~~~
txrjk96
Hey, I'm actually one of the engineers at Innolitics working on improving the
DICOM Browser, and we just finished a relatively large update to it.

Thanks for linking the site! If you have any suggestions or encountered any
bugs on the site, please feel free to create an issue in the repo:
[https://github.com/innolitics/dicom-
standard/issues](https://github.com/innolitics/dicom-standard/issues)

~~~
korijn
Nice work! It is the primary DICOM resource for me and my team. Good to see
that it's being actively maintained!

~~~
jdgiese
@korijn I'm glad you find our DICOM Standard Browser to be useful!

You (and others reading this post) may be interested to know that the JSON
data the powers the browser is extracted using a set of open-sourced Python
scripts:

[https://github.com/innolitics/dicom-
standard](https://github.com/innolitics/dicom-standard)

------
dt3ft
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.

------
Areading314
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...](https://www.amazon.com/Digital-Imaging-
Communications-Medicine-DICOM/dp/3642108490), which believe it or not is a
very entertaining read on the subject.

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

[https://beta.shodan.io/search?query=dicom+server+response](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.

~~~
jacquesm
Hospitals tend to have piss-poor security. Their IT budget is usually low,
they have one or two sysadmins who are eternally busy fixing things that users
have messed up. Pentests are slowly becoming more accepted as a requirement,
mostly because the GDPR has come into effect. And those inevitably turn up
large lists of criticals.

Typically, gear is left with all the settings at 'default', things are opened
up to the net for temporary access which is then never removed again, it's
possible for the whole hospital to have only one LAN segment and so on.
Ransomware, directed attacks to gain admin privileges and substantial
violations of patient confidentiality have all been recorded with great
regularity.

I'm assuming that if I have to go into the hospital again for whatever reason
that that data will be on the street before I leave the building.

------
jacquesm
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.

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

------
eska
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.

------
jhallenworld
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.

------
rasengan0
I'll just leave this right here: [https://www.ihe.net/](https://www.ihe.net/)

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

~~~
tecleandor
DICOM hasn't changed a lot, but thankfully there are lots of tools available
now, and vendors have stopped using proprietary formats.

