DICOM Attribute

Specific Character Set (0008,0005)

Keyword
SpecificCharacterSet
VR
CS
VM
1-n

Definition

Character Set that expands or replaces the Basic Graphic Set. Required if an expanded or replacement character set is used. See for Defined Terms.

From NEMA PS3.3 §C.12.1.

Attribute Metadata

Tag
(0008,0005)
Keyword
SpecificCharacterSet
Name
Specific Character Set
Value Representation (VR)
CS
Value Multiplicity (VM)
1-n
Status
Active
Source
NEMA PS3.6 (table_6-1)

This attribute is part of the current DICOM Standard. Its value representation is CS with multiplicity 1-n.

Used in 4 Modules

This attribute uses the CS Value Representation. Multiplicity 1-n governs how many values may be encoded.

Integration Notes

Real-world integration guidance for engineers implementing this attribute in Mirth Connect, FHIR gateways, HL7 v2 bridges, and cloud DICOM services. Authoritative source data where available; reference examples and operational notes where they add value.

FHIR Mapping

No direct FHIR ImagingStudy mapping published for this attribute. Some tags map indirectly via the Patient, Endpoint, or ImagingSelection resources — Phase 2b will expand coverage to those.

HL7 v2 Equivalent

No standard HL7 v2 equivalent published for this attribute. Imaging-only attributes (Image Pixel data, technical acquisition parameters, modality-specific values) typically have no HL7 v2 carrier.

Cloud DICOM Support

AWS HealthImaging, Azure DICOM, and GCP Healthcare DICOM coverage rolls out by attribute. The QIDO-RS matching keys + Patient/Study/Series core (~50 attributes) are documented; lower-traffic attributes will be added as Saga teams encounter them in production.

Real-World Sample Values

  • ISO_IR 100 CT_small.dcm

Extracted from pydicom test fixtures (MIT, de-identified).

Mirth Connect Example

Specific Character Set normalization for non-ASCII Patient Names — Modalities in non-English-speaking countries emit DICOM with ISO-IR 100 (Latin-1

Modalities in non-English-speaking countries emit DICOM with ISO-IR 100 (Latin-1), ISO 2022 IR 13 (Japanese Romaji), or ISO IR 192 (UTF-8). Mirth must declare/convert.

// (0008,0005) Specific Character Set — ensure UTF-8 in outbound JSON
var charset = String(msg.dataset.attr.(@tag == '00080005').value).trim();
if (charset && charset !== 'ISO_IR 192' && charset !== 'ISO_IR 100') {
  channelMap.put('charset_warning', 'Source uses ' + charset + ' — verify display rendering downstream');
}
// Force UTF-8 in outbound — Mirth's String coercion handles the conversion
var pn = new java.lang.String(msg.dataset.attr.(@tag == '00100010').value.toString().getBytes('UTF-8'), 'UTF-8');
channelMap.put('patient_name_utf8', String(pn));

Reference only — validate before production. Snippets are starting points, not turnkey solutions. Always test against your channel's specific message structure and your facility's interface specification. See Mirth Connect User Guide + NEMA PS3.6 + your vendor conformance statement for authoritative specification.

Common Operational Errors

  • medium Specific Character Set absent — receiver assumes ISO-IR 6 (ASCII)

    Diagnosis: Per DICOM PS3.5, (0008,0005) is Type 1C — required when text fields contain non-ASCII characters. Modality omits the tag but emits Latin-1 bytes in PatientName. Receiver displays mojibake.

    Fix: On perimeter, if (0008,0005) is absent and any text field has bytes >0x7F: insert (0008,0005) = 'ISO_IR 100' (Latin-1) by default and log a warning. Push modality vendor for compliance.

  • medium UTF-8 data written without SpecificCharacterSet=ISO_IR 192

    Diagnosis: Modality acquires a name with non-ASCII characters (e.g., 'Müller', 'García') but doesn't set (0008,0005) SpecificCharacterSet. Default is ISO_IR 6 (ASCII). Downstream parsers interpret the UTF-8 bytes as ASCII and see mojibake ('Müller').

    Fix: At ingress, scan text-typed attributes (PN, LO, SH, LT, UT, ST) for non-ASCII bytes. If found and SpecificCharacterSet is missing or ASCII, set SpecificCharacterSet to 'ISO_IR 192' (UTF-8) explicitly. Most modern systems default to UTF-8 but some legacy archives require the tag be set.

Reference only — validate before applying a fix. Scenarios are drawn from common DICOM/HL7 v2 integration patterns; reproduce against your environment before acting on any diagnosis. See NEMA PS3.6 + your vendor conformance statement for authoritative specification. Severity levels: high (data-loss / patient-safety), medium (workflow disruption), low (cosmetic).

DICOM Integration Services

Saga IT builds production DICOM integrations across Mirth Connect, FHIR gateways, and cloud imaging platforms. If you're working with SpecificCharacterSet or the broader (0008,0005) context: