DICOM file with CT and MR tags

Question

A DICOM file (an artificial axial slice) has been generated from both a CT and an MR images. Can the aggregated file contain both CT and MR DICOM tags? E.g. Echo Time (0x18, 0x81) and KVP (0x18,0x60)?

I cannot find any information whether one image modality module is exclusive of the other and want to find out if such an artificial image might run into troubles with other vendors' software. Any help would be greatly appreciated.

Answer 1

The attribute SOP Class UID (0008,0016) determines which "type of object" you have and by this, the so-called Information Object Definition (IOD). The IOD tells you, which attributes are mandatory and which are allowed (and implicitly: which are not allowed) for the type of object.

So, merging attributes about the acquisition processes from two different IODs is not a good idea. What is going to fail widely is the annotation of these objects in a DICOM viewer. Most viewers have a SOP Class- or Modality- dependent configuration that defines how the images are annotated with DICOM header information. SOP Class UID and Modality have to provide exactly one value which cannot be entirely right in your case. So you have to decide whether another application treats the images as "CT only" or "MR only".

So, there is no way of merging IOD tables and still claiming DICOM conformance for the application that generates images of this type.

A lot of systems I know just treat the DICOM header as a "stream of attributes" not looking at correctness and consistency. As long as your pixel data and ordering information (Patient name, ID, ... , Study Instance UID, Series Instance UID) is properly encoded, it might happen that you will not run into severes issues.

However, I would never advise anyone to implement such thing. It is just a question of time when someone will validate your objects against the DICOM standard, find out that they are blatantly wrong and blaming no one else than you for that.

Answer 2

As explained by other, you are required to follow the DICOM standard. Basically you need to implement what is defined in the related IOD of your SOP Class instance.

Again as explained by other you are allowed to use a so-called 'Standard Extended SOP Class'. But be sure to read the definition for such class:

• 7.3 Rules Governing Types of SOP Classes

Quoting the paragraph:

Standard Extended SOP Classes shall:

1. be a proper super set of one Standard SOP Class;
2. not change the semantics of any Standard Attribute of that Standard SOP Class;
3. not contain any Private Type 1, 1C, 2, or 2C Attributes, nor add additional Standard Type 1, 1C, 2 or 2C Attributes;
4. not change any Standard Type 3 Attributes to Type 1, 1C, 2, or 2C;
5. use the same UID as the Standard SOP Class on which it is based.

So in summary no, you certainly cannot create an MR instance with a left over kVp (0018,0060) attribute, it cannot possibly mean anything for a MR modality in which case you are changing the semantics of a public attribute.