Skip to content

Add robust DICOM de-identification step (tag scrubbing + burned-in PHI + optional defacing) #57

Description

@Liohtml

Part of #51. Foundational privacy stage — a prerequisite for safely sharing,
logging, or (optionally) sending any imaging data externally.

Summary

Add an optional but strongly-recommended pipeline step that de-identifies
DICOM data: (1) header tag scrubbing per the DICOM standard, (2) burned-in
pixel PHI
detection/redaction, and (3) optional defacing of head MRI/CT.
The current preprocess step mentions "Anonymize" in the README diagram but
there is no actual de-identification implementation.

Why (research-backed)

  • Header scrubbing alone is insufficient. DICOM images frequently contain
    burned-in PHI — patient name/MRN/DOB rendered into the pixels (common on
    ultrasound, secondary captures, dose sheets, some MR/CT). Removing DICOM tags
    does not touch pixels; a separate pixel-level pass (OCR/vision or manual
    review) is required. Confirmed against primary de-id literature + TCIA/MD.ai docs.
  • Head MRI/CT can be facially re-identifiable (3D facial reconstruction), so
    truly anonymizing brain scans may require defacing — relevant under GDPR
    (special-category data; pseudonymized ≠ anonymized) and German BDSG §22/§27.
  • Legal framing: when a patient self-uploads their own scan, US HIPAA often
    doesn't apply, but the FTC Health Breach Notification Rule (2024) does, and
    EU GDPR Art. 9 applies the moment the app processes the data. De-identification
    is the core technical safeguard that makes logging, caching, second-opinion
    sharing, and any external LLM call defensible. Pairs with the consent gate ([repo-monitor] High: Patient PHI/DICOM data transmitted to external LLM APIs without consent controls #27)
    already merged.

Proposed implementation

  • New file src/medcheck/pipeline/deidentify.pyDeidentifyStep(PipelineStep),
    registered as "deidentify"; runs after ingest, before anything that
    logs/transmits (especially before vision_analysis's external path).
  • Tag scrubbing: implement against the DICOM PS3.15 Basic Application Level
    Confidentiality Profile
    (+ options: Retain Longitudinal Temporal as config,
    Clean Descriptors). Remove/replace the HIPAA Safe-Harbor-relevant tags (names,
    dates→year, IDs, device serials, institution, private tags, UIDs re-mapped
    consistently). Evaluate reusing a maintained library (e.g. dicognito, MIT)
    vs. a hand-rolled tag list.
  • Burned-in PHI: detect text in pixel data (lightweight OCR behind an optional
    ocr extra) and redact bounding boxes; honor/repair the BurnedInAnnotation
    tag but don't trust it. Default to flag + warn if OCR isn't installed.
  • Defacing (optional): integrate an Apache/MIT defacer for head MRI/CT behind
    an optional extra; off by default, on for detected head studies when enabled.
  • Free-text: if a report is ingested (see reconciliation Add report reconciliation: compare official radiologist report against image analysis #58), scrub PHI from
    the text too (NLP/regex pass).

Design constraints

Acceptance criteria

  • DeidentifyStep registered; removes/replaces the PS3.15 tag set; consistent
    UID remapping.
  • Burned-in PHI: OCR-based redaction when the extra is installed; clear
    warn-and-block behavior when it isn't and transmission is requested.
  • Optional defacing for head studies behind an extra.
  • Integrates with the [repo-monitor] High: Patient PHI/DICOM data transmitted to external LLM APIs without consent controls #27 consent gate: no external transmission of
    not-de-identified data.
  • Tests: tag removal on a synthetic dataset; UID consistency; burned-in
    detection on a fixture with rendered text (mocked OCR ok); fail-safe path.
  • Docs: what is/isn't removed, GDPR/HIPAA/FTC framing, limitations.

Effort

~2–3 days (tag scrubbing first; OCR + defacing as follow-ons). Optional heavy deps.

References (session research)

DICOM PS3.15 confidentiality profiles; HIPAA Safe Harbor (45 CFR §164.514);
burned-in PHI de-id literature (PMC11522224); GDPR Art. 9 / German BDSG §22,§27;
FTC Health Breach Notification Rule (2024).

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions