What DICOM Metadata Guarantees About a Series, and What It Only Suggests

The DICOM standard defines an attribute’s type as a statement about obligation, not about correctness. A Type 1 attribute must be present and must have a value. Type 2 must be present but may be empty. Type 3 is optional and may be absent entirely.¹ Nothing in the standard obliges any of them to be accurate, and no part of the conformance mechanism checks whether the value describes what actually happened in the scanner.

This distinction is the root of most quantitative imaging data quality work, and it is routinely collapsed into “the header says so”.

The obligation tiers, and where the useful fields sit

The attributes that identify and position an image are mostly Type 1. Series Instance UID (0020,000E), Image Position (Patient) (0020,0032) and Image Orientation (Patient) (0020,0037) have to be there and have to be populated, because reconstruction into a volume is impossible without them. In practice they are reliable, and a series that violates them tends to fail loudly rather than quietly.

The attributes a quantitative pipeline actually reasons about are a different story. Many of the ones that matter most are Type 3 in the modules where you would want them:

• Spacing Between Slices (0018,0088) is optional. Slice Thickness (0018,0050) describes the nominal slice, not the reconstruction interval, and the two differ whenever slices overlap. Deriving geometry from thickness when the acquisition overlapped produces a volume with the wrong z-extent.
• Magnetic Field Strength (0018,0087) is present far more often than it is correct, and it is stored as a decimal string. A 3 T system may report 3, 3.0 or 2.89 depending on vendor and software version, all of which are defensible and none of which compare equal as strings.
• Diffusion b-value was not given a standard attribute until (0018,9087) in the enhanced objects. Classic single-frame diffusion series carry it in private tags that differ by manufacturer, which is why b-value extraction is still vendor-conditional code in every pipeline that handles multi-vendor diffusion.

The pattern generalises: the more a field describes the physics rather than the filing, the weaker its obligation.

Table 1. Obligation tier against observed reliability. The identifiers a pipeline files on are Type 1; the parameters it reasons with cluster in Type 3.

Series Description is not a label

(0008,103E) Series Description is a Type 3 free-text field populated from the protocol as the technologist configured it. It is the field most curation scripts key on and the one least able to bear the weight.

It is free text, so it carries site conventions, local abbreviations and typographical drift. It is set from the protocol, so it describes what was intended, and survives unchanged when the technologist alters parameters mid-session. And it is not validated against anything, so a series labelled T1_MPRAGE_POST is a series someone named that, not a series that had contrast administered.

The practical consequence is that classifying series by description gives you a classifier trained on a site’s naming habits. Move to a second site and it degrades in ways that are invisible in aggregate statistics, which is one of the mechanisms behind the multi-site performance drops discussed in the header fields that break quantitative analysis.

Derived data announces itself, weakly

Image Type (0008,0008) carries ORIGINAL or DERIVED in value 1 and PRIMARY or SECONDARY in value 2. A DERIVED series has been through a processing step after reconstruction, and for quantitative purposes that step is usually unrecoverable — you cannot know from the header whether the derivation was a simple reformat or an interpolation that has already smoothed away the texture your feature extractor is about to measure.

The failure mode worth naming: DERIVED\SECONDARY series routinely enter cohorts because they are indistinguishable from originals by every other field. They then contribute measurements from a different processing history to the same distribution. This is a provenance problem before it is a statistics problem, and it is the reason metadata provenance has to be recorded at ingestion rather than reconstructed later, as argued in metadata provenance in imaging AI validation sets.

What to verify against the pixels

A short list of checks that catch most of what headers assert but do not establish:

1. Geometry. Recompute slice spacing from consecutive Image Position (Patient) values and compare it against (0018,0088) and (0018,0050). Disagreement means a gap, an overlap, or a non-uniform stack.
2. Rescale. For modalities using Rescale Slope (0028,1053) and Intercept (0028,1052), confirm the transformed values land in a physically plausible range. A CT series whose transformed air is not near −1000 HU has either a wrong rescale or is not what it claims to be.
3. Orientation consistency. Image Orientation (Patient) should be constant across a series. Variation within one Series Instance UID means the series has been assembled from more than one acquisition.
4. Frame ordering. Do not trust Instance Number (0020,0013) for spatial ordering. Sort on the projection of Image Position (Patient) onto the slice normal.

None of these are exotic. They are omitted mainly because a header that parses feels like a header that is true.

The rule worth adopting

Treat every acquisition parameter as a claim requiring corroboration, and every identifier as a fact. Identifiers are what DICOM exists to protect and what its obligation tiers actually defend. Acquisition parameters are description, and description is written by whoever configured the protocol.