Design the API of the project

[sapetnioc]

We must discuss, define and document the expected behavior of the project. Both for the library part and for the script part.

[sapetnioc]

Is there someone that do not agree with some of the following statements ?

• The goal of this project is to make it easy to propose a deidentification service that must be usable by non specialists.
• DICOM is a major part of this project but deidentification is not limited to it. For instance removing path internally stored in GZip format of a *.nii.gz file is in the scope of this project.
• It is necessary to rename input files into deidentified path.
• This project could associate deidentified metadata to each input item (such as a subject code, an imaging session name, etc.) and use this metadata to build an output file name.
• We could use BIDS for the definition of the metadata we want to associate to each item. Thus, the metadata for a file would be values for sub, ses, ack, run, etc.
• We could use BIDS to automatically build an output path for each item given its metadata
• The deidentification API could involve the following steps:
  1. Parse input files and identify input items with their file(s) and identified metadata (patient name, sessions, etc.)
  2. Create a deidentification file associating input items to deidentified BIDS metadata. The force of the project would be to have the possibility to automatize this step given deidentified subject codes and using CATI knowledge about acquisitions.
  3. Give the possibility to the user to modify the deidentification file by editing the generated metadata. This may be necessary to handle all cases that cannot be done automatically.
  4. Use the translation file to perform the deidentification and create a BIDS-like directory. This will not be a valid BIDS directory because there will not be any conversion to NIFTI here, we will store DICOM files (this is not supported by BIDS, AFAIK).

[Hboni]

These first ideas sound good for me. But I have some question/suggestion :

• Do we limit this project to neuroimaging data or medical images in general? I think that because of our data, we can limit to neuro, but the principle could be the same for other imaging?

The goal of this project is to make it easy to propose a deidentification service that must be usable by non specialists.

• So I'm wondering if you thinking about adding a user interface around the API?
• I know that we can find header infos in nifti format, I didn't use much, but do you think that some deidentification can be necessary for this header too?

It is necessary to rename input files into deidentified path.

• In case of filename without any specific information in it, can we have the possibility to deidentify and erase the old one?

• I'm not sure if I understand all the API step, your idea is to first create a metadata file from the DICOM. This metadata could be modified before the deidentification step? So for the user, it would be 2 steps?

[sapetnioc]

These first ideas sound good for me. But I have some question/suggestion :

* Do we limit this project to neuroimaging data or medical images in general? I think that because of our data, we can limit to neuro, but the principle could be the same for other imaging?

Theoretically I would like to see a project that is dedicated to the reception of neuroimaging research data (with a broad meaning, for instance omics data coul be included). But I am afraid that we will only have the possibility to deidentifiy DICOM, NIFTI and eventually a few other format that may be sent tu us.

* So I'm wondering if you thinking about adding a user interface around the API?

* I know that we can find _header infos_ in nifti format, I didn't use much, but do you think that some deidentification can be necessary for this header too?

Yes, I do not know if it will be in the same project but I have in mind a very simple Web interface associated with a way to send files (for instance Web, WebDAV, sFTP).

* In case of filename without any specific information in it, can we have the possibility to deidentify and erase the old one?

I think the goal is to be confident that no identifying data is left in the output of the project. But how to be sure that the file name does not contain such information ? This is why I propose to always rename file names.

* I'm not sure if I understand all the API step, your idea is to first create a metadata file from the DICOM. This metadata could be modified before the deidentification step? So for the user, it would be 2 steps?

Yes, this is where having an GUI makes sense. On the API side, the metadata could be a sort of JSON object (whose exact content is still to be defined). There would be a function to build the metadata given the input files and another function to do the deidentification given the input files and the metadata. If it appears that, in some use cases, there is no need for user interaction, we will just have to chain the two functions.

[Hboni]

Yes, I do not know if it will be in the same project but I have in mind a very simple Web interface associated with a way to send files (for instance Web, WebDAV, sFTP).

A Web interface, connected to what? To be used in local !?

I think the goal is to be confident that no identifying data is left in the output of the project. But how to be sure that the file name does not contain such information? This is why I propose to always rename file names.

In our case, we don't want sensible data in the filename, but if this tool is going to be used by someone who just needs to deidentify before sending data (to the CATI for example), they maybe would keep the original file?