DICOM Attribute
Manufacturer (0008,0070)
- Keyword
Manufacturer- VR
LO- VM
1
Definition
Manufacturer of the equipment that produced the Composite Instances.
From NEMA PS3.3 §C.7.5.1.
Attribute Metadata
This attribute is part of the current DICOM Standard. Its value representation is LO with multiplicity 1.
Used in 10 Modules
Value Representation
This attribute uses the LO
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.
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
-
n/a(no HL7 v2 equivalent)Manufacturer is set by the modality from its own configuration; HL7 v2 has no field that conveys imaging equipment manufacturer.
Source: common convention
Verify against IHE Radiology TF Vol 2 and your facility's interface specification before production use.
Cloud DICOM Support
- AWS HealthImaging Preserved
- Azure DICOM Preserved
- Google Cloud Healthcare Preserved
Manufacturer — preserved by all three. Relevant for vendor-specific compatibility checks.
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
-
GE MEDICAL SYSTEMSCT_small.dcm -
TOSHIBA_MECMR_small.dcm -
G.E. Medical SystemsExplVR_BigEnd.dcm
Extracted from pydicom test fixtures (MIT, de-identified).
Mirth Connect Example
Manufacturer-specific quirk dispatcher — Different scanner vendors emit DICOM with vendor-specific quirks (private tag co
Different scanner vendors emit DICOM with vendor-specific quirks (private tag conventions, character set differences). Apply per-vendor patches in a dedicated transformer.
// (0008,0070) Manufacturer — branch on vendor for quirk handling
var mfr = String(msg.dataset.attr.(@tag == '00080070').value).trim().toUpperCase();
if (mfr.indexOf('GE') === 0 || mfr.indexOf('G.E') === 0) {
channelMap.put('vendor_quirk', 'GE');
// GE scanners may emit private tags 0009,xxxx — preserve
} else if (mfr.indexOf('SIEMENS') >= 0) {
channelMap.put('vendor_quirk', 'SIEMENS');
// Siemens uses 0029,xxxx for CSA headers
} else if (mfr.indexOf('PHILIPS') >= 0 || mfr.indexOf('TOSHIBA') >= 0 || mfr.indexOf('CANON') >= 0) {
channelMap.put('vendor_quirk', mfr.split(/\s+/)[0]);
} 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
-
low Manufacturer name varies across same vendor's modalities
Diagnosis: Same vendor's CT and MR scanners report Manufacturer differently — 'GE MEDICAL SYSTEMS' vs 'G.E. Medical Systems' vs 'GE'. Vendor-specific quirk handlers don't fire when matching is exact-string.
Fix: Normalize to a canonical form on perimeter: uppercase, strip non-alpha, prefix-match on known vendor stems. Mirth lookup: `if (mfr.toUpperCase().indexOf('GE') === 0) vendor = 'GE'`.
-
low Manufacturer spelling variations break vendor-specific workflows
Diagnosis: Sites that need vendor-specific handling (e.g., GE vs Siemens CT reconstruction kernels) match on (0008,0070) Manufacturer. Different modalities from the same vendor can emit 'GE MEDICAL SYSTEMS', 'GE Medical Systems', 'GE', 'General Electric' across firmware versions. Regex-based routing misses some.
Fix: Normalize manufacturer at ingress with a vendor alias map (JSON lookup of canonical names keyed by common variants). Refresh map when new modality models are acquired.
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 Manufacturer or the broader (0008,0070) 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