In short: DICOM tag normalisation rewrites or supplements inconsistent descriptive attributes, such as Study Description (0008,1030), Series Description (0008,103E) and Body Part Examined (0018,0015), using a governed mapping table to a standard vocabulary such as the LOINC/RSNA Radiology Playbook. Normalise once, as close to ingest as practical, keep the original values, and test before go-live.
Every PACS administrator in a multi-site network eventually inherits the same problem: dozens of spellings for one exam, routing rules multiplying to cope, and hanging protocols firing unreliably. DICOM tag normalisation is the disciplined fix, and done well it removes a whole class of downstream workarounds.
This guide covers which attributes matter, how to map them to a standard vocabulary, where normalisation should sit, and how to govern and test it. For the business case to share with leadership, see why study descriptions are a mess across sites.
What is DICOM tag normalisation?
DICOM tag normalisation is the process of transforming inconsistent values in selected DICOM attributes into agreed, consistent values, based on rules or a mapping table, while preserving the originals for audit.
It is needed because the standard leaves many descriptive attributes to local choice. Study Description is defined as an “institution-generated description or classification of the Study performed” [1], and Protocol Name as a “user-defined description of the conditions under which the Series was performed” [2]. Normalisation does not touch pixel data or identifiers such as Study Instance UID; it targets the descriptive layer that people and rule engines read. The result is the wider data inconsistency problem in radiology workflows, and it hits teleradiology workflows hardest.
Which DICOM attributes should you normalise?
For DICOM tag normalisation, start with the attributes your routing, prior-fetching and hanging protocols actually use. The table below lists the usual candidates, with tags and types verified against the current DICOM standard. Hanging protocols are a good example: see why hanging protocols matter to radiologists.
| Attribute | Tag | VR | Type / module | Why it matters |
|---|---|---|---|---|
| Study Description | (0008,1030) | LO | Type 3, General Study [1] | Primary label for search, routing, priors |
| Procedure Code Sequence | (0008,1032) | SQ | Type 3, General Study [1] | Coded procedure performed; best target for standard codes |
| Accession Number | (0008,0050) | SH | Type 2, General Study [1] | Links study to order; key for billing counts |
| Requested Procedure Description | (0032,1060) | LO | Requested Procedure module [3] | What was ordered, before local edits |
| Requested Procedure Code Sequence | (0032,1064) | SQ | Requested Procedure module [3] | Coded order; one item per procedure type |
| Series Description | (0008,103E) | LO | Type 3, General Series [2] | Drives series-level hanging protocols |
| Body Part Examined | (0018,0015) | CS | Type 3, General Series [2] | Anatomy for routing and display rules |
| Protocol Name | (0018,1030) | LO | Type 3, General Series [2] | Often the raw source of vendor default names |
| Modality | (0008,0060) | CS | Type 1, General Series [2] | Normally reliable; use as a mapping input |
| Request Attributes Sequence | (0040,0275) | SQ | General Series [2] | Can carry multiple requested procedures per series |
Two format constraints shape your target values. LO (Long String) allows up to 64 characters, and CS (Code String) allows up to 16 bytes of uppercase letters, digits, space and underscore [4]. A target Body Part Examined value must therefore be a valid code string. The standard publishes Defined Terms for Body Part Examined, with a mapping to SNOMED CT anatomic codes used in Anatomic Region Sequence (0008,2218), in PS3.16 Annex L [5]. Use those rather than inventing your own.
How do you map local names to a standard vocabulary?
In DICOM tag normalisation, map each distinct local value to one entry in an external, maintained vocabulary, and store the result both as a readable description and, where possible, as a code.
For procedures, the obvious reference is the LOINC/RSNA Radiology Playbook. It unifies the former LOINC radiology terms and the RSNA RadLex Playbook into a single model, developed by Regenstrief Institute and RSNA [6]. Each term is defined by attributes including modality, anatomic location, laterality, view, pharmaceutical (contrast or radiopharmaceutical), timing, maneuver, reason for exam and guidance [6]. The unified content was first released in 2015, and by LOINC version 2.63 it contained more than 5,800 active terms [7]. Terms are distributed within LOINC releases [6], whose use is governed by the LOINC licence and requires a LOINC account to download [8].
For series, RSNA’s RadLex Series Playbook work addresses the same problem one level down: series “are described in widely varying ways by different device manufacturers and sites” [9]. Check its current scope before relying on it.
A practical mapping workflow:
- Extract every distinct combination of Modality, Study Description, Requested Procedure Description and Body Part Examined from each site for a representative period.
- Rank by volume, so the first mapping effort covers the largest share of studies.
- Decompose each local name into Playbook attributes (modality, region, contrast, laterality) before choosing a target term.
- Assign a target code and a standard display name, and record confidence.
- Route unmapped values to a review queue rather than guessing.
Map on combinations, not on Study Description alone. “CT HEAD” means little until you know the modality and whether contrast was given.
Where should normalisation happen: at ingest, in the archive or in between?
For DICOM tag normalisation, normalise once, as early as practical, in a component that every downstream system trusts. There are three common placements, each with trade-offs.
| Placement | Strengths | Weaknesses |
|---|---|---|
| At the modality or ingest router | Clean data from the start; every consumer benefits | Rules spread across many routers; harder to change centrally |
| In the archive (PACS or VNA) | Central rules; can reprocess history | Tied to one product; other systems may read pre-normalised copies |
| A layer in between | Vendor-neutral; consistent across PACS, archives and downstream feeds | One more component to run and monitor |
In multi-vendor estates, a dedicated layer between sources and consumers usually gives the best balance, especially alongside a vendor-neutral archive. Whichever you choose, record what you changed. DICOM provides the Original Attributes Sequence (0400,0561), described as a “sequence of items containing all attributes that were removed or replaced by other values”, with a Reason for the Attribute Modification such as COERCE or CORRECT [10]. Also make sure the normalised values reach HL7 and FHIR consumers, not just DICOM ones; DICOM, HL7 and FHIR explained covers how those flows connect.
How do you govern the mapping table?
Good DICOM tag normalisation treats the mapping table as controlled configuration with a named owner, version history and a change process, not as a spreadsheet on someone’s desktop.
- Ownership. A clinical or operations lead approves target names; PACS administrators implement them.
- Versioning. Every change is dated, attributed and reversible.
- Intake. New sites, scanners and client catalogues trigger a mapping review before go-live.
- Monitoring. Track the unmapped rate weekly; a rise usually means a new protocol or scanner.
- Retirement. Deprecated target terms are mapped forward, not deleted.
Governance matters most when a new site arrives, which is exactly when variants appear; build it into your model for multi-site radiology operations.
How do you test DICOM tag normalisation before go-live?
Test against real historical data in a non-production environment, then compare downstream behaviour before and after.
- Build a test set from each site, covering high-volume exams, rare exams and known problem names.
- Run normalisation and check every output value is valid for its VR and length.
- Verify unchanged fields: UIDs, patient identifiers and pixel data must be untouched.
- Replay downstream: routing rules, prior-fetch queries and hanging protocols, comparing results with the original data.
- Check exam counts by type before and after, since grouping changes affect billing; see accurate exam counts for teleradiology per-study billing.
- Pilot one site, monitor the unmapped queue and exceptions, then roll out.
Where Evorad fits
Building a DICOM tag normalisation layer in-house is possible, but it is ongoing work. evoTag is Evorad’s study data standardisation component. It organises and corrects DICOM tags such as study descriptions, giving them consistent, accurate names, using the existing DICOM tags and study descriptions; it does not analyse image pixels and does not determine clinical urgency. The outcomes are those this guide aims for: reliable study grouping, search and retrieval, correct prior-study linking, more reliable hanging-protocol triggering, accurate counts of distinct exams, and normalised metadata for billing, analytics and EHR/HIS systems. Clean metadata also underpins worklist orchestration and reliable AI-ready imaging infrastructure.
Related guides
Frequently asked questions
Is DICOM tag normalisation the same as tag morphing?
They overlap. Tag morphing usually means rule-based rewriting of attributes in transit, often by a router or archive, for compatibility. Normalisation is the goal of making values consistent against an agreed vocabulary. Morphing is one technique for achieving it; a governed mapping table, audit trail and testing are what turn morphing into normalisation.
Should normalisation overwrite Study Description or add a code?
Ideally both. Many viewers and worklists display Study Description, so a consistent readable name delivers immediate value. A standard code in Procedure Code Sequence (0008,1032) gives systems an unambiguous key. Preserve the original value, for example in Original Attributes Sequence (0400,0561), so you can audit or reverse changes.
Do we need to normalise historical studies?
If you want consistent priors and analytics, yes, at least for the period radiologists compare against. Reprocessing history can be done in the archive or by replaying through the normalisation layer. Prioritise recent years and high-volume exams, and plan the load carefully so that reprocessing does not affect production performance.
Is the LOINC/RSNA Radiology Playbook suitable for European sites?
It is an international terminology and its attribute model is language-neutral, so it can serve as a common reference across countries. You may still need local display names in each language, and national requirements may specify other code systems. Check any national coding requirements before adopting it as your only reference.
Can normalisation change clinical content?
It should not. Normalisation targets descriptive metadata, not images, measurements or reports, and the radiologist remains responsible for interpretation and the report. Your test plan should explicitly confirm that pixel data, UIDs and patient identifiers are unchanged, and that every modified attribute has its original value preserved for audit.
Want normalised study data without rebuilding your routing estate? See how evoTag works from existing DICOM tags.
Sources
- DICOM PS3.3, Section C.7.2 “Patient and Study Modules” (General Study Module). NEMA, current edition. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.2.html
- DICOM PS3.3, Section C.7.3 “Series Modules” (General Series Module). NEMA, current edition. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html
- DICOM PS3.3, Section C.4.11 “Requested Procedure Module”. NEMA, current edition. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.4.11.html
- DICOM PS3.5, Section 6.2 “Value Representation (VR)”. NEMA, current edition. https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_6.2.html
- DICOM PS3.16, Annex L “Correspondence of Anatomic Region Codes and Body Part Examined Defined Terms”. NEMA, current edition. https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_L.html
- “LOINC/RSNA Radiology Playbook User Guide.” Regenstrief Institute (LOINC), last updated 29 February 2024. https://loinc.org/kb/users-guide/loinc-rsna-radiology-playbook-user-guide
- Vreeman DJ, Abhyankar S, Wang KC, et al. “The LOINC RSNA radiology playbook – a unified terminology for radiology procedures.” Journal of the American Medical Informatics Association, 2018. https://scholarworks.iupui.edu/bitstream/1805/19292/1/ocy053.pdf
- “Downloads.” LOINC, Regenstrief Institute, date not stated. https://loinc.org/downloads/
- “RadLex Series Playbook.” Radiological Society of North America (RSNA), date not stated. https://www.rsna.org/practice-tools/data-tools-and-standards/radlex-series-playbook
- DICOM PS3.18 Web Services, Annex I “Store Instances Response Module” (Original Attributes Sequence and Reason for the Attribute Modification). NEMA, current edition. https://dicom.nema.org/medical/dicom/current/output/chtml/part18/chapter_I.html
