Best Practices for Generating a Crosswalk During DICOM De-identification

[Ezequiel Gioia]

Hello,

I need guidance on creating a crosswalk for DICOM images processed with the Healthcare API’s de-identification feature. The goal is to allow controlled re-identification if needed. The crosswalk will be securely stored in the same GCP project, and the data owner understands and accepts the associated risk.

Current setup:

• I receive new DICOM images daily.
• Two DICOM stores:
  • One for original images.
  • One temporary store for de-identified images processed in batches. I delete all images on this store after each deidentification run. De-identified images are exported to Cloud Storage.
• I use the Cloud Storage filter feature to select subsets for de-identification on each run.

Challenge:
I want the Healthcare API to handle UID remapping (StudyInstanceUID, SeriesInstanceUID, SOPInstanceUID)—I do not want to generate UIDs myself. However, I also need a reliable way to build a crosswalk between original and de-identified instances for each batch.

Questions:

• Does the API provide any mechanism or configuration to return a mapping of original to new UIDs?
• If not, what are the recommended best practices for maintaining referential integrity and generating this mapping without manually generating UIDs?

Any advice or patterns you’ve seen work well would be greatly appreciated.

Thank you

[Truc Le]

Hello,

Yes, our API provides operation metadata (represented as FHIR) to keep track of de-identification details, including a mapping of original to new UIDs.

Best,

Truc