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.
Glossary
Burned-in PHI

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.
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.
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.
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.
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.
Detection via OCR Pipelines
Automated detection requires a specialized computer vision pipeline distinct from standard text-based PHI detection:
- Region Proposal: Object detection models identify text-bearing regions within the image.
- Text Recognition: OCR engines transcribe the pixel-based text into machine-readable strings.
- PHI Classification: A downstream medical NER model classifies the transcribed strings against HIPAA Safe Harbor identifiers.
- Redaction: The identified pixel region is permanently obscured using black bars or Gaussian blur.
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.
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.
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.
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.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Understanding burned-in PHI requires familiarity with the detection techniques, imaging standards, and privacy frameworks that govern its removal. These related concepts form the operational backbone of clinical de-identification pipelines.
Optical Character Recognition (OCR) in Medical Imaging
The foundational technology for detecting burned-in PHI embedded in pixel data. Unlike metadata extraction, OCR processes the visual frame buffer of modalities like ultrasound, endoscopy, and nuclear medicine to locate and transcribe text rendered directly into the image. Modern clinical pipelines use deep learning-enhanced OCR to handle challenges unique to medical imagery:
- Low contrast text: White text on grayscale anatomical backgrounds
- Non-standard fonts: Proprietary typefaces from legacy modality workstations
- Multi-orientation text: Rotated annotations on lateral or oblique views
- Overlay interference: Text partially obscured by anatomical structures or measurement calipers
Post-OCR, detected text strings are fed into PHI detection models to classify whether the recognized characters constitute protected identifiers before redaction.
Pixel Data vs. Metadata PHI
A critical distinction in medical image de-identification that determines the technical approach required:
Metadata PHI resides in structured DICOM header fields and is detectable through tag-level parsing. Examples include the PatientName, PatientID, and InstitutionName attributes. Removal is deterministic and rule-based.
Pixel Data PHI (burned-in) is visually rendered into the image itself during acquisition. Common sources:
- Ultrasound machines that overlay patient demographics on each frame
- Ophthalmology devices that burn identifiers into fundus images
- Endoscopy video with timestamp and patient ID overlays
- Secondary capture images that photograph original films containing labels
Detection requires computer vision pipelines operating on the raw pixel buffer, making it computationally more intensive than metadata scrubbing.
False Negative Rate in De-identification
The proportion of actual PHI instances that a detection model incorrectly classifies as non-sensitive, representing a direct measure of privacy leakage in a de-identification system. For burned-in PHI, false negatives are particularly dangerous because:
- A single missed instance of a patient name in an ultrasound frame can constitute a HIPAA breach if the image is released for research
- Burned-in text often appears in unpredictable locations across different modality vendors
- Low-contrast overlays may be invisible to human reviewers but recoverable through image enhancement
Mitigation strategies:
- Dual-pass detection: Combining OCR-based text recognition with direct visual object detection of text regions
- Confidence thresholding: Routing low-confidence frames to human-in-the-loop review
- Adversarial testing: Deliberately crafting images with subtle burned-in PHI to stress-test detection pipelines
Hybrid De-identification Pipeline
A system architecture that combines deterministic rule-based redaction with probabilistic machine learning models to maximize both precision and recall of PHI detection across all modalities.
For burned-in PHI specifically, the hybrid approach layers:
- Heuristic pre-processing: Detecting known modality-specific overlay patterns (e.g., Siemens ultrasound footer format)
- OCR text extraction: Running multiple OCR engines in parallel with voting mechanisms
- NER-based PHI classification: Applying medical named entity recognition to distinguish patient names from anatomical labels
- Visual region proposal: Using object detection models to locate text bounding boxes independently of OCR
- Consensus scoring: Combining confidence scores across all detection layers before redaction or human review routing
This defense-in-depth strategy ensures that PHI missed by one layer is caught by another, minimizing residual risk.
Residual PHI Risk Assessment
The remaining probability that protected health information persists in a dataset after an automated de-identification pipeline has been executed. For burned-in PHI, residual risk assessment must account for:
- Vendor-specific overlay formats: Proprietary text placement that may not appear in training data
- Image degradation: Compression artifacts that degrade OCR accuracy in transmitted images
- Multi-frame instances: DICOM objects containing dozens or hundreds of frames where burned-in text may appear intermittently
- Annotation text: Physician-added measurements or labels that inadvertently include identifying information
Formal risk assessment methodologies:
- Stratified sampling across modality types and device manufacturers
- Red-team penetration testing using manual reviewers to hunt for missed identifiers
- Statistical extrapolation from false negative rates measured on ground-truth annotated test sets

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.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us