[Loris-dev] Regarding the details of the imaging uploading process

[Cecile Madjar]

Dear Ioannis,

Thank you for reaching out.

1) Given that a subject exists in the database (with a certain PSCID and
> CandID), with respect to running the imaging_upload_file.pl -profile prod
> -upload_id $UploadIDID
> /PATH/TO/UPLOAD/PSCID_CandID_VisitLabel_OptionalSuffix.zip -verbose what is
> the relationship between the upload_id and the patient? Is a row in the
> mri_upload table being created when this command is executed or there is
> something that I need to manually do (e.g. create an id, point to the path
> etc.)? Does the /PATH/TO/UPLOAD have to be explicitly defined in the
> Configuration->Paths (e.g. /data/incoming) for it to be valid?
>

The typical workflow is to inserting DICOM would be:

   1. upload a zip file labelled
   <PSCID>_<DCCID>_<VisitLabel>.<zip|tgz|tar.gz> via the imaging uploader
   (this will insert a row in the mri_upload table with UploadID, UploadedBy,
   UploadDate, UploadLocation, PatientName, IsPhantom filled in according to
   your uploaded file). Note: the PatientName field in the DICOMs' headers
   have to match <PSCID>_<DCCID>_<VisitLabel>
   2. run imaging_upload_file.pl on the uploaded scan => this will
      1. untar the archived file with the DICOMs, parse the list of DICOMs,
      create a new archive and insert information about the DICOM
study (series,
      files etc...) into the tarchive* tables
      2. read the archived DICOM files and convert them to MINC (and NIfTI
      if config option to create NIfTI files is set to true)
      3. read the patient name and compare the information derived from the
      PatientName to what candidate/visit is already present in the database
      (this is performed by a customized function in the prod file in
      dicom-archive/.loris-mri/prod)
      4. read the protocol and compare it to the mri_protocol tables to
      identify the scan type
      5. insert the file in the files table if PatientName and protocol
      found (the file will be labelled
      <study>_<DCCID>_<VisitLabel>_<ScanType>_<001|002..>.mnc)
      6. update the mri_upload table with the SessionID, TarchiveID,
      number_of_mincCreated, number_of_mincInserted, IsCandidateInfoValidated,
      IsTarchiveValidated, InsertionComplete, Inserting

In order for the script to correctly identify to which participant/visit
the scan belongs to, you have to ensure the PatientName is properly
encoding in the DICOM headers. If that is the case, then the magic of the
scripts will work and associate the scans to the proper candidate/visit.

The path to upload in the config module is used only by the imaging
uploader I believe. I don't think this is required by imaging_upload_file.pl
script though.

If you do not wish to upload your DICOM studies via the imaging uploader
but instead do it from the backend directly (upload of many studies at
once), then you should use the batch_imaging_upload.pl script which will

   1. insert a row in the mri_upload table (the same way as the imaging
   uploader module does)
   2. call imaging_upload_file.pl to proceed with the complete insertion

2) I am confused as to how the scans are parsed. Say that I have a .zip
> with dicoms of one subject. From my understanding the parsing is based on
> either the regex of the series description or the scan parameter values
> range lying in mri_protocol. Is that true? In turn, given that this is
> successful, is the scan being aliased with a certain name as defined in the
> mri_scan_type?
>

Exact. The inserted scan would then be labelled according to the following
convention:
<study>_<DCCID>_<VisitLabel>_<ScanType>_<001|002..>.mnc

Hope this helps answer your questions.

Don't hesitate to consult the LORIS-MRI documentation
<https://github.com/aces/Loris-MRI/tree/main/docs>, you may find some
helpful information there.
Let me know if you need additional information.

Best,

Cécile





> I appreciate your help during these troubled times.
> Ioannis
> _______________________________________________
> Loris-dev mailing list
> Loris-dev at bic.mni.mcgill.ca
> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20200723/b28329e0/attachment.html>