ENH: Allows the user to save the Phoenix Report in the sourcedata folder #489
Conversation
…cedata This way the user can go back to the scanner and import the exact same protocol that was run for a given subject, improving reproducibility.
Codecov Report
@@ Coverage Diff @@
## master #489 +/- ##
==========================================
+ Coverage 76.01% 76.42% +0.41%
==========================================
Files 38 39 +1
Lines 3010 3042 +32
==========================================
+ Hits 2288 2325 +37
+ Misses 722 717 -5
Continue to review full report at Codecov.
|
heudiconv/tests/test_dicoms.py
Outdated
| parse_private_csa_header, | ||
| embed_dicom_and_nifti_metadata, | ||
| group_dicoms_into_seqinfos, | ||
| OrderedDict, |
There was a problem hiding this comment.
while at it -- please sort alphabetically (I usually just do that in pycharm)
There was a problem hiding this comment.
You can import those files back at the scanner (or at a different scanner, for that matter), as if they were a normal image. Those "images" will then show up in the image browser, as if it was a normal subject/session.
It is useful because you can then register a new patient at the scanner and "drag-and-drop" these fake images into the scanner queue and voila, you would have the protocol imported "automagically".
This is a very nice trick of Siemens: if somebody shared some DICOM images with you, you could import them into your own scanner and get the same protocol imported, without the need for somebody to export the protocol for you, etc. This process was called to "Phoenix" some images. One (big) problem with that was those DICOM files contained protected health info (the images themselves) together with the name, DoB, etc. Plus people would share a lot of files (say, one per slice, for an anatomical image) when you only needed the protocol info, which is in the header of each of the DICOM files.
Siemens solved this problem by creating that Phoenix Report, which contains just one DICOM file per run with the protocol information, without any pixel values, making it very portable. Furthermore, because it was a DICOM file, you could send it to your PACS system for storage. Then, if you wanted to replicate a study (e.g., for a clinical follow up), you just needed to import back at the scanner the Phoenix Report, rather than the whole set of images.
We use it as a backup (in the sourcedata folder) of the actual protocol, in case you need to share it and for whatever reason you don't have access to the original protocol (so exporting an exar1 file or a pdf is not an option).
There was a problem hiding this comment.
You can import those files back at the scanner (or at a different scanner, for that matter), as if they were a normal image. Those "images" will then show up in the image browser, as if it was a normal subject/session.
so there is one Phoenix .dcm file per each sequence in any given study (which typically has multiple sequences)? or in other words -- could we associate a Phoenix .dcm file with a specific produced sequence (and thus .nii.gz wherever there is a single nii produced)?
There was a problem hiding this comment.
I think so. It depends on what you call "sequence".
There will be one .dcm file per run (here, I call "run" each of the entires in the scanner queue). Some runs produce more than one series (I call "series" each of the folders containing images in the scanner image browser; each "series" has a different seriesUID).
Some Phoenix .dcm files will produce one series (e.g., an MPRAGE without intensity normalization), while other produce more than one series (e.g., a CMRR GRE EPI with a multiband factor larger than 1 will produce the _SBRef series plus the actual MB series). Finally, to make things more interesting, some series can generate more than one .nii.gz file: for the GRE fieldmap, one single run (which will have a single Phoenix .dcm corresponding to it) will have two series (of DICOM images): one for the magnitude images and another for the phase difference images. The series with the phase difference images will produce a single .nii.gz file, while the series with the magnitude will produce two .nii.gz images, one per echo.
If a given "run" is repeated multiple times, there will be multiple (identical, except for the run number) Phoenix .dcm files.
So, in the end, yes: if you have a .nii.gz, there will be a Phoenix .dcm file with the protocol that was used to generate that image. But several .nii.gz images can come from the same Phoenix .dcm file.
But, because there might be more .nii.gz images than Phoenix .dcm files, you need to be careful how to assign which one to which. Probably the best way would be to look at the ID Image Time in the Phoenix .dcm file to check that it matches (at least closely) the ID Image Time of the DICOM series from which the .nii.gz was generated.
(Not sure if all that makes sense...)
There was a problem hiding this comment.
Gotcha. Unlike in case of dicoms+nii produced from them, association might indeed be tricky and anyways is for a heuristic to figure out
This PR allows the user to store the Phoenix Report in the
sourcedatafolder.Siemens scanners create a Phoenix Report (or Phoenix Document) series, with DICOM files that store the protocol that was run on a given scanner session. These Phoenix Report series can be brought back into any Siemens scanner that runs the same software version and be used to automatically import the protocol parameters.
By archiving the Phoenix Report in the
sourcedata, the user can extract it, load it back into the scanner and run the exact same protocol that was run for a previous subject, improving reproducibility. This can be done by going to the image database in the scanner, "importing" the Phoenix Report and then drag-and-dropping it into the exam queueThis PR includes the code (in
dicoms.py), unittest (test_dicoms.py) with the corresponding test data (tests/data/Phoenix) and an example of heuristic (bids_PhoenixReport.py, with the corresponding unittest intest_heuristics.py)