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.
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.
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.
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.
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.
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.
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).
Thankfully nowadays there are lots of local-only web DICOM viewers, based on Cornerstone or other JS libraries...
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.
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.
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).
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.
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).
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.
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!
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.
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.
The explanation of TLV could be interesting also in itself.
