Dicom File Format Basics
vladsiv.com
vladsiv.com
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.
Thankfully nowadays there are lots of local-only web DICOM viewers, based on Cornerstone or other JS libraries...
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.
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.
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.
That said, I was in IT before I got my MD.
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.
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).
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.
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.
https://www.orthanc-server.com/static.php?page=stone-web-vie...
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.
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.
As an added bonus, you can run it as a portable app.
Dicom Compliance is a well paying job.
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.
Source: I wrote the DICOM viewer & anonymizer for Radiopaedia (okay, most of the heavy lifting is done by cornerstone.js).
Agree! Also some applications have "special" features that rely on data stored in private tags which, of course, you don't have any idea how to use.
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).
How to render an MPR image (an arbitrary slice of 3D data volume) from scratch starting from the bare DICOM files.
https://www.nema.org/directory/nema-councils/imaging-and-com...
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.
Is this as cursed as it sounds?
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.
To me, specifically streaming and caching strategies to move the load of (often hopelessly legacy) hospital infrastructure are an interesting challenge.
Between HL7 and vendors doing custom things with HL7 and DICOM, IT support in healthcare is always going to be desperately needed.
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.
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!
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.
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.
Dcm4che is that, though perhaps there could be some debate as to whether it's decent. I don't know; I'm stuck using quite an old version.
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).
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.
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.
The explanation of TLV could be interesting also in itself.