Inferensys

Glossary

Burned-in PHI

Protected health information that is visually rendered directly into the pixel data of a medical image, such as a patient name burned into an ultrasound frame, requiring optical character recognition for detection.
Data scientist building training data pipeline on laptop, data preprocessing visible, technical workspace.
PIXEL-LEVEL IDENTIFIER

What is Burned-in PHI?

Burned-in PHI refers to protected health information that is visually rendered directly into the pixel data of a medical image, rather than stored as discrete metadata, requiring optical character recognition for detection and redaction.

Burned-in PHI is protected health information permanently fused into the image raster of a medical file, such as a patient name or MRN displayed on an ultrasound frame. Unlike DICOM header metadata, this text is part of the visual capture and cannot be removed by standard tag stripping, necessitating specialized optical character recognition (OCR) pipelines for HIPAA-compliant de-identification.

Common in modalities like ultrasound, endoscopy, and secondary capture images, burned-in PHI poses a significant residual PHI risk because conventional automated redaction tools often miss pixel-embedded identifiers. A robust DICOM de-identification workflow must combine metadata scrubbing with computer vision techniques to detect and redact these burned-in annotations before the image can be considered safely anonymized for research or sharing.

VISUAL DATA LEAKAGE

Key Characteristics of Burned-in PHI

Burned-in PHI represents a critical failure mode in medical de-identification pipelines where protected health information is rendered directly into the pixel data of an image, bypassing standard metadata-based redaction tools.

01

Pixel-Level Persistence

Unlike metadata tags that can be stripped programmatically, burned-in PHI is fused with the image pixels themselves. This text—such as a patient name or MRN overlaid on an ultrasound frame—becomes part of the rasterized image data. Removing it requires optical character recognition (OCR) followed by inpainting or black-box redaction, not simple header manipulation. The text has no machine-readable encoding; it exists only as a visual pattern of light and dark pixels.

Rasterized
Data Format
OCR Required
Detection Method
02

Common Modality Sources

Burned-in PHI is most prevalent in modalities that capture screen outputs or secondary captures:

  • Ultrasound: Sonographers frequently annotate frames with patient demographics directly on the screen before capture.
  • Endoscopy/PACS: Older Picture Archiving and Communication Systems often burned text overlays into exported secondary captures.
  • Mobile Photography: Clinicians taking photos of monitor screens for consults inadvertently capture overlaid patient banners.
  • Digitized Film: Scanned analog X-rays may have lead-letter annotations burned into the film emulsion.
03

Detection via OCR Pipelines

Automated detection requires a specialized computer vision pipeline distinct from standard text-based PHI detection:

  1. Region Proposal: Object detection models identify text-bearing regions within the image.
  2. Text Recognition: OCR engines transcribe the pixel-based text into machine-readable strings.
  3. PHI Classification: A downstream medical NER model classifies the transcribed strings against HIPAA Safe Harbor identifiers.
  4. Redaction: The identified pixel region is permanently obscured using black bars or Gaussian blur.
04

DICOM Header vs. Pixel Data

A critical distinction in medical imaging de-identification exists between DICOM metadata and pixel data. Standard DICOM de-identification tools excel at clearing tags like (0010,0010) Patient Name from the file header. However, they are blind to the same information if it appears visually within the pixel array (7FE0,0010). A fully compliant pipeline must address both vectors, ensuring the image is 'clean' both structurally and visually.

05

Secondary Capture Risk

The DICOM Secondary Capture Image Storage SOP Class is a high-risk source. These images are often screen grabs exported from a modality workstation, containing not just the medical image but the entire application chrome—including the patient banner, exam list, and status bar. De-identifying these requires cropping or redacting the non-diagnostic UI regions before release, a step frequently missed in automated workflows.

06

Validation and Quality Assurance

Verifying the absence of burned-in PHI cannot rely on metadata checks alone. A robust QA process includes:

  • Visual Spot-Checking: Manual review of a random sample of de-identified images.
  • Automated OCR Re-scan: Running the de-identified output through the detection pipeline again to confirm zero detections.
  • False Negative Audits: Specifically testing on images known to contain burned-in text to ensure the pipeline's recall is 100% for visual identifiers.
BURNED-IN PHI CLARIFIED

Frequently Asked Questions

Addressing the most common technical and compliance questions about protected health information that is visually rendered directly into the pixel data of medical images.

Burned-in PHI is protected health information that is visually rendered directly into the pixel data of a medical image, such as a patient's name, date of birth, or medical record number appearing as text within an ultrasound frame or X-ray. Unlike metadata PHI, which resides in structured DICOM header tags and can be removed programmatically, burned-in PHI is part of the image itself. This distinction is critical because standard DICOM de-identification tools that strip header tags will completely miss burned-in text, leaving the data fully identifiable and non-compliant with HIPAA Safe Harbor requirements. Detection requires optical character recognition (OCR) applied to every frame in a study, making it a computationally distinct and more complex challenge than metadata scrubbing.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.