DICOM · Tool

DICOM Validator — Check Files Against the NEMA Standard

Drop a .dcm file into the validator and get a report of every attribute that's missing, malformed, or violates a conditional requirement — checked against the official NEMA PS3 standard.

Coming soon Get notified at launch

In active development — not yet available in the browser.

What gets validated

Type 1 attributes — required with a value. Missing = critical failure.
Type 1C attributes — required under a condition defined in PS3.3. Validator evaluates each condition and flags violations.
Type 2 attributes — required to be present, value may be empty.
Type 2C attributes — conditional presence requirement.
Value representation — does the actual VR match what PS3.6 declares?
Value multiplicity — is the VM within PS3.6 bounds?
UID format — canonical OID-style, under 64 chars, digits + dots only.
Enum values — CS-VR attributes checked against PS3.3 defined terms.

Where the rules come from

Every validation rule traces back to the parsed NEMA PS3 standard shipped with the Saga DICOM standard browser. Our parse covers:

PS3.3 CIODs — composite object definitions for every SOP class.
PS3.3 modules — attribute groupings (Patient, Study, Series, etc.).
PS3.6 attributes — all tags with VR, VM, retired status.
PS3.4 SOP classes — what CIOD each SOP class instantiates.

Production validation pipelines

The browser validator covers ad-hoc file checks. For continuous-integration validation of incoming PACS traffic, Saga's medical imaging integration team builds Mirth Connect + Orthanc + dcm4che filters that gate non-conformant studies before they land in the archive.

What a failure report looks like

Each issue is surfaced with: severity (error / warning), the failing tag, the rule violated, and a link to the authoritative NEMA source. For example:

ERROR   (0010,0020) PatientID  — Type 1 attribute missing
        Required by Patient Module. See PS3.3 Section C.7.1.1

WARN    (0008,0016) SOPClassUID — Declared SOP class has no
        conforming CIOD. File may fail downstream PACS ingest.

WARN    (0008,0060) Modality — Value "CTA" not in PS3.3 Defined
        Terms. Consider "CT" (standard) or "CR" (computed radiography).

FAQ

What does a DICOM validator check?

Whether the file conforms to the SOP Class it claims. Verifies: required (Type 1) attributes present, conditional (Type 1C / 2C) attributes correct per their conditions, value representations match what PS3.6 defines, VM (multiplicity) within bounds, enum values from the allowed list, UID format valid.

What's a CIOD and why does validation need it?

CIOD = Composite Information Object Definition — the complete object structure for a SOP class (e.g., CT Image CIOD). Each CIOD references a set of modules (Patient, Study, Series, Image Plane, etc.), and each module has required and optional attributes. Validation walks the loaded file against the CIOD hierarchy. Browse CIODs in the spec browser.

Why would a DICOM file fail validation?

Common causes: a modality dropped a Type 1 tag (most often PatientID or StudyInstanceUID), a Type 1C condition wasn't satisfied (e.g., ImageType set to SECONDARY without the referenced equipment tags), a VR mismatch from a mis-configured transform, UID format invalid, or a sequence attribute missing its item delimiters.

Does the validator use the NEMA standard as the reference?

Yes — it validates against the parsed PS3.3 CIODs + modules + PS3.6 attribute dictionary that powers the Saga DICOM standard browser. Every validation rule links back to the NEMA source, so you can click through to the authoritative definition of any failing tag.

Is this a diagnostic-quality validator?

For conformance checks against NEMA PS3 — yes. For production PACS validation with site-specific business rules, custom acceptance criteria, or high-throughput CI integration — you probably want a dedicated pipeline. Saga's medical imaging team builds conformance pipelines for institutions that need that level.