8 ms·

Why Does the DICOM Standard Exist?

87 points by jdgiese 6y ago

megiddo 6y ago
DICOM exists for two reasons: One - As an industry, healthcare tends to employee and retain the bottom quintile of software talent. It's like the "bell curve" of development. For every unicorn out there hiring the best of the best, there's yet another healthcare IT firm making sure the other side of the curve has good insurance, neckties, a 9-5 and a $39,000/year salary. Two - Because the healthcare industry never met a technical challenge it couldn't solve poorly and support in perpetuity through federal regulations. DICOM is dumb. This is a commercial piece to push whatever the hell innolitics sells. Innolitics has a business model because federal bureaucracies guarantee it. Whatever.
- Damorian 6y ago
  If any of this were true you'd have tech giants, with their armies of "top" developers and massive legal teams disrupting the status quo but instead they announce a foray into healthcare, with much fanfare, only to scrap the project or have it fade into obscurity a few years later. Turns out healthcare is hard, both the practice itself and the industrial/government bureaucracy. Probably why the better EHR shops pay just as well as top tech companies.
  - megiddo 6y ago
    Oh, man. Who lied to you about healthcare compensation? Just go check glassdoor. Major IT companies bail on healthcare because margins suck and it's enormously regulated. I give you, for instance, DICOM, Hl7, Meaningful Use, Infobutton, or any of the other half-useless dead-letter, best of the 80s-era mainframe technologies that are required to meet healthcare regulatory burden. The best thing that's come out lately if FHIR, which is 9 years old and still doesn't qualify an EHR for meaningful use. Instead, it's all pipe-delimited TCP/MLLP and WTF.
    - Damorian 6y ago
      I work in health IT and I've turned down offers from two big-n companies because they couldn't match my current compensation. I'm sure there's some no-name health system in the middle of nowhere paying $40k/year for dev work the same I'm sure there's some android fart app paying some developer peanuts as well. Be fair and compare the exceptions to the exceptions.
  - wokkel 6y ago
    Having worked on a MVP for a healthcare company in Europe I can tell you that the users are not looking for better solutions. The doctors I worked with wanted a better pencil not some fancy solution. In our case it was improved traceability of medical implants and one doctor, when asked in private, told me that the current status quo suites them fine as it allows for more creative answers when the sh*t hits the fan. After that meeting I decided that the healthcare business was not the most healthy to work with.
    - Damorian 6y ago
      Agreed, but this is slowly changing. Of the doctors/nurses I've worked with (hundreds at this point), I'd say only half of them know how to type. The younger docs though, they can be real power users. Europe is notable in how low tech they can be, which is why they've been the biggest new market in recent years for a lot of health IT companies. The idea of a hospital system doing all of their charting on paper is unheard of in the US, but there's still plenty of places doing that in Europe.
      - dogma1138 6y ago
        Healthcare in Europe is weird you end up with a lot of parallel systems, all healthcare data in Europe have to be digitized and there is a standard for digital EU healthcare records including mandated interoperability between all providers in various member states. Even within the same healthcare system you can have drastic differences and a layer that sorts (or tries too) the entire mess out.
- deleted 6y ago
  [deleted]
- yshrestha 6y ago
  Co-founder of Innolitics chiming in here While this is undoubtedly one take on the subject, allow me to give you another perspective: One of my friends had an MRI taken for suspected nasopharyngeal cancer. The physician that read the scan did not find cancer. Thankfully, his ENT physician did not believe the diagnosis and took another look at his MRI, which happened to be in DICOM format. He was able to load the images on a DICOM compliant image viewer and saw the tumor right away. My friend underwent surgery and was confirmed to have cancer by microscopy. I think DICOM saved his life. It allowed his ENT physician to take another look, which would have probably been significantly harder with a proprietary file format. Yujan Shrestha, MD
ZeroCool2u 6y ago
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.
chkaloon 6y ago
Seeing those diagrams brought back swarms of memories from 20+ years ago working on UML diagrams on HL7 committees. Ewww.
afwaller 6y ago
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 6y ago
  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 6y ago
    Nice work! It is the primary DICOM resource for me and my team. Good to see that it's being actively maintained!
    - jdgiese 6y ago
      @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
achillean 6y ago
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 6y ago
  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 6y ago
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.
yread 6y ago
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.
- BubRoss 6y ago
  What do you mean by OS libraries here? Open source? Have you profiled the library to see where it is slow?
- jdgiese 6y ago
  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
dt3ft 6y ago
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.
tialaramex 6y ago
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.
eska 6y ago
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 6y ago
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.
1cvmask 6y ago
I worked on DICOM images sent to Blackberry apps in 2006 or so. It was a pain then. Assume not much has changed.
- tecleandor 6y ago
  DICOM hasn't changed a lot, but thankfully there are lots of tools available now, and vendors have stopped using proprietary formats.
rasengan0 6y ago
I'll just leave this right here: https://www.ihe.net/ https://www.ihe.net/
Areading314 6y ago
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-Medicine-DICOM/dp/3642108490 https://www.amazon.com/Digital-Imaging-Communications-Medici..., which believe it or not is a very entertaining read on the subject.

87 points by jdgiese 6y ago

DICOM exists for two reasons: One - As an industry, healthcare tends to employee and retain the bottom quintile of software talent. It's like the "bell curve" of development. For every unicorn out there hiring the best of the best, there's yet another healthcare IT firm making sure the other side of the curve has good insurance, neckties, a 9-5 and a $39,000/year salary. Two - Because the healthcare industry never met a technical challenge it couldn't solve poorly and support in perpetuity through federal regulations. DICOM is dumb. This is a commercial piece to push whatever the hell innolitics sells. Innolitics has a business model because federal bureaucracies guarantee it. Whatever.

Damorian 6y ago
If any of this were true you'd have tech giants, with their armies of "top" developers and massive legal teams disrupting the status quo but instead they announce a foray into healthcare, with much fanfare, only to scrap the project or have it fade into obscurity a few years later. Turns out healthcare is hard, both the practice itself and the industrial/government bureaucracy. Probably why the better EHR shops pay just as well as top tech companies.
- megiddo 6y ago
  Oh, man. Who lied to you about healthcare compensation? Just go check glassdoor. Major IT companies bail on healthcare because margins suck and it's enormously regulated. I give you, for instance, DICOM, Hl7, Meaningful Use, Infobutton, or any of the other half-useless dead-letter, best of the 80s-era mainframe technologies that are required to meet healthcare regulatory burden. The best thing that's come out lately if FHIR, which is 9 years old and still doesn't qualify an EHR for meaningful use. Instead, it's all pipe-delimited TCP/MLLP and WTF.
  - Damorian 6y ago
    I work in health IT and I've turned down offers from two big-n companies because they couldn't match my current compensation. I'm sure there's some no-name health system in the middle of nowhere paying $40k/year for dev work the same I'm sure there's some android fart app paying some developer peanuts as well. Be fair and compare the exceptions to the exceptions.
- wokkel 6y ago
  Having worked on a MVP for a healthcare company in Europe I can tell you that the users are not looking for better solutions. The doctors I worked with wanted a better pencil not some fancy solution. In our case it was improved traceability of medical implants and one doctor, when asked in private, told me that the current status quo suites them fine as it allows for more creative answers when the sh*t hits the fan. After that meeting I decided that the healthcare business was not the most healthy to work with.
  - Damorian 6y ago
    Agreed, but this is slowly changing. Of the doctors/nurses I've worked with (hundreds at this point), I'd say only half of them know how to type. The younger docs though, they can be real power users. Europe is notable in how low tech they can be, which is why they've been the biggest new market in recent years for a lot of health IT companies. The idea of a hospital system doing all of their charting on paper is unheard of in the US, but there's still plenty of places doing that in Europe.
    - dogma1138 6y ago
      Healthcare in Europe is weird you end up with a lot of parallel systems, all healthcare data in Europe have to be digitized and there is a standard for digital EU healthcare records including mandated interoperability between all providers in various member states. Even within the same healthcare system you can have drastic differences and a layer that sorts (or tries too) the entire mess out.
deleted 6y ago
[deleted]
yshrestha 6y ago
Co-founder of Innolitics chiming in here While this is undoubtedly one take on the subject, allow me to give you another perspective: One of my friends had an MRI taken for suspected nasopharyngeal cancer. The physician that read the scan did not find cancer. Thankfully, his ENT physician did not believe the diagnosis and took another look at his MRI, which happened to be in DICOM format. He was able to load the images on a DICOM compliant image viewer and saw the tumor right away. My friend underwent surgery and was confirmed to have cancer by microscopy. I think DICOM saved his life. It allowed his ENT physician to take another look, which would have probably been significantly harder with a proprietary file format. Yujan Shrestha, MD

ZeroCool2u 6y ago

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.

chkaloon 6y ago

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

afwaller 6y ago

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 6y ago
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 6y ago
  Nice work! It is the primary DICOM resource for me and my team. Good to see that it's being actively maintained!
  - jdgiese 6y ago
    @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

achillean 6y ago

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 6y ago
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 6y ago

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.

yread 6y ago

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.

BubRoss 6y ago
What do you mean by OS libraries here? Open source? Have you profiled the library to see where it is slow?
jdgiese 6y ago
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

dt3ft 6y ago

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.

tialaramex 6y ago

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.

eska 6y ago

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 6y ago

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.

1cvmask 6y ago

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

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

rasengan0 6y ago

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

Areading314 6y ago

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