You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.py → DeidentifyStep(PipelineStep),
registered as "deidentify"; runs afteringest, 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.
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
preprocessstep mentions "Anonymize" in the README diagram butthere is no actual de-identification implementation.
Why (research-backed)
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.
truly anonymizing brain scans may require defacing — relevant under GDPR
(special-category data; pseudonymized ≠ anonymized) and German BDSG §22/§27.
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
src/medcheck/pipeline/deidentify.py→DeidentifyStep(PipelineStep),registered as
"deidentify"; runs afteringest, before anything thatlogs/transmits (especially before
vision_analysis's external path).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.
ocrextra) and redact bounding boxes; honor/repair theBurnedInAnnotationtag but don't trust it. Default to flag + warn if OCR isn't installed.
an optional extra; off by default, on for detected head studies when enabled.
the text too (NLP/regex pass).
Design constraints
but cannot complete (e.g. OCR missing on a study with suspected burned-in PHI),
the external-LLM path must refuse to transmit rather than leak — tie into the
[repo-monitor] High: Patient PHI/DICOM data transmitted to external LLM APIs without consent controls #27 consent gate.
Acceptance criteria
DeidentifyStepregistered; removes/replaces the PS3.15 tag set; consistentUID remapping.
warn-and-block behavior when it isn't and transmission is requested.
not-de-identified data.
detection on a fixture with rendered text (mocked OCR ok); fail-safe path.
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).