Which tags in two separate slice files from same DICOM series are required to be the same?

Question

I am having difficulties interpreting the DICOM specification. Specifically, if I have two DICOM files, each say a unique CT slice from a single CT series (same study). Both files will contain the Patient module, so in theory they could have different patient information. My understanding by the DICOM standard that would be wrong. But I am having difficulties figuring out from the standard, how to identify all tags between the two files that are required to match.

I am guessing the awnser is in A.1.2 IOD Entity-Relationship Model [http://dicom.nema.org/medical/dicom/current/output/chtml/part03/chapter_A.html#figure_A.1-1] But I fail to see how exactly that relates to the individual slice file content, which is described by A.3.3 CT Image IOD Module Table [http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.3.3.html]

Any insight much appreciated!

Answer 1

You could think about this from the perspective of an acquisition modality which supports modality worklist. The DICOM standard (Part 3) defines module tables for the IOD applicable to the type of data that the modality acquires, i.e. which attributes are mandatory and which are optional (let us abstract the Type 1 / 2 / 3 [C] details).

The modality acquires series of information. So it is in your hand to align all series level attributes, and that is what you should do even though it is not explicitly required.

Referring to the Study- and Patient level, there may be other modalities contributing to the same study's or patient's EHR. You cannot know which attributes these modalities fill with which values. So you cannot make sure that they are aligned. Each modality is required to fill in the mandatory attributes as required by the module table. Period.

Now modality worklist comes into place. A central scheduling system publishes patient and study information across different modalities. The patient level is a good example: All patient related attributes are Type 2 which means they must be present but they may be empty. However, Type 2 should be understood in such a way that it is required to have a value if the value is known to the creator of the object (see here). So when the modality has received patient level attributes through the worklist, it is obliged to include them in the header of acquired objects. By this, relevant attributes are aligned across different acquisition processes.

These conditions are weak. E.g. if a modality does not ask for patient's weight (study level attribute) in the modality worklist (which is allowed for the attribute is optional), it will not receive the correct attribute value. Another modality may support the attribute. The values in objects acquired by these modalities shall not be contradictory, that is, if it is not supported by modality worklist, it shall be omitted from the acquired images. With an empty Type 2 attribute meaning "value is unknown", a PACS system will not have to resolve any conflicts, i.e. it is safe to keep the first known value of each attribute to its database.