DICOM Attribute
Modality (0008,0060)
- Keyword
Modality- VR
CS- VM
1
Definition
Type of device, process or method that originally acquired or produced the data used to create the Instances in this Series. See for Defined Terms.
From NEMA PS3.3 §C.7.3.1.
Attribute Metadata
This attribute is part of the current DICOM Standard. Its value representation is CS with multiplicity 1.
Used in 47 Modules
- Autorefraction Measurements Series 1
- Corneal Topography Map Series 1
- CT Protocol Series 1
- CT Series 1
- DX Series 1
- Encapsulated Document Series 1
- Enhanced Mammography Series 1
- Enhanced PET Series 1
- Enhanced RT Series 1
- Enhanced US Series 1
- General Series 1
- Hanging Protocol Definition 1C
- Intra-Oral Series 1
- Intraocular Lens Calculations Series 1
- Intravascular OCT Series 1
- Inventory 1
- Keratometry Measurements Series 1
- Key Object Document Series 1
- Lensometry Measurements Series 1
- Mammography Series 1
- Microscopy Bulk Simple Annotations Series 1
- MR Series 1
- Ophthalmic Axial Measurements Series 1
- Ophthalmic Photography Series 1
- Ophthalmic Thickness Map Series 1
- Ophthalmic Tomography B-scan Volume Analysis Series 1
- Ophthalmic Tomography En Face Series 1
- Ophthalmic Tomography Series 1
- Optical Surface Scanner Series 1
- Parametric Map Series 1
- Presentation Series 1
- Real World Value Mapping Series 1
- RT Series 1
- SC Equipment 3
- Segmentation Series 1
- Spatial Fiducials Series 1
- Spatial Registration Series 1
- SR Document Series 1
- Stereometric Series 1
- Structure Set 1
- Subjective Refraction Measurements Series 1
- Tractography Results Series 1
- Visual Acuity Measurements Series 1
- Visual Field Static Perimetry Measurements Series 1
- Whole Slide Microscopy Series 1
- XA Protocol Series 1
- XA/XRF Series 1
Value Representation
This attribute uses the CS
Value Representation. Multiplicity 1 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.
HL7 v2 Equivalent
-
OBR-24Diagnostic Service Section IDORMORUOBR-24 carries the modality code (CT, MR, US, NM, etc.) using the same DICOM CID 30 / table 6029 codes. Often also encoded in OBR-21 (Filler Field 1).
Source: IHE RAD-TF Vol 2 §4.7
Verify against IHE Radiology TF Vol 2 and your facility's interface specification before production use.
Cloud DICOM Support
- AWS HealthImaging Queryable
- Azure DICOM Queryable
- Google Cloud Healthcare Queryable
Modality is a Series-level QIDO-RS matching key on all three platforms. Single-value (use ModalitiesInStudy 0008,0061 for Study-level multi-modality queries).
Per-vendor source URLs and verification date in src/content/dicom/cloud-support.json#_meta.
Status taxonomy: required (mandated on Store), queryable (QIDO-RS matching key), preserved (stored as-is), promoted (AWS top-level metadata), unsupported (stripped/rejected).
Real-World Sample Values
-
CTCT_small.dcm -
MRMR_small.dcm -
USExplVR_BigEnd.dcm
Extracted from pydicom test fixtures (MIT, de-identified).
Mirth Connect Example
Modality-based channel routing — Common Mirth pattern: a single DICOM Reader feeds modality-specific downstream c
Common Mirth pattern: a single DICOM Reader feeds modality-specific downstream channels via routeMessage.
// (0008,0060) Modality — route to vendor-specific PACS channels
var modality = String(msg.dataset.attr.(@tag == '00080060').value).trim().toUpperCase();
var routes = {
'CT': 'CT_PACS',
'MR': 'MR_PACS',
'US': 'Ultrasound_VNA',
'NM': 'NM_PACS',
'CR': 'CR_PACS',
'DX': 'CR_PACS', // share with CR
'MG': 'Mammo_VNA'
};
var targetChannel = routes[modality];
if (targetChannel) {
router.routeMessageByChannelName(targetChannel, message.getRawData());
} else {
logger.warn('Unhandled modality: ' + modality);
} 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 Modality 'OT' (Other) instead of expected code
Diagnosis: Legacy modality emits Modality='OT' for everything. Downstream routing channels can't distinguish CT from MR from US.
Fix: Fall back to (0008,0016) SOP Class UID lookup — derive the modality from the Storage SOP Class. Maintain a SOP Class → Modality map in the channel's configurationMap.
-
medium Modality mismatch between SOP Class and (0008,0060) tag
Diagnosis: DICOM file has SOP Class = CT Image Storage but Modality = 'MR'. Often caused by a faulty modality conversion or operator override at the modality console.
Fix: QC check: in Mirth, fail-fast when the SOP Class's expected modality doesn't match (0008,0060). Route to quarantine + notify radiology IT.
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 Modality or the broader (0008,0060) context:
- Medical Imaging & DICOM Integration — end-to-end PACS, VNA, and cloud imaging deployments
- Mirth Connect Services — production-grade Mirth channel development
- Healthcare AI Integration — DICOM pipelines for AI/ML inference