A PACS migration is one of the few IT projects where "it seems to have worked" is not an acceptable conclusion. The archive holds diagnostic records that clinicians will rely on for years and that the organisation is legally obliged to retain. If a migration silently drops attributes, breaks the study hierarchy, or transcodes images, the damage may not surface until a radiologist cannot find a prior study during a reporting session.
Validation therefore has to be evidential rather than impressionistic. A tag-level comparison of source and destination objects is the fastest way to produce that evidence, but only if you know which differences are defects and which are expected. This article covers both.
What You Are Actually Comparing
A DICOM file is a data set of attributes, each identified by a tag written as group and element — (0010,0010) for Patient Name, (0020,000D) for Study Instance UID. Each attribute carries a Value Representation, a two-letter type code such as PN, DA, UI or SQ, that determines how its bytes are interpreted.
This structure is why a byte-level file comparison is close to useless for migration QA. Two files containing identical clinical content will differ in bytes whenever the transfer syntax differs, the attribute order differs, or padding differs. What you need is a comparison that matches attributes by tag and compares the decoded values — a semantic diff, not a binary one.
Differences That Are Expected
Start by cataloguing what your migration is supposed to change. Anything on this list appearing in the diff is not a defect:
- File meta information. Implementation Class UID (0002,0012) and Implementation Version Name (0002,0013) identify the writing software. A different archive wrote the destination object, so these differ by definition.
- Transfer syntax. Destination archives frequently store with a different transfer syntax — explicit versus implicit VR is the usual case. If your comparison works on decoded values rather than raw bytes, this produces no differences at the attribute level at all.
- Coerced identifiers. Most archives are configured to coerce Patient ID (0010,0020), Accession Number (0008,0050) or Study ID (0020,0010) against the receiving institution's master patient index. This is deliberate, and verifying it happened correctly is part of the validation rather than a finding against it.
- Archive timestamps. Instance Creation Date and Time, and any private attributes recording receipt, will differ by design.
Write this list down before you start. A validation that has not defined its expected differences in advance tends to rationalise findings after the fact, which is precisely what makes a QA record indefensible.
Differences That Are Defects
Everything else deserves scrutiny, and three categories deserve it most.
UIDs and the Study Hierarchy
Study Instance UID, Series Instance UID and SOP Instance UID form the hierarchy that lets an archive assemble loose instances into a coherent study. In a straight migration these must be preserved exactly. A changed SOP Instance UID does not mean an object moved — it means a new object was created, and the original identity is gone. Downstream consequences include duplicate studies, broken prior-study links, and reports that reference instances the archive can no longer resolve.
This is the single highest-value check in a migration validation, and it is why filtering a diff to attributes with VR UI is worth doing first. If every UI attribute is identical, the identity layer survived.
Pixel-Describing Attributes
Rows (0028,0010), Columns (0028,0011), Bits Allocated (0028,0100), Bits Stored (0028,0101), High Bit (0028,0102), Pixel Representation (0028,0103) and Photometric Interpretation (0028,0004) describe how to interpret the pixel data. A change here means the image itself has been altered or re-encoded. Rescale Slope and Intercept (0028,1053 and 0028,1052) matter just as much on modalities such as CT, where they convert stored values into Hounsfield units — a changed intercept silently shifts every density measurement a clinician takes.
Geometry
Image Position Patient (0020,0032), Image Orientation Patient (0020,0037), Pixel Spacing (0028,0030) and Slice Thickness (0018,0050) determine how a series reconstructs in three dimensions. Corruption here produces multiplanar reconstructions that are subtly wrong rather than obviously broken, which makes it particularly dangerous — nothing looks like an error until a measurement is taken from it.
Sequences: The Part Simple Tools Miss
An attribute with VR SQ contains an ordered list of items, each of which is a full nested data set that may contain further sequences. Scheduled Procedure Step Sequence (0040,0100), Referenced Image Sequence (0008,1140), Request Attributes Sequence (0040,0275) and the entire content tree of a DICOM Structured Report live inside sequences.
Many comparison tools skip sequences or collapse them into a single summary row such as "sequence with 2 items". That is not good enough for migration QA. Structured reports carry the clinical findings themselves inside nested content items; radiotherapy plans carry dose prescriptions there. A diff that reports both sides as "2 items" while the referring physician or the prescribed dose inside those items differs has told you nothing while appearing to have checked.
A correct comparison descends into each sequence, pairs items by index — order is significant within a sequence — and reports each nested attribute with its full path, so you can see exactly where in the tree a difference lives.
Using a Diff to Verify De-Identification
The same comparison serves a second purpose. When file B is meant to be a de-identified copy of file A, the diff becomes a verification report, and the expectation inverts: every attribute on the PHI list should have changed, and the clinical attributes should not.
Filtering to PHI attributes gives you that view directly. Any PHI attribute still reported as identical is a potential leak — a patient name, birth date, institution name, referring physician or accession number that survived the pipeline. DICOM PS3.15 Annex E defines the confidentiality profiles that specify which attributes must be handled and how; the diff is how you check a real pipeline against that specification on real files.
Note the UID rule flips here. In a migration, UIDs must be preserved. In de-identification, UIDs generally must be replaced, because a retained Study Instance UID links the anonymised copy straight back to the original study in the source archive. Running the UID filter answers the right question in both cases; only the expected answer changes.
Check the reverse direction too. If a clinically significant attribute shows as changed when it should not have been, the de-identification profile is more aggressive than intended. Over-anonymisation that strips acquisition parameters or geometry can quietly destroy the research value of a data set, and it is much harder to notice than a leak because nothing about it looks like a failure.
A Practical Validation Workflow
- Select a representative sample. Cover each modality in the archive, plus the awkward cases: multi-frame objects, structured reports, presentation states, and any studies with unusual character sets or non-Latin patient names.
- Define expected differences first. Write down the coercion rules and the implementation attributes before looking at any output.
- Run the UID filter. Confirm the identity layer behaved as the operation requires — preserved for a migration, regenerated for de-identification.
- Run the differences-only view. Read every row if the count is small. If it is large, sweep by VR: DA and TM for dates, PN for names, CS for coded values, DS for the numeric geometry attributes.
- Check the pixel and geometry attributes explicitly. These are the ones whose corruption is invisible in a viewer.
- Export the report. A CSV attached to the migration ticket is what makes the validation auditable months later.
- Swap and re-read. Viewing the comparison from the other direction catches attributes present only in the destination, which are easy to overlook when you are thinking about what was lost.
What a Header Diff Cannot Tell You
Being clear about scope is what makes a QA tool's output usable as evidence. A tag-level diff compares headers and metadata. It will confirm that Rows, Columns and Bits Allocated match — strong evidence that the pixel data is structurally intact — but it does not decode and compare the pixels themselves. A migration that preserved every header attribute while transcoding or corrupting the image data would produce a clean diff.
It also does not validate conformance. An object can differ from its source in no attribute at all and still violate the IOD it claims to conform to, if the source was non-conformant to begin with. Conformance checking is a separate exercise against PS3.3.
A header diff therefore belongs in a validation suite alongside a pixel-level comparison and a visual review of a representative sample. It is the fastest way to find every difference a header can express, and it is deliberately silent about the ones it cannot.
Why Browser-Based Matters Here
DICOM files routinely contain protected health information. Uploading them to a third-party web service to run a comparison is a disclosure, and in most organisations it is one that has not been authorised — which is why so many clinical engineers fall back to the command line even when a web tool would be quicker.
A tool that parses both files locally in the browser removes that trade-off. Nothing is transmitted, so there is no disclosure to authorise, and it works on a locked-down clinical workstation where installing DCMTK is not an option.
Try It
Our DICOM diff tool implements the workflow above: a three-way verdict per attribute, recursion into sequences with full paths, PHI and UID filters using the same tag definitions as our de-identifier, VR narrowing, search, and CSV export with a stable column order. Both files are parsed entirely in your browser.
To inspect a single file's attributes rather than compare two, the DICOM tag viewer is the better starting point. If you are producing the de-identified copy in the first place, the DICOM de-identifier applies the PS3.15 confidentiality profiles — and the diff is how you prove it did what you expected.