DICOM Attribute

Pixel Data (7FE0,0010)

Keyword
PixelData
VR
OB or OW
VM
1

Definition

A data stream of the pixel samples that comprise the Image. See for further explanation. Required if Pixel Data Provider URL (0028,7FE0) is not present.

From NEMA PS3.3 §C.7.6.3.

Attribute Metadata

Tag
(7FE0,0010)
Keyword
PixelData
Name
Pixel Data
Value Representation (VR)
OB or OW
Value Multiplicity (VM)
1
Status
Active
Source
NEMA PS3.6 (table_6-1)

This attribute is part of the current DICOM Standard. Its value representation is OB or OW with multiplicity 1.

Used in 1 Module

This attribute uses the OB or OW 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

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 Preserved
  • Azure DICOM Preserved
  • Google Cloud Healthcare Preserved

Pixel Data is preserved on Store. AWS HealthImaging additionally separates pixel data into the ImageFrame storage tier for cost-optimized retrieval. WADO-RS bulk-data semantics apply on all three.

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

No representative sample value available — this attribute isn't present in the de-identified pydicom fixture set. Add a fixture covering this attribute to expand coverage.

Mirth Connect Example

Strip PixelData when forwarding metadata-only to FHIR ImagingStudy — When generating a FHIR ImagingStudy resource that references the DICOM via WADO-

When generating a FHIR ImagingStudy resource that references the DICOM via WADO-RS endpoint, you want metadata only — keep payload size manageable.

// (7FE0,0010) Pixel Data — exclude from outbound metadata-only forward
// In a Mirth source-to-destination flow building a FHIR resource:
var metadata = msg.copy();
// E4X delete pixel data attribute
delete metadata.dataset.attr.(@tag == '7FE00010');
channelMap.put('metadata_only_size', String(metadata.toString().length));
return metadata;

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

  • high Pixel Data corruption from JPEG 2000 transcoding

    Diagnosis: Mirth or upstream gateway transcodes JPEG 2000 Lossless to Implicit VR Little Endian (uncompressed) for compatibility. Result: PixelData length doesn't match expected uncompressed bytes due to incorrect padding handling.

    Fix: Use a battle-tested DICOM library (dcm4che, pixelmed) for transcoding rather than rolling your own. Validate the output by computing expected uncompressed length (Rows × Columns × Frames × BitsAllocated/8 × SamplesPerPixel) and comparing.

  • high PixelData length doesn't match Rows × Columns × BitsAllocated × SamplesPerPixel / 8

    Diagnosis: Calculated expected pixel data size (e.g., 512 rows × 512 cols × 16 bits × 1 sample / 8 = 524,288 bytes) doesn't match actual PixelData length. Indicates frame count mismatch (multi-frame), truncation during transmission, or a padding-byte bug in the modality's encoder.

    Fix: At ingress, compute the expected bulk-data size from the header fields and compare against actual PixelData length. If multi-frame, multiply by NumberOfFrames. Log deviations and route to QC rather than silently storing corrupt bytes.

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 PixelData or the broader (7FE0,0010) context: