Imaging SOP

[edilbertoamorim]

Hi folks: hoping to cluster discussions about imaging standards here.

[edilbertoamorim]

Meeting about imaging deidentification Thursday 11AM EST.

Some of the agenda points (feel free to add)

1. Physionet imaging deidentification pipeline - Tom

2. Current algorithms being tested by CHORUS group – Xiang

   • header de-identification (open-source tools/libraries)
   • pixel burned redacting (open-source tools/libraries)

3. Future OMOP integration: potential barriers

4. Central identifier mapping vs local identifiers mapping and where should Tooling build the pipeline in and with what logic?

5. Datetime in UTC: discussion

6. File transfer strategy, especially sites with no Azure tenant.

7. Knowledge on what sites can produce what type of images and does sites need to have sampling strategy in place ahead of image data extraction.

Zoom info:

Eddy Amorim - UCSF [he/him/his] is inviting you to a scheduled Zoom meeting.
Meeting ID: 953 3952 1733
Password: 822578
Phone or Conference room password: 822578
---
One Click Join from a PC, Mac, Linux, iOS or Android device:
https://ucsf.zoom.us/j/95339521733?pwd=d1pjYjhsbndnZGpaWGgvYXR3YzdWdz09&from=addon
---
One tap mobile (iPhone)
[+16692192599,,95339521733#,,,,1#,,822578#](tel:+16692192599,,95339521733#,,,,1#,,822578#) US (San Jose)
[+16699006833,,95339521733#,,,,1#,,822578#](tel:+16699006833,,95339521733#,,,,1#,,822578#) US (San Jose)
---
Dial by your location
[+1 669 219 2599](tel:+16692192599) US (San Jose)
[+1 669 900 6833](tel:+16699006833) US (San Jose)
[+1 213 338 8477](tel:+12133388477) US (Los Angeles)
000 800 050 5050 India Toll-free
000 800 001 4002 India Toll-free
[+52 554 161 4288](tel:+525541614288) Mexico
1800 062 2403 Mexico Toll-free
Meeting ID: 953 3952 1733
Password: 822578
---
Connecting from a room system:
IP: 162.255.37.11
SIP: [[email protected]](mailto:[email protected])
Meeting ID: 953 3952 1733
Password: 822578
---
UCSF Zoom instance is approved for use with restricted data.

For more information on Zoom:
https://it.ucsf.edu/services/zoom-web-conferencing

[edilbertoamorim]

#BIDMC/MIMIC Physionet call 9/28/2023

#Images DEID

1. adding blocks to the parts of the image that have PHI burnt in (need to know the vendor to know where to block usually); MIMIC team received images with things blocked from radiology already
2. OCR
3. CNN
4. AWS-BOTo3
   *https://github.com/aws-samples/amazon-comprehend-medical-image-deidentification

#Header DEID
4) PyDICOM - MIMIC team ahs codes for PHI removal
5) PRESIDIO

#Defacing

• needs to identify methods; Eddy has done skull stripping in images; some automated tools from Martinos for MRI

ID mapping

• look into N3C: assigned centrally; cannot replicate as multiple types of data
• likely better to be done locally; define standards for CHORUS

Data Transfer services
*https://www.globus.org/data-transfer

[edilbertoamorim]

[del42]

2. A series and instance is not being modified in central but person_id is.
3. A time shift should be resolved within the site. If you have de-identified OMOP and identified images. You have to request their offset from UCSF CDW.

[briangow]

Regarding the length of a deid UID. We took the approach of creating the deid UID as MIT_ID.LCP_ID.MIMIC_ID.TAG_ID.SHA512_derived_hash. We cut the SHA512_derived_hash down to 39 numbers. In our case this left us with a 62 byte UID, leaving 2 bytes for future expansion if needed.

Also, in case it hasn't been made clear in the guideline, 1.2.840.113554, is the registered MIT_ID not a CHORUS_ID.

[heschmidt04]

Hi Eddie,

To help answer question number 3

• From what I understand - Del is writing a Python script (referred to as a trigger) to sense the load to the Azure Blob Storage (ADLS) is complete by a CHoRUS site.
• That Azure data load into each site/person_id folder will have an omop_table sub folder with data for all the OMOP tables per target folder structure
• Folks came to agreement that the Python script will load the OMOP database data from each site as it is into a staging database schema for that site.
• From that point the generation of a new set of ids for each patients data that is in the Azure Blob folder structure under their site/person_id will be created as part of process of appending that data into the final CHoRUS OMOP central database.
• During that database data load process or after, I am suggesting we write relevant information that we'd need to identify or track the any of the data loaded to Azure (database data, image data, etc.)
• We could come up with the data provenance for the images & waveforms (timestamp generated, checksum, image type specifics, etc) and a file format for the data (CSV, JSON, YAML, etc) along with a location for the data to live (in a database table, or in a Azure Blob ADLS file in a folder - for two examples)

My High level understanding (assumptions) for OMOP EHR data at MGB

• All the OMOP id columns are integers and can't store GUID's or UUID's
• All the OMOP table columns that have source_value as a suffix are minimum varchar(50) and some of those could possibly be used to indicate some relationship back to source data, or contain some sort of data provenance - for example we at MGB talked about putting the string bedmaster into modifier_source_value column for OMOP table procedure_occurrence
• MGB is not using any EHR patient ids, encounter ids, or medical record numbers for any of its IDs or source_value columns.
• No modifications have been made to CHoRUS OMOP central database tables, yet and therefore no modifications need to be in the location where the MGB ELT is being done to get MGB EHR data de-identified with no PII/PHI into OMOP tables before being written out into CSV files to load into CHoRUS OMOP central database. Any by product or raw tables are for the ELT process and can be made reference or historical - they have nothing to do with the final CSV output to be transferred to Azure Blob storage (ADLS)
• DICOM images that have been de-identified sofar, all have a new random name associated with them with .dcm file extension and no data provenance included in the DICOM filename relating to OMOP ids, checksums, or other data provenance.

[edilbertoamorim]

From the call today with tools (1/2/24):

imaging data deidentification

1. Local processing - Potential issues
   [ ] how OHDSI information will be linked to image file? Right now, patient ID will be used in file name – this process will not be covered by COMPASS, so each site will have to modify file names posthoc with a custom script.

[ ] how to link individual imaging tests to imaging reports in OHDSI? We would need to link a procedure ID to each test. That is generally done via accession number in the DICOM header, however that will be removed by COMPASS. It is not clear how the procedure ID will be linked to the image test – perhaps this could go into

[ ] there is other metadata in the header being removed by COMPASS, so figuring out how we may move things back into some table will be helpful

2. Central processing - Potential issues
   [ ] DICOM ID registration: which group should pursue the CHORUS specific DICOM code? I am happy to submit it but was not sure if there are any specifics to consider.

3. Header metadata
   [ ] concept mapping => I anticipate this will take some time to get set up

[ ] RSNA code to OMOP concept_id mapping: is that a strategy to be considered

[edilbertoamorim]

Pydicom VS COMPASS:

Th eother topic that came up in the call today was the decision for COMPASS vs Pydicom. We are happy to use whatever the tools group decide is best. Open source has advantages but there is experience at MGH with COMPASS already, so there are pros and cons.

[briangow]

Thanks @edilbertoamorim !

Based on what was discussed in the call yesterday and what you've highlighted above I see some of the cons of going with COMPASS as:

• we have to pay for licenses.
• we have to move those licenses between sites and deploy COMPASS at the sites.
• we don't have full control over COMPASS. There are things that it removes (Accession Number) which we may want to keep. We can't modify/add metadata as we'd like.

If my last bullet is accurate I'm a bit concerned with the choice to go with COMPASS. In working with echocardiogram DICOMs I feel that I needed to have full control over what every metadata field contained and whether it was removed. Can we use a custom CHoRUS UID root with COMPASS?

In terms of making a decision on this, I think it'd also be helpful to have a list of advantages to using COMPASS. It sounds like one of the sites has familiarity with COMPASS but other sites have familiarity with Pydicom (and potentially other tools). Does COMPASS make de-identifying DICOMs easier to do for sites that don't have technical staff available to remove the PHI before sending it to central?

[del42]

Just want to add that asking some institutes to ask permission to deploy the Compass is going to be hassle from the IT Risk Security perspective. At Emory, third party paid tools have harder time going through IT Risk Security Assessment than open-source tools. Since it is closed system, they go too much in details how they handle data, etc.

[heschmidt04]

I let Ciera know this Github discussion side bar on Compass so we all can be proactive on logistics questions and concerns to make sure she is in the loop.

[CmCC1435]

So when discussing with COMPASS there has been past projects when they have created licenses to move/deploy between sites. This might be something we need to determine further if IT determines if it is too much of a risk but it sounded like there has been success cases before.

From our discussions we would have full control of COMPASS. We are having more discussions to confirm price and can go deeper but when we initially had the discussion around creating these deploy-able licenses we would have full control.

The main benefit that we saw was that it made things easier fro sites that do not have the technical staff who may know python or can come up to speed as fast with Pydicom. Xiang did a presentation on COMPASS a few months back that I can see about him sending around about the advantages and MGH has a test package right now that we plan on working with soon on our images which we can then show how it went.

[CmCC1435]

Just an update on this discussion, Eric, Xiang, Kevin, and I had a meeting yesterday just on some internal discussion more on Xiang's lab working between COMPASS and Pydicom. I can let Xiang discuss more on what he things but just want to let everyone know COMPASS is not officially decided.

[edilbertoamorim]

Hi

Regarding OMOP & DEID tool integration

It will be important to link the deid tool to the OMOP procedures. I think we need the accession number from the headers as we can link that to the procedure orders in the EHR. Other things

Must haves
A timestamp associated with the data capture
A link – either through something like an ADT bed lookup or direct MRN – to the associated patient => could be accession number in addition
A high-level description of the data capture method (e.g. CT, X-Ray, Echo, etc.)

Nice-to-haves would be:
A link to a specific encounter entity already included in OMOP (this can be inferred using 1.a and 1.b if not directly available)
A specific description of the data capture method (e.g. CT of prostate for radiotherapy planning)
An associated anatomic site (e.g. prostate)
Device information (e.g. GE Lightspeed VCT 64)
…

[edilbertoamorim]

I wanted to sync with you on the imaging deidentification pipeline. I am cc’ing Heidi and Jared given the OMOP integration that would be needed for the DEID tool (point 2 and 3 below). I am posting this in github for visibility, but I know not everyone here is using github yet, hence the email.

We had discussed that pydicom would be the likely method forward for image DEID given the MIT/MGB/Emory experience with it, but, next week, we will be connecting with the NIH and UVa team about CTP vs. pydicom pros and cons.

1. pydicom
   I understand that Xiang had added some of the pydicom recipe information from the MIT group to his code, but we also had some new items from Hari’s group at Emory that we may consider adding. I wanted to ask the group what would be the best method to collaborate on the recipe plan if we go the pydicom route. I will defer to Xiang as the tool lead on how he would prefer to do that.

2. OMOP sync to images
   We need code that reads the OMOP data from the tables and makes that available to the DEID code. This would require collaboration from the teams with expertise in OMOP and imaging data.

3. Metadata storage for future OMOP work
   The original data being removed or changed in the metadata will need to be saved in a table to be kept locally at each site. We would need to define how that should look like so in the future further omopification of the imaging metadata can be done.

@jared: I reviewed the image registry, and that is using procedure_occurrence_id and not the accession number (image_occurrence_id), so it would be good to touch base on this.
https://github.com/chorus-ai/MIMIC

Other points

#OMOP Intake Table for DICOM DEID

We need to prepare a table that includes OMOP mapping for certain variables. This table will be used by the DEID tool to replace fields that will allow linkake between OMOP and DICOM data.

• Time shift
• MRN mapping for person_id
• Accession number mapping for image_occurrence_id

DEID tool

DICOM Metadata field replacements

In our imaging-standards call few weeks ago we had these operations planned (this might have changed since then):

• MRN => person_id
• Accession number => image_occurrence_id [now perhaps procedure_id]
• Date => apply time shift from OMOP
• Modality Attribute => DICOM-defined value

DEID Output: DICOM Metadata Lookup table

• Metadata that has been erased, replaced, deidentified, or shifted should be stored in a table

Other Questions

1. In what format should the remaining DICOM metadata being erased or transformed be kept?
2. If we strip the remaining metadata out of the DICOM header, how can we ensure is readable in DICOM viewers? Is there a DICOM readability test code?
3. What is the difference between procedure_occurrence_id and image_occurrence_id?
4. What to do with private tags? (e.g., erase vs store in separate table)
5. Secondary capture + pixel removal: what would be the timing for these tools becoming available?
6. CHORUS UID: is that necessary?
   https://www.iana.org/assignments/enterprise-numbers/
   https://www.iana.org/assignments/enterprise-numbers/assignment/apply/

[edilbertoamorim]

Discussion poitns from call on 3/13/2024

Questions for the group => discussion points:

Metadata DEID

1. Is CTP customizable? In other words, we need to use OMOP IDs and OMOP date shifts plus DEID accession numbers for each scan, how would we integrate that to the CTP pipeline? => Participants were not sure.
2. What are the advantages of CTP compared to the custom python strategy? => It is widely used by the community; there may be other things we were not sure.

Pixel DEID & 3rd party company

3. If we have our customized metadata DEID solution, do we need to set up a contract with a private company? => people thought that our own customizable solution may be very labor intensive. This would need GPU and that can get expensive.
4. Global solution: do we need to set up a contract with a private company that would do both metadata and pixel deidentification? What could be done centrally (MGB cloud) vs local (each site setup)? => It may not add much to have both done if we decide that support from a third party is needed?

DEID expert review

5. Expert review of DEID performance: How are we budgeting for that? Could that be done centrally at MGB cloud? =>Depending on a 3rd party solution, a viewer may be provided. Homegrown solutions may not have good viewers built in. Central review may expedite things.
6. What will be the procedures and best practices for expert review? => TBD

[edilbertoamorim]

Imaging follow-up questions about DEID

Database table from PACS:
Is there something like that available on your site?
Are you able to access that for the CHORUS cohort?

Are you able to get raw DICOM images?
If not raw, what modifications would happen in the DICOM file before they are released?
Would your site be willing to provide you with “untouched” DICOM files?
Would your site allow you to use a CHORUS DEID tool on raw images and then share those images?

What data quality checks for deidentification your site will ask you to do?
How do you plan on doing it?
Is a visualization tool needed for you to do that?
Could that be done centrally at MGB Azure?

Is pixel deidentification necessary for data release to CHORUS?
If it is, how do you plan on doing it?

Is defacing necessary for data release to CHORUS?
If it is, how do you plan on doing it?

Do you have personnel with expertise to run a CHORUS DEID script on your site?
If not, what type of help would you need?