My amazing experience with DICOM, an open standard with viewer software on SourceForge, is that I once took pictures in the format to a locally renowned neurologist.
She plugged my USB stick into her Windows XP workstation, ca. 2019, without the slightest hesitation, then proceeded to claim not to know what DICOM is, and to ask me why I didn't bring her either the proprietary viewer program, or JPEGs.
Had I brought the viewer, she would have probably launched the .exe with equally no hesitation.
At least in these parts of the woods, this once again confirmed to me that medicine and IT usually exist at opposite ends of a spectrum.
Until I took a senior developer role at a radiology practice I had no idea what DICOM was. The idea that a physician should know is kind of fanciful, isn't it? In 99.99% of cases, they load images by clicking a button that says "Display images" in a PACS, or RIS, or the images are loaded automatically by workflow. It's like expecting someone who has only ever viewed webpages, and never even viewed the source let alone made a webpage, to know the difference between JPEG, GIF, and PNG.
Physicians know that a DICOM file is what you get when you export from their viewer software. I asked a chiropractor for my x-rays and they just gave me a CD with two DICOM files on it. That chiropractor was an idiot, but at least they knew what a DICOM was.
IMHO, I don't think it's ever safe to assume that someone, even if they're in tech, would readily know what file format X is or have the right software for it. If in doubt, you should provide them the way to easily see whatever it is you want to show them, whether it's a x-ray or a hiking map or a giant party banner.
When I got my scans from the radiologist, they came on a CD-ROM (remember those?). I had to dig up my old disc drive from storage, then loaded the files onto my phone. At the orthopedist, I just showed it to them right on the phone with a Android DICOM viewer. I also brought the original CD, along with the same files plus 2-3 different viewers on my laptop, juuuuust in case. There's no way I was going to risk another clinic visit, at what, $300/visit?, just because they couldn't read the images. I'd do the same anytime I was visiting another professional. I don't assume to know their tech setup or level of file format expertise... that isn't what I'm paying them for, after all.
As an aside, in my brief investigation into DICOM (a format previously unknown to me before my injury), I discovered that it's actually a pretty complex format, with different viewers having pretty different UIs in terms of how they handle layers within a file (in both time and space), overlays and contrast adjustments (to emphasize/deemphasize certain artifacts, apparently), different collections and naming schemes for the same body parts, etc. Some of them were barely more usable than a JPEG viewer, while others could interpolate/extrapolate the data into a 3D point cloud and create rough anatomical models by combining collections of images from different angles. It's quite a complex system of raster imaging plus metadata, and no two viewers worked quite the same, even between the several free and/or open-source options. It reminds of the nonstandard mess that is file packaging for GIS (geographic information systems) -- a lot of power, but no simple system for organizing that power. In that sense DICOM is more like a database of radiological data that happens to be plottable in 2D (and sometimes 3D) space, rather than a simple image. If you export it to JPEG, you get a static output in time & space and lose a lot of the power of DICOM.
There are a loooooooot of ways to store imaging data out in the wild, and many different versions & viewers for each format... rather than looking down on someone for not keeping up with the tech stacks du jour, why not just help them get what they need to do their job more effectively? Especially when they're working to heal you.
There is also a problem that many DICOM viewers are outdated and abandoned, e.g. written in GTK+ 2.x which is not availabe on modern systems, and weren't updated for many years. Take, for example, AMIDE[1] - no changes in the development repository for 5 years already. Same story with many other projects.
This is like a restaurant that has a QR code on the table instead of a menu.
Yes, it's absolutely possible for someone to use the QR code to fetch the menu from a website using their phone. But unless you do it often, you just don't even know how to do it.
Doctors are insulated from DICOM the same way that most humans don't normally type "h t t p : / /" They just click on links and things show up for them.
My clinical work is in TB control and we read a lot of chest X-rays and CT scans. I'm very used to DICOM and I have my personal preferences for DICOM viewers, but outside of an actual radiology suite most docs will just use whatever viewer came on the disc, if there's one at all. And that's largely true for the ones I've worked with in this field, too.
Dicom files are usually in a structure that includes a viewer (there is a IHE profile which standardizes it). Barring radiologists physicians rarely know about file formats, and the portable media "just works" (mostly).
In my experience the specialists just offload this problem (and any other imaging tech problems) to their radiology provider, and while that might be a local phenomenon, I’d hazard a guess that it’s universal.
> Had I brought the viewer, she would have probably launched the .exe with equally no hesitation. At least in these parts of the woods, this once again confirmed to me that medicine and IT usually exist at opposite ends of a spectrum.
Well, on the other hand she'd be able to do what she needed without any other distractions - and in case you happened to break the machine, you'd be around to slap or pay up for the fixes :-P.
At the end of the day for most people computers are there to help their jobs.
> then proceeded to claim not to know what DICOM is
98% (made up number) a non-radiologist physician is going to bring up the image on whatever institutional lightweight PACS viewer is provided, and then occasionally in clinic on a disk that has some viewer provided. Not providing a viewer with a disc is kind of a dick move.
Most people using smartphones have no idea what HEIC or JPG really is, and why should they?
> this once again confirmed to me that medicine and IT usually exist at opposite ends of a spectrum.
Do you actually know how to read even a chest X-ray or an echocardiogram?
I never quite understood this tech fascination with pointing out/being surprised that specialized experts are not generally deeply familiar with IT. It has little to nothing to do with their everyday jobs.
I don't know of any doctors that would be surprised that an IT worker/engineer cannot properly read a neuro MRI or any other image for that matter. But people here are always surprised when most doctors don't have beyond a lay understanding of computers.
I do think the tech crowd tends to have a lot more hubris though. Amateur docs and lawyers seem not to be in short supply around here.
> that medicine and IT usually exist at opposite ends of a spectrum.
Working in Medicine you learn that specialists, and in particular renowned ones have their worlds optimized around having them do what they do best, and not wasting time not doing what they do best.
My father practice moved digital in the late nineties, they had a cd robot that would burn the dicom images together with a quite decent windows viewer from Siemens (actually it had nice contrast and zooming features) on the disk with autorun config (nobody cared at this time about security). The future was here...
Fun side aspect of the story is that they bought the wrong type of CD-Rs for the robot and I am still having empty CD-Rs from a batch of 500 or so I am using (once every other year).
Coincidentally, for me, I had an MRI yesterday and they always give me access to the DICOM files so it's interesting to know more about them. "Horos" is a really good viewer if you want something for managing and viewing entire sets of such images, especially as it can create 3D visualizations of all the 2D slices which results in fun/creepy pictures of my brain to show off.
On Windows I use RadiAnt. It's not free software, but it is extremely good and not terribly expensive. It will even load and display DICOM out of zip files which is a killer feature.
It used to be that everyone used eFilm Workstation for like legal consulting etc. But eFilm decided to end that (probably because they couldn't figure out how to get it to migrate to high DPI screens and it wasn't a priority).
RadiAnt switched their sales model in a way that's very convenient for law firms to pay consultants. They can basically buy however many months are needed for the consultant.
RadiAnt is OK - it's got a trial license model but when the license expires you can request an extension for free (big WinRAR energy). There's nothing as good as Horos that is similarly free and open source, sadly.
What you may prefer to do is use the excellent pydicom library for Python, which loads dicom files as numpy arrays, allowing you to convert to any other file format you fancy, whether that be image or video.
A complex/overkill but open source approach on Windows is to install Orthanc and use the new webassembly viewer. But it's not as fast/good as RadiAnt and it's certainly nothing next to OsiriX.
I would suggest ImageJ, which is a Java-based image processing program developed at the National Institutes of Health (NIH). It has a very low memory footprint, built-in support for most DICOM file formats, a ton of extensions, and (of course) cross-platform support.
As an added bonus, you can run it as a portable app.
I use Ginkgo CAD on linux. Unfortunately a lot of good free DICOM viewers have become abandonware in Linux and shareware on OSX. Don't know about Windows.
It's similar on Windows. Part of the problem is that access to DICOM images is a major barrier. OsiriX happened because OS X didn't have a viewer. The "eFilm Workstation" crowd moved to OsiriX. It's complex but eFilm used to be pretty good but they couldn't add features and fix bugs fast enough. And then they couldn't make high DPI work. In the mean time, OsiriX was very nice looking and adaptable for radiologists who like to tinker. Radiologists can be extremely picky and demanding about UI and efficiency and OsiriX served that well. Not to mention that OSX brought all the linux research packages. So, they all just bought Macs and left eFilm behind for OsiriX particularly after it obtained FDA/EC clearance.
OsiriX is a great and bad viewer that made life easier and cheaper for lots of radiologists and doctor (although not cheap enough for some countries)
The bad part: OsiriX was LGPL for a while, but they began to mix it with closed binaries. I reported some inconsistencies on the license in their mailing list, they moderated me, and some time later stopped publishing source. That's were Horos started growing.
I have always avoided OsiriX, but at my new job it's used a lot in the image processing lab (that I help support). I want to build/provide some simple QA utilities for the people who do use OsiriX, but I'm a physicist and I can't justify buying that MD license to tinker with and that damn timeout nag bullshit is not something I will waste my time on. I can't even tell how compatible Horos is with OsiriX or if it's maintained anymore. If I knew that plugins developed for Horos would work on OsiriX I might consider that "ecosystem" but as is it's not worth the effort to me. I barely tolerate OS X.
Ginkgo CADx was a project by a Spanish company giving services to public and private health services, but they dissolved some years ago, and seems like nobody took the maintenance.
Oh, nice! Somehow I had missed this one and was wondering why nobody had created a cross-platform python viewer that's simpler than slicer. I'll check it out!
Every CDROM I've received after an MRI comes with a windows viewer on it. IN 2010 it was E Film Light, then DCSView, then DrayViewer, and today it is Radiant.
The problem with extensibility is that everyone does! Manufacturers will dump in all sorts of tags, and check for them, when you read in, but the won't tell you what they are and how you might calculate their supersecret checksums (for safety!).
> Manufacturers will dump in all sorts of tags, and check for them, when you read in, but the won't tell you what they are
True. As far as I know it could be also used for a vendor lock-in. If you export DICOM files from X, you have to use software Y. Since they are dumping all sorts of private tags which you don't know anything about.
In many cases it's because the standards don't (yet) support storing important information or weren't performant. For example, in DTI imaging recording of the diffusion vectors was not something that DICOM supported until DTI use became more widespread clinically. In other cases it was network performance hacks. Another example with DTI is that initially DICOM for MRI only supported 2D images. Which for DTI is a problem because you easily end up with thousands of images and transferring them as individual 2D with all the network handshaking and storage confirmations is slow as molasses and grinds on PACS that aren't setup for this. Some vendors "solved" this by creating large 2D images of 3D images by laying out multiple 2D slices in a mosaic. Because the 3D volume became one 2D image, transfers were much faster and doesn't consume as many resources on PACS. Eventually the DICOM standard came up with an even better solution, but it's only recently starting to roll out on the scanners and the old ways still persist.
For certain definitions of "just fine". Some manufacturers will use a private tag to hold the same information that's meant to be in a standard tag—and even sometimes put different values in the two, with the private tag being correct.
Viewer of what? Dicom can contain other things than just nD imagery.
Also, the difficulty in my experience is the getting data back in part; getting data out is usually a lot easier (you don't need to care about those tags).
Manufacturers of devices and associated software (eg treatment planning systems) tend to have somebody like that. Not sure you actually want to though.
For those who like to experiment a little, I can recommend firing up a jupyter notebook and explore the image data using pydicom and plotting it via matplotlib (or whatever plotting lib you fancy). For most CT and MRI data you will have a volume/voxels available and its pretty fun to slice'n dice your way through it by using list slices. Also all other data is available to inspect.
If you've gone through security at a U.S. airport, the scanners use DICOS format to save scans of your baggage. Someone correct me if I am wrong though - it's possible only a subset of these machines use DICOS, I am not 100% sure.
The file format is reasonably cursed (header fields to indicate endian-ness, multiple internal metadata tables, and it's a container format so you can encode the image data using any one of 6-8 codecs - or just include a link to the TCP stream).
I haven't used the network protocol, but having some way to only bring the required pixel data across the network is pretty important - uncompressed CT scans are often hundreds of megabytes and the standard was developed before ethernet was widespread.
It's fully binary and is document as a Lisp, as far as I remember. It's very nightmarish, but it's from the 80s, so it has its merits for staying for so long.
DICOM is a fun format to tinker with. The absolute basics of it are simple enough that I wrote a DICOM viewer in college for a class. All of the extensions mean you can get some really interesting data as well. The various number of attributes and unusual combinations make it a real pain if you're trying to implement it all from the ground up but I'd highly recommend anyone play with it.
Very interesting! I have been working with medical information standards for a while now. Recently, I took an interest in DICOM and ways to modernize it. For example by introducing streaming, caching, moving metadata to a FHIR ImagingStudy resource.
To me, specifically streaming and caching strategies to move the load of (often hopelessly legacy) hospital infrastructure are an interesting challenge.
The amount of redundant scientific/medical/industrial image file formats is amazing. Just off the top of my head there is DICOM, FITS, NIFTI, NRRD, plus TIFF.
They all have the basic property of having raster data of arbitrary channels/depth plus a whole bunch of metadata.
It feels like every new industry I work with I discover they have their own redundant image format.
I have a funny (or sad, really) DICOM story. I wrote my own DICOM parser in Rust, and I kept encountering a bug where the parsing would fail on a small subset of files in my database.
What you need to know is that DICOM tags have 16-bit group and element values that uniquely identify what the tag contains, and tags that begin with the group 0xfffe are very special, comprising a small set of field delimiters.
Well, the brilliant minds at Codonics decided to use the special group 0xfffe for their private, vendor-specific fields at the end of the file. When parsing a file those private fields would look like delimiters and ruin the logic.
So because of that one particular vendor, I have to check both the group and element of every special tag in every file I parse to make sure it isn't one of their special ones. Whereas, if they had followed the standard, I would only need to check the groups for the value 0xfffe. Thanks, guys!
Things are improving, but non-conformity to the DICOM spec by some vendors is quite common. I regularly encounter DICOM files that don't even have the 128byte preamble or 4byte `DICM` prefix.
The information in a DICOM file is a huge huge superset of the information you'd typically find in a PNG, because the amount of metadata you want to tie to a medical image is enormous (e.g. what day, what scanner, which scan, which part of which scan, which radiology tech, which doctor, which patient, with which contrast agent, in what orientation). Even if you did contrive a way to pack that metadata into a PNG file (which is possible), you'd still need a way to unambiguously interpret all that metadata, and know that everything else in the healthcare world is going to interpret it the same way. That's one of the things that the DICOM standard covers.
DICOM is a lot older than PNG, you can embed multiple images in a DICOM file using different formats - losless and lossy, formats like jpg, tiff and so on. It also includes a bunch of tags that describe the image, patient information, scanner it came from and so on.
It also goes well beyond just talking about the imagery itself or the metadata surrounding it, and the standard contains its own network protocol effectively for transmitting data between PACS systems and other endpoints. (I recently worked in medical imaging for over 6 years and know DICOM fairly well, warts and all).
That said, there are absolutely better ways of handling almost any of the cases DICOM supports, the issue is that there is almost no standard that is fully backwards compatible which supports everything DICOM does, so we're sorta shackled to it for better or worse. Otherwise you have to deal with trying to explain to underfunded clinics (not the Mayo or Cleveland type) around the world why their expensive machine that they bought second or third hand is no longer acceptable.
Is there any need or demand for a decent Java language DICOM parsing library?
Mid-aughts, I wrote a DICOM image viewing applet. (Before tile-servers a la Google Maps, which would have been a better strategy.) My library could read DICOM filestores. But not do network interchange.
DICOM applet was intended to be part of our EMR web client, our frontend to showcase our portable electronic medical records backend stuff. At the time, it was an amazing demo, greatly helping our Sales team.
My code (IP) got lost, abandoned. (Acquisition, abandonment, high mgmt turnover, etc. Typical M&A story.) So sad. Anyone who'd know or remember what my code did is long gone.
--
Ditto my HL7 2.x and 3.x libraries, FWIW. I wrote my stuff in response to the available tools at the time. SeeBeyond ICAN/JCAPS, Mirth, BizTalk, a bunch of others I now forget. Turrible. I'm out of the field, so I imagine the world's moved on. FHIR and whatnot.
We lived predominantly in the .NET world and leveraged Fellow Oak Dicom pretty heavily, but when I did have to use anything in Java-land we pretty much always leveraged dcm4che, as it did what we needed and we didn't need to monkey with it much. Ultimately given my ignorance of that ecosystem I'd be hard pressed to advise about the need or demand in Java one way or the other unfortunately. Sorry about that!
You made me shudder by mentioning BizTalk just now, though. I had long since shut that way in the corners of my mind.
Ya, with all the ETL work I've done, I've been cured of any interest in visual programming, "no-code", and the latest iteration of CASE tools in general.
Aside from all the BizTalk specific heartache...
With patch-cord programming, you always have to drop down to actual code for that last 5% of work, the fit & finish. Then you're fighting the framework (tool).
Better to have an API that's easy and bulletproof. My solution for HL7 "interface" implementations was to ingest the specifications (authored by our customer facing business analysts) and output Java source code. Then use any IDE (tool stack) to proceed as normal for that last 5%.
We'd onboard new teammates (to do "HL7 interfaces"), most who had never seen Java before, in about 2 weeks. At the time, the assumption was onboarding to ICAN (or equiv) would take about 3 months. (Yikes.)
I was always interested in playing with C# and LINQ for our work. But none those sales leads panned out.
PNG coupled with a JSON can do almost anything that DICOM can do. DICOM can also do video and is starting to dabble in waveform data, but MP4 and SVG exist.
DICOM is a standard for medical imaging, and the patient data related to it, supported by every medical imaging device manufacturer.
JSON is a data format, it isn't in itself a standard for any content in particular, particularly medical imaging content. Think schema, not encoding (and in fact there is a JSON encoding for DICOM).
Yup, the way you interpret the JSON or DICOM matters.
In DICOM, the interpretation of the data is coupled with a specific file format, when it doesn't need to be.
We want window leveling to work the same way across the board, but whether you transmit the width, center, and algorithm (linear, sigmoid, etc.) in a DCM file or in JSON or in carrier pigeon doesn't particularly matter so long as the receiver can interpret it.
Would it be better if all modality manufacturers started sending JSON? Probably not, however manufacturers produce non-compliant DICOM ALL THE TIME so there's still an issue there with complexity and lack of strong testing tools for the standard.
*supported by every medical imaging device manufacturer going back something like 3+ decades.
This is much less of a problem of shiny-object-syndrome not providing a "better" way of solving the problem(s) and much more one of market inertia, IMO. Many people overlook this.
Especially considering that medical information can often need review decades later. Can't just support the new stuff, you need to support the priors that were rendered in the pre-2000s as well.
DICOM supports MP4 (and HVEC/H.265, various flavors of JPG, and various other encoders, etc). I don't think PNG is supported, though and I'm not entire certain why but possibly it's a licensing issue. DICOM objects are basically just generic containers.
There’s probably multiple reasons why DICOM does not support PNG. Most compression formats in DICOM are those published as official standards in the JPEG family from ISO.
The original JPEG from ‘92 already included a Lossless mode which supports 16/12/8 bit color and monochrome and is very fast to encode and decode. All of those were important features.
Adding PNG later would not benefit anyone: it can not handle all of these usecases, it is usually slower and it came later.
She plugged my USB stick into her Windows XP workstation, ca. 2019, without the slightest hesitation, then proceeded to claim not to know what DICOM is, and to ask me why I didn't bring her either the proprietary viewer program, or JPEGs.
Had I brought the viewer, she would have probably launched the .exe with equally no hesitation.
At least in these parts of the woods, this once again confirmed to me that medicine and IT usually exist at opposite ends of a spectrum.