A PACS migration is, at its core, a data migration. Move the imaging data correctly and the project succeeds. Miss a category of data quality problem and you either delay go-live or arrive on the other side with a new PACS populated with corrupt, mis-attributed, or inaccessible studies.
These are the five data quality failures I have seen derail PACS migrations most consistently — and what to do about each of them before migration day.
1. Duplicate Patient Records
What it looks like: The source PACS has patient SMITH JOHN with MRN 123456 and also patient SMITH, JOHN with MRN 123456. Or the same patient with two different MRNs because an HL7 merge event was missed years ago. Migrating both records creates a split patient history in the new system.
Why it happens: Years of interface changes, system upgrades, manual demographic corrections, missed A40 merges, and multiple feeding systems with slightly different patient ID formats all contribute to patient duplication over time.
How to find it:
- Run a query on your source PACS for duplicate MRNs
- Run a phonetic name match (Soundex or similar) across the patient index looking for near-matches with different MRNs
- Cross-reference against the current EMR patient master file
How to remediate it:
- For clear duplicates (same MRN, different spelling): merge in the source PACS before migration, then migrate the merged record
- For suspected duplicates (same demographics, different MRN): escalate to clinical records team — this requires human verification before any automated merge
- Do not migrate unresolved duplicates and rely on the new system to sort it out. It won't.
2. Corrupt or Unreadable DICOM Files
What it looks like: The migration tool reports errors on a percentage of DICOM files — typically 0.5–3% of a large archive. These files may have incorrect pixel data length, invalid tag values, truncated File Meta headers, or compressed pixel data that cannot be decompressed.
Why it happens: Years of ingestion from heterogeneous modalities, gateway transcoding failures, partial writes from network interruptions, and in some cases bit rot in the underlying storage.
How to find it: Run a pre-migration DICOM validation scan. For each file, verify:
- File Meta header is present and parseable
(0002,0000)Group Length matches actual Group 0002 byte count(0028,0010)×(0028,0011)×(0028,0100)/ 8 = pixel data length- SOP Instance UID in File Meta matches SOP Instance UID in dataset
- Transfer Syntax UID is a recognised value
Our DICOM Validator will flag all of these issues for individual files. For batch validation at scale, use dcmtk's dcmdump or a custom scan against the archive.
How to remediate it:
- Files with corrupt pixel data: cannot be recovered. Document them, exclude from migration, notify the clinical team, and preserve the originals in cold storage for audit purposes
- Files with fixable metadata issues (wrong group length, mismatched UIDs): remediate with dcmtk tools before migration. Document every change
- Target: < 0.1% unmigratable files before go-live
3. Missing or Wrong Demographics in DICOM Headers
What it looks like: Studies in the source PACS with blank Patient Name (0010,0010), placeholder IDs (000000, UNKNOWN), or demographics that don't match the current patient master record.
Why it happens: Manual entry on the modality bypassing the worklist (as covered in our Modality Worklist Troubleshooting post), historical interfaces before MWL was implemented, emergency studies performed before registration, and old imports from external CDs.
How to find it: Query your source PACS for studies with:
(0010,0010)Patient Name = empty, "UNKNOWN", or containing "^" with empty components(0008,0050)Accession Number = empty or matching a placeholder pattern(0010,0020)Patient ID = empty,0,000000
How to remediate it:
- Studies with correct Patient ID but wrong/missing name: enrich from the patient master file match
- Studies with no usable identifier: retain original data, flag for clinical review post-migration
- Establish a policy for how the new PACS will handle "unidentified" studies — dedicated dummy patient, separate worklist, specific naming convention
This is the category where a manual demographic correction programme (run by medical records 4–6 weeks before migration) pays for itself.
4. Non-Unique or Colliding UIDs
What it looks like: Multiple different DICOM objects share the same SOP Instance UID (0008,0018). Or multiple studies share the same Study Instance UID (0020,000D). When migrated, the new PACS silently overwrites earlier studies with later ones that share the same UID.
Why it happens: A modality was factory-reset without resetting its UID root counter. A DICOM copy tool reused UIDs when creating transformed copies. A PACS migration from a previous system imported studies with mis-generated UIDs.
How to find it: Run a SOP Instance UID uniqueness check across the full archive. Any UID appearing more than once is a collision. This query can be slow on large archives — run it during off-hours.
Check Study Instance UID collisions separately — a UID collision at the study level means images from different patients may be grouped together.
How to remediate it:
- UID collisions at the SOP Instance level: if both files are valid and different, you must generate new UIDs for one. Use the original as the Referenced SOP Instance UID in a derivation sequence to preserve the lineage
- UID collisions at the Study or Series level: do not silently merge. Investigate whether these are actually the same study stored twice, or two different studies with a UID generation failure
- After remediation, re-scan for UID uniqueness
5. Broken Study-to-Order Linkage
What it looks like: Studies in the source PACS with Accession Number (0008,0050) values that don't correspond to any current order in the RIS. Or Accession Numbers in a format from a previous RIS system that was replaced years ago.
Why it happens: RIS system replacements, order number format changes, and studies performed without an order (manual scans, external studies, emergency cases).
Why it matters for migration: The new RIS/PACS workflow depends on Accession Number to link images to reports. Orphaned studies — those without a valid RIS order — cannot be reported through the normal workflow in the new system.
How to find it: Cross-reference Accession Numbers from the source PACS against the current RIS order database. Studies with Accession Numbers not found in the RIS are orphaned.
How to remediate it:
- Recent orphaned studies (last 2 years): attempt to reconcile with the RIS. For each study, identify the corresponding order manually (patient + date + modality match) and update the Accession Number
- Historical orphaned studies (> 2 years): migrate as-is but tag them with a specific "legacy" flag or dummy accession prefix that identifies them as pre-integration studies
- Define a clear policy for how the new PACS handles legacy studies in the reporting workflow before go-live
The Migration Readiness Checklist
Before any PACS migration project can proceed to execution phase, all five of these data quality checks should be complete:
| Check | Target | Notes |
|---|---|---|
| Duplicate patient resolution | < 0.5% duplicate rate | Human review required for suspected clinical duplicates |
| DICOM file validation | < 0.1% unmigratable | Preserve originals of excluded files |
| Demographics enrichment | > 98% complete Patient ID + Name | Policy defined for unresolvable cases |
| UID uniqueness | Zero collisions | Re-scan after any remediation |
| Accession Number reconciliation | Policy defined for orphaned studies | Legacy prefix convention agreed with RIS team |
Data quality remediation takes longer than most project plans allow. Build 4–6 weeks of remediation time into your schedule, and run the validation scans early — not the week before go-live.
For a comprehensive overview of the full PACS migration project lifecycle, see the Complete PACS Implementation Guide.
Related: PACS Go-Live Checklist · PACS Storage Growth Calculator · Patient ID tag reference