Skip to main content

MS MRI Workflow

For a large multiple sclerosis MRI dataset, dicomqc should be the audit layer on top of a pseudonymization/de-identification workflow. It should not be the tool that edits the only copy of the study.

raw_mri/
    |
    | 1. archive read-only
    v
pseudonymization / de-identification pipeline
    |
    | 2. external tool writes pseudonymized DICOM files
    v
candidate_release_mri/
    |
    | 3. dicomqc reads metadata only
    v
reports/
    |
    | 4. fix findings and rerun
    v
release_candidate/
project/
  raw_mri/                 # immutable source copy; restricted access
  work/
    candidate_release_mri/ # pseudonymized .dcm output
  maps/
    pseudonym_map.tsv.gpg  # protected; never shipped with released data
  reports/
    dicomqc/
      report.json
      findings.csv
      dicomqc_mqc/

For this MS MRI project, the likely model is pseudonymization rather than full anonymization: the data provider may keep a linkage file that maps source identifiers to research pseudonyms. That linkage file is operationally necessary, but it is sensitive. Keep it on the provider side, outside the released dataset, outside public repositories, and under a separate access policy.

The preferred data shape is DICOM-in and DICOM-out: raw .dcm files are the input, and pseudonymized .dcm files are the output. Conversion to NIfTI or BIDS can happen later, after the DICOM release candidate has passed metadata audit.

Step 1: inventory and preserve the raw data​

Make the raw dataset immutable from the pipeline's point of view. dicomqc can be run on raw data for internal risk discovery, but raw reports may still reveal risk patterns through paths or tag presence, so keep them restricted.

dicomqc scan raw_mri/ \
  --json reports/dicomqc/raw-risk-inventory.json \
  --csv reports/dicomqc/raw-risk-findings.csv

Step 2: pseudonymize and de-identify with an external tool​

Use a controlled pseudonymization/de-identification workflow to create candidate_release_mri/ as DICOM files. Possible options include:

  • DCMTK commands such as dcmodify for targeted metadata edits
  • Orthanc de-identification routes if the site already uses Orthanc
  • XNAT anonymization or pseudonymization scripts if the site already manages DICOM through XNAT
  • a validated institutional de-identification pipeline
  • a project-specific pydicom script maintained outside dicomqc

For this project, the pseudonymization/de-identification workflow should at minimum address:

  • direct subject identifiers
  • accession and clinical workflow identifiers
  • dates, according to the release policy
  • site and institution identifiers
  • operator and physician names
  • private/vendor tags
  • protocol names that may contain subject, site, or study information
  • pseudonym consistency across subject, visit, study, and series

Step 3: run dicomqc as the release gate​

Run dicomqc on the pseudonymized .dcm output:

dicomqc scan work/candidate_release_mri/ \
  --json reports/dicomqc/report.json \
  --csv reports/dicomqc/findings.csv \
  --multiqc reports/dicomqc/dicomqc_mqc

Interpret the result:

  • exit code 0: metadata checks passed
  • exit code 1: warnings need review
  • exit code 2: errors or unreadable files block release

Step 4: remediate findings and rerun​

Use the report recommendations to update the pseudonymization/de-identification workflow, not just one file by hand. Then regenerate the candidate release and rerun dicomqc.

The goal is a reproducible pipeline:

same raw input + same pseudonymization policy -> same dicomqc result

MRI-specific privacy risks​

dicomqc v0.1 audits metadata. It does not inspect pixel data and does not deface brain MRI volumes.

For head MRI, de-identification may also require image-level handling such as defacing, skull stripping, or another approved facial-feature protection method, depending on the release policy and downstream analysis needs.

If the dataset will be converted to BIDS, keep dicomqc as a pre-conversion metadata audit and then run BIDS-specific validation on the converted dataset. The BIDS MRI specification includes de-identification information and defacing mask concepts, so those checks should become a future dicomqc/BIDS profile rather than an implicit v0.1 claim.

Release checklist​

Before sharing the MS MRI dataset, require:

  • raw data preserved under restricted access
  • candidate release generated by a reproducible pseudonymization/de-identification workflow
  • pseudonym linkage map retained by the provider, stored separately, and protected
  • dicomqc JSON, CSV, and MultiQC reports archived
  • errors resolved
  • warnings reviewed and signed off
  • private-tag handling documented
  • pixel/facial de-identification handled by an appropriate imaging workflow
  • final release reviewed under the institutional data-sharing policy