DICOM Tags Reference for PACS Engineers (Practical Guide)

If you've ever stared at a DICOM dump wondering why a study routed to the wrong worklist, why images arrived but won't display, or why a patient merge created duplicates instead of resolving them — the answer was hiding in the tags.

DICOM tags are the metadata backbone of every image that flows through your enterprise imaging infrastructure. They control routing, matching, display, archival, and retrieval. When tags are correct, everything works invisibly. When they're wrong, you get tickets.

This guide is the DICOM tags reference we wish existed when we started. No academic theory. No pasted standard text. Just the tags that matter in real PACS work, the failures they cause, and how to fix them.

Who This Guide Is For

This guide is written for practitioners who work with DICOM daily:

• PACS Administrators troubleshooting routing, matching, and display issues
• Integration Engineers mapping HL7 to DICOM fields across modality interfaces
• Radiology IT Managers overseeing migrations, upgrades, and multi-vendor environments
• Clinical Engineers commissioning new modalities and validating DICOM conformance
• Healthcare IT Project Managers leading go-lives who need to understand what their engineers are debugging

If you already know what a DICOM tag is but want a fast, structured reference for the tags that actually break things in production — this is for you.

What "DICOM Tags" Actually Are (In One Clear Mental Model)

Think of every DICOM file as a structured envelope. The pixel data (the actual image) is the letter inside. The DICOM tags are everything printed on the envelope and the routing slip attached to it: who the patient is, what study this belongs to, which modality produced it, how to display it, and where to send it.

Every DICOM object — whether it's a CT slice, an MR series, a structured report, or a presentation state — carries a set of these DICOM header tags. The PACS reads these tags to decide how to file, match, route, and render the object. The RIS uses them to reconcile orders. The VNA uses them for lifecycle management. The viewer uses them for hanging protocols.

When people say "DICOM header," they mean this collection of tags. When people say "DICOM tag list," they're referring to the data dictionary — thousands of defined tag entries in the DICOM standard. In practice, you'll interact with maybe 40–60 of them regularly. About 25 of those cause the vast majority of production issues.

How DICOM Tags Are Structured (Group, Element, Keyword)

Every DICOM tag has three identifying components: a group number, an element number, and a keyword (human-readable name).

Tag Addressing: (gggg,eeee) Explained

Tags are written as a pair of four-digit hexadecimal numbers in the format (group, element). The group number clusters related tags together, and the element number identifies the specific attribute within that group.

You don't need to memorize group numbers. But recognizing them at a glance helps you navigate a DICOM dump faster. If a problem is about patient identity, look at 0010. If it's about routing or study context, start with 0008 and 0020.

Public vs Private Tags (And Why Private Tags Break Migrations)

Tags with an even group number (0008, 0010, 0020, 0028) are public tags — defined by the DICOM standard and interoperable across all vendors.

Tags with an odd group number (0009, 0019, 0021, 7005) are private tags — proprietary extensions created by vendors for internal use. Every major vendor uses private tags extensively. They store proprietary reconstruction parameters, presentation data, workflow flags, and licensing information.

Common pitfall: During a PACS migration, private tags from Vendor A are meaningless to Vendor B. If the new system strips them, you may lose reconstruction capabilities, dose information, or display presets. If it preserves them blindly, you accumulate dead metadata. Always map which private tags carry clinical value before migration and decide on a per-vendor, per-modality handling strategy.

Private tags are the single biggest source of "it worked in the old system but not the new one" complaints during cutovers.

VR and VM: The Two Attributes That Cause the Most Mistakes

Every DICOM tag has a Value Representation (VR) that defines its data type, and a Value Multiplicity (VM) that defines how many values it can hold. Getting these wrong during interface mapping or tag rewriting is a common and frustrating source of failures.

Common VR Types You'll See in PACS Work

VM Explained (1, 1-n, 2, 2-n)

VM tells you how many values the tag can contain, separated by backslashes.

• VM = 1: Exactly one value. Patient ID is VM 1 — one ID per patient.
• VM = 1-n: One or more values. Image Type (0008,0008) can hold multiple descriptors like ORIGINAL\PRIMARY\AXIAL.
• VM = 2: Exactly two values. Pixel Spacing (0028,0030) holds row spacing and column spacing.
• VM = 2-n: Two or more values. Image Position Patient (0020,0032) holds x, y, z coordinates.

Field note: When a modality sends a tag with VM = 1-n but your interface engine treats it as a single value, you'll silently lose data after the first backslash. This is a classic HL7-to-DICOM mapping bug, especially with Image Type and Institutional Department Name.

Required vs Optional vs Conditional Tags (What "Type 1/2/3" Means)

The DICOM standard classifies tags by obligation level within each Information Object Definition (IOD):

• Type 1 (Required): Must be present and must contain a valid value. If missing or empty, the object is technically non-conformant. Example: Patient ID (0010,0020) in most IODs.
• Type 1C (Conditionally Required): Required only under specific conditions defined by the IOD. When the condition applies, it behaves like Type 1.
• Type 2 (Required, May Be Empty): Must be present in the dataset, but can have a zero-length (empty) value. The tag must exist even if blank. Example: Patient's Birth Date (0010,0030).
• Type 2C (Conditionally Required, May Be Empty): Same as Type 2, but only under defined conditions.
• Type 3 (Optional): May or may not be present. No obligation. Example: Patient Comments (0010,4000).

Common pitfall: Many interface engines and modality worklist providers send Type 2 tags with the tag absent entirely rather than present-but-empty. Technically, this is non-conformant. Some PACS systems tolerate it; others reject the association or fail the C-STORE. If you see "missing required attribute" errors in your PACS logs, check whether the sending system omits Type 2 tags instead of sending them empty.

The 25 DICOM Tags PACS Engineers Troubleshoot Most Often

These are the PACS DICOM tags you'll reference repeatedly. For each one, we note the tag, its keyword, VR, and what goes wrong in practice.

Patient & Demographics Core Tags

(0010,0010) Patient's Name — VR: PN The primary patient identifier for display and matching. Format is Last^First^Middle^Prefix^Suffix. When the name format doesn't match between the order (from HL7/RIS) and the modality output, studies appear as unmatched or under the wrong patient. This is the number one cause of manual reconciliation work.

(0010,0020) Patient ID — VR: LO The machine-readable patient identifier, typically the MRN. If this doesn't match the value in the RIS order, the PACS cannot auto-reconcile the study. Leading zeros, trailing spaces, and prefix/suffix discrepancies between systems are the usual culprits.

(0010,0030) Patient's Birth Date — VR: DA Used for patient matching and demographic verification. If the modality receives the wrong DOB from the worklist (or no DOB at all), it creates a mismatch that shows up as a reconciliation error in the PACS.

(0010,0040) Patient's Sex — VR: CS Valid values are M, F, or O. Some modalities send blank or non-standard values. By itself this rarely causes failures, but it can trigger validation warnings in PACS and may affect dose reference calculations.

Study-Level Identity Tags

(0020,000D) Study Instance UID — VR: UI The globally unique identifier for the entire study. This is the anchor tag for study-level operations: routing, matching, retrieval, and migration integrity. If two different studies share the same Study Instance UID (which happens during misconfigured secondary captures or copy/paste workflows), you get study corruption.

(0008,0050) Accession Number — VR: SH The bridge between radiology orders and imaging. The accession number links the DICOM study to the RIS order for worklist matching, report association, and billing. When it's missing, empty, or doesn't match the order, the study arrives unlinked. SH is only 16 characters — if your RIS generates longer accession numbers, they'll get truncated.

(0008,0020) Study Date — VR: DA The date the study was performed. Used for study sorting, hanging protocol logic, and prior study retrieval. When modalities have incorrect system clocks or timezone offsets, studies appear filed under the wrong date.

(0008,0030) Study Time — VR: TM Study timestamp. Combined with Study Date, this determines chronological ordering. Inconsistent time precision across modalities can cause sorting anomalies in study lists.

(0008,1030) Study Description — VR: LO Human-readable study description, often populated from the worklist's Requested Procedure Description. When this is blank or generic ("CT SCAN"), it hurts radiologist workflow because they can't identify the study purpose from the worklist.

(0032,1060) Requested Procedure Description — VR: LO The procedure description as sent by the RIS. This tag and Study Description are often confused. Some modalities map Requested Procedure Description to Study Description; others keep them separate. Misalignment between these two creates inconsistent study labeling.

Series & SOP Instance Identity Tags

(0020,000E) Series Instance UID — VR: UI Unique identifier for each series within a study. If duplicate Series Instance UIDs appear (from modalities that reuse UIDs incorrectly), the PACS will overwrite or merge series unintentionally, resulting in missing images.

(0008,0018) SOP Instance UID — VR: UI Unique identifier for each individual object (image, report, presentation state). Duplicate SOP Instance UIDs cause the most dangerous form of data loss — the PACS silently overwrites the first instance with the second. This happens more often than it should, especially with secondary capture and third-party CD import workflows.

(0020,0013) Instance Number — VR: IS The ordinal position of an image within its series. When this is wrong or duplicated, images appear out of order in the viewer. Not a data integrity issue, but it degrades the reading experience and wastes radiologist time.

(0020,0011) Series Number — VR: IS Ordinal position of a series within the study. Like Instance Number, incorrect values cause sorting problems rather than data loss.

Acquisition Context Tags (Modality, Protocol, Body Part)

(0008,0060) Modality — VR: CS The type of equipment that produced the images (CT, MR, CR, DX, US, etc.). This tag drives routing rules, hanging protocols, and workload distribution. If the Modality tag value is wrong (e.g., a DR system sending "CR"), images route to the wrong destination or display with the wrong hanging protocol.

(0018,1030) Protocol Name — VR: LO The acquisition protocol as configured on the modality. Used by hanging protocol engines and for dose tracking. Inconsistent protocol naming across identical scanners in a multi-site environment causes hanging protocol mismatches — the same exam type gets displayed differently depending on which scanner produced it.

(0018,0015) Body Part Examined — VR: CS Identifies the anatomical region. Used for hanging protocols and routing. When this tag is missing or incorrect, the viewer may select the wrong display preset. Some modalities populate this reliably; many don't.

(0008,0070) Manufacturer — VR: LO Identifies the equipment manufacturer. Useful during troubleshooting to isolate vendor-specific behaviors. During migrations, this tag helps you build per-manufacturer handling rules for private tags.

---

🛠️ Tired of tracking all these tags in spreadsheets during go-lives?

The PACS Starter Bundle gives you the structured tools PACS engineers actually use during deployments:

• PACS Go-Live Checklist — 47 validated checkpoints covering pre-cutover through post-go-live
• PACS Storage Growth Calculator — formula-driven capacity planning with modality-level projections
• DICOM Troubleshooting Workbook — systematic tag validation and failure isolation workflows
• VM Sizing Calculator — right-size your infrastructure before it becomes a bottleneck

Built from 10+ years of real hospital deployments. Get the bundle →

---

Display / Presentation & Laterality Gotchas

(0028,0010) Rows and (0028,0011) Columns — VR: US Define the image matrix dimensions. If these are incorrect (rare but possible with secondary capture or format conversion), the viewer renders garbage or crashes.

(0028,0004) Photometric Interpretation — VR: CS Defines how pixel data should be interpreted (MONOCHROME1, MONOCHROME2, RGB, YBR_FULL, etc.). When the transfer syntax changes during compression but this tag isn't updated, images display inverted or with wrong colors.

(0020,0060) Laterality — VR: CS Indicates left (L) or right (R) for paired body parts. When this tag is missing or incorrect on mammography, extremity, or ophthalmology exams, there is a direct patient safety risk. Some PACS systems enforce laterality validation; most don't.

(0020,0020) Patient Orientation — VR: CS Describes the orientation of the patient relative to the image (e.g., A\P for anterior/posterior). When absent or wrong, annotation overlays in the viewer display incorrect orientation markers.

(0008,0008) Image Type — VR: CS, VM: 2-n Multi-valued tag describing image characteristics (ORIGINAL\PRIMARY, DERIVED\SECONDARY, etc.). Hanging protocol engines rely heavily on this tag. When modalities send non-standard values or omit it, the viewer can't distinguish original from reformatted images.

A Practical Workflow: How to Troubleshoot Using Tags (Step-by-Step)

When a DICOM-related issue hits your queue, use this structured approach instead of randomly scanning tag dumps.

Step 1: Identify the Failure Mode (Routing, Matching, Display, Archive)

Before you touch a single tag, classify the problem:

• Routing failure: Images sent to wrong destination or not arriving at all → Focus on Modality (0008,0060), AE Title configuration, and Called/Calling AE tags.
• Matching failure: Study arrived but isn't linked to the order → Focus on Accession Number (0008,0050), Patient ID (0010,0020), Patient Name (0010,0010).
• Display failure: Images present but look wrong or hang incorrectly → Focus on Image Type (0008,0008), Photometric Interpretation (0028,0004), Window Center/Width, Body Part (0018,0015).
• Archive failure: C-STORE rejected or images overwritten → Focus on SOP Instance UID (0008,0018), Study Instance UID (0020,000D), transfer syntax.

Step 2: Confirm Identity Chain (Patient → Study → Series → SOP)

Check the four-level DICOM identity hierarchy in order:

1. Patient ID (0010,0020) — Does this match the expected MRN?
2. Study Instance UID (0020,000D) — Is this unique to this study?
3. Series Instance UID (0020,000E) — Is each series carrying a distinct UID?
4. SOP Instance UID (0008,0018) — Is every object truly unique?

If any level has duplicates or mismatches, you've found your problem.

Step 3: Validate Modality + Study Context

Check (0008,0060) Modality, (0008,0050) Accession Number, and (0008,1030) Study Description. These three tags control how the PACS files, routes, and displays the study. If the modality tag is wrong, routing breaks. If accession is wrong, matching breaks. If description is empty, workflow suffers.

Step 4: Compare Two Files (Working vs Broken)

The fastest way to isolate a tag issue: get a DICOM dump from a working study and a broken study of the same type from the same modality. Diff the headers. The delta will reveal exactly which tag value changed and caused the failure.

Step 5: Decide: Fix at Source vs Fix via Engine vs Fix in PACS Rules

Once you've identified the bad tag:

• Fix at source: Reconfigure the modality or worklist provider to send the correct value. This is the cleanest fix but often requires vendor involvement and change control.
• Fix via engine: Use your interface engine (Mirth, Rhapsody, Cloverleaf, etc.) to transform the tag value in transit. Fast to deploy but adds a maintenance layer.
• Fix in PACS rules: Some PACS systems have built-in tag-mapping or auto-correction rules. Useful for known, consistent discrepancies.

Field note: Always prefer fixing at source when possible. Engine-based transforms accumulate over years and become an undocumented mess that no one can maintain. Document every transform rule, including why it exists and when it was added.

Common Real-World Failure Patterns (And The Tags Behind Them)

"Wrong Patient / Merge Issues"

Root cause: Patient Name (0010,0010) or Patient ID (0010,0020) mismatch between the modality worklist response and what the technologist selected. Accents, special characters, hyphenated names, and middle name handling are the usual triggers.

Resolution: Standardize name formatting in the worklist provider. Implement modality worklist query filtering to reduce selection errors. Verify HL7-to-DICOM name component mapping at the interface engine.

"Study Not Matching Order / Missing Accession"

Root cause: Accession Number (0008,0050) is empty, truncated, or doesn't match the RIS order. This also happens when technologists start an exam without querying the worklist (manual entry).

Resolution: Enforce worklist usage via modality configuration. Validate that the accession number field in your HL7 ORM maps correctly to DICOM tag (0008,0050) through the interface. Check for SH truncation at 16 characters.

"Images Arrive but Don't Display Correctly"

Root cause: Photometric Interpretation (0028,0004) mismatch after compression, incorrect Window Center (0028,1050) / Window Width (0028,1051) values, or missing Pixel Spacing (0028,0030) causing measurement tools to fail.

Resolution: Verify the transfer syntax negotiation between the modality and PACS. If lossy compression is applied mid-route, confirm that presentation-related tags are updated. Check if the viewer is applying modality-specific LUT corrections.

"Series Split / Duplicate Studies"

Root cause: Duplicate or recycled Study Instance UID (0020,000D) or Series Instance UID (0020,000E). This is especially common with secondary capture workstations and third-party CD import workflows that reuse UIDs.

Resolution: Audit the UID generation logic on the offending source. Secondary capture systems should generate new UIDs for every capture. CD import workflows must create new Study/Series/SOP UIDs unless explicitly merging into an existing study.

"Hanging Protocol Misfires"

Root cause: Hanging protocols rely on a combination of Modality (0008,0060), Body Part Examined (0018,0015), Study Description (0008,1030), and Image Type (0008,0008). When any of these are inconsistent across sites or modalities, the protocol selects the wrong layout or fails to trigger.

Resolution: Standardize protocol naming, body part coding, and study descriptions across your fleet of modalities. Build hanging protocol rules that account for known variations rather than assuming perfect tag consistency.

DICOM Tags During PACS Migration (What Must Be Stable)

Migrations are where tag handling makes or breaks the project. Every PACS stores data slightly differently, and the act of moving data between systems can alter tags in ways that break downstream workflows.

UID Stability Rules (What You Must Never Change)

The three UIDs in the identity hierarchy — Study Instance UID (0020,000D), Series Instance UID (0020,000E), and SOP Instance UID (0008,0018) — must remain unchanged during migration. These are the globally unique keys that link images to reports, bookmarks, teaching files, and external references.

If UIDs change during migration:

• Prior study references in radiology reports become broken links
• Peer review and quality assurance records lose their image associations
• Teaching file collections and research datasets become orphaned
• Compliance and legal hold references become invalid

Field note: Some migration tools offer a "re-UID" option for conflict resolution. Use this only as a last resort for genuine UID collisions, and maintain a mapping table of old-to-new UIDs. Re-UIding an entire archive is almost never the right answer.

When Rewriting Tags Is Acceptable (And When It's Dangerous)

Safe to rewrite:

• Patient Name formatting (to match new PACS conventions)
• Accession Number padding or prefix changes (if the RIS mapping also changes)
• Institution Name (0008,0080) and Station Name (0008,1010) for organizational updates
• Referring Physician Name (0008,0090) for format normalization

Dangerous to rewrite:

• Any UID tag (Study, Series, SOP)
• Modality (0008,0060) — will break routing and hanging protocols
• Pixel Data related tags (Rows, Columns, Bits Allocated, Photometric Interpretation) — will corrupt image rendering
• Transfer Syntax UID — must match the actual encoding of the pixel data

Never rewrite without a rollback plan. Always keep the original DICOM objects accessible until the migration is validated.

Minimal Tag Validation Checklist (Pre Go-Live / During Cutover)

Use this as a quick validation pass for every modality-PACS pathway before go-live:

1. ☐ Patient ID (0010,0020) matches MRN from worklist — no truncation, no extra characters
2. ☐ Patient Name (0010,0010) format matches PACS expectations (Last^First component order)
3. ☐ Accession Number (0008,0050) populates from worklist and is ≤ 16 characters
4. ☐ Study Instance UID (0020,000D) is unique per study (not reused across exams)
5. ☐ SOP Instance UID (0008,0018) is unique per object (verify with secondary capture)
6. ☐ Modality (0008,0060) sends correct code (verify DR sends DX, not CR, if intended)
7. ☐ Study Description (0008,1030) populates from worklist — not blank
8. ☐ Body Part Examined (0018,0015) populates correctly for hanging protocol matching
9. ☐ Image Type (0008,0008) contains expected values for the modality type
10. ☐ Transfer syntax negotiated correctly (explicit VR preferred for interoperability)
11. ☐ Laterality (0020,0060) populates on mammography, extremity, and paired-organ exams
12. ☐ Private tags from outgoing modality are handled (preserved, stripped, or mapped) per migration plan

Common pitfall: Don't validate with just one test exam per modality. Run at least three different exam types (different protocols, different body parts) to catch conditional tag population issues. A chest CT might populate Body Part correctly while an abdomen/pelvis from the same scanner doesn't — because the protocol mapping differs.

FAQ

What's the difference between a DICOM tag and a DICOM header? A DICOM header is the collection of all metadata tags in a DICOM file, everything before the pixel data. A DICOM tag is a single attribute within that header. When people say "check the DICOM header," they mean "examine the individual tags."

How do I view DICOM tags on a file? Use a DICOM dump tool. Free options include dcmdump (from the DCMTK toolkit), DICOM viewers with header inspection (Horos, RadiAnt), or web-based parsers. On the command line, dcmdump filename.dcm will output every tag with its value.

Can I edit DICOM tags after images are archived? Yes, using tools like dcmodify (DCMTK) or DICOM tag editors. However, editing archived images should follow strict change control. Modifying UIDs or pixel-related tags on archived studies is risky and should involve your PACS vendor's recommended procedure.

What are the most common tags that break during PACS migrations? Patient Name format mismatches, Accession Number truncation, private tag stripping (losing dose or reconstruction data), and UID collisions from poorly configured migration tools. Study Description going blank is also common when the source and destination systems map the field differently.

Why do some modalities send different tag values for the same exam type? Modality configuration varies. Even two identical scanners from the same vendor can send different Body Part or Protocol Name values if their protocol libraries were set up independently. This is why fleet standardization is part of PACS deployment planning.

What does "Explicit VR Little Endian" mean for tags? It's a transfer syntax that explicitly encodes the VR of each tag in the data stream. This is the most interoperable transfer syntax. "Implicit VR Little Endian" omits VR from the stream and requires the receiver to look it up. Implicit VR causes interoperability issues with private tags because the receiver can't determine the data type.

How many DICOM tags exist in the standard? The DICOM data dictionary contains several thousand defined tags. In practice, a typical image file contains 50–150 tags, and you'll regularly troubleshoot about 25–30 of them.

Should I validate DICOM tags at every interface point or just at the PACS? Validate at the earliest point possible. If the modality sends bad data, it's better to catch it at the modality or the interface engine than to let it propagate through the entire workflow and discover the problem at the PACS or — worse — at the radiologist's workstation.

Summary: What To Do Next

DICOM tags are the control plane of your imaging infrastructure. Understanding which tags matter, how they fail, and where to fix them is the difference between reactive firefighting and systematic, predictable deployments.

Keep this reference bookmarked for your next troubleshooting session, migration planning meeting, or go-live cutover. The 25 tags listed here cover the vast majority of production issues you'll encounter.

If you want to go beyond reference material and into structured, ready-to-use deployment tools, the next step is straightforward:

---

📦 The PACS Starter Bundle — Built for Engineers Who Deploy

Stop rebuilding checklists from scratch for every project. The PACS Starter Bundle packages the tools PACS engineers actually need during implementations:

• PACS Go-Live Checklist — 47 validated checkpoints, from infrastructure pre-checks through post-cutover stabilization
• PACS Storage Growth Calculator — formula-driven projections by modality, with multi-year capacity planning
• DICOM Troubleshooting Workbook — systematic workflows for isolating and resolving tag-level failures
• VM Sizing Calculator — right-size servers and storage before procurement, not after

Every item built from 10+ years of real hospital deployments. No filler. No fluff.

Get the PACS Starter Bundle →