Hacker News Reader

Comment by brnt | Hacker News Reader

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!).

Dicom Compliance is a well paying job.

View on HN

> 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 practice, the files can be viewed just fine in any standard-compliant viewer without any awareness of custom tags.

Source: I wrote the DICOM viewer & anonymizer for Radiopaedia (okay, most of the heavy lifting is done by cornerstone.js).

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.

> Some manufacturers will use a private tag to hold the same information that's meant to be in a standard tag...

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.

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

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.

I have some DICOM experience. How does one go about getting these compliance jobs?

I would also like to know :D

Manufacturers of devices and associated software (eg treatment planning systems) tend to have somebody like that. Not sure you actually want to though.

I had a good snicker at the "Basics" in the title for exactly this reason!

Reply on news.ycombinator.com