Conflicting study identifiers

heudiconv
#1

Dear all,

I’m using heudiconv (version 0.6.0) for the first time because I want to move to BIDS. Not surprisingly, I´m finding some bumps on the road for which I´d appreciate some help.

I have a multi-subject multi-session study and I can generate the convertall.py for most of the subjects and sessions. However, for some, I got an error related to conflicting study identifiers. Here are the command lines and output from the terminal:

INFO: Need to process 1 study sessions
INFO: PROCESSING STARTS: {‘subject’: ‘02’, ‘outdir’: ‘/base/Nifti/’, ‘session’: ‘001’}
INFO: Processing 960 dicoms
INFO: Analyzing 960 dicoms
/src/heudiconv/heudiconv/dicoms.py:58: UserWarning: The DICOM readers are highly experimental, unstable, and only work for Siemens time-series at the moment
Please use with caution. We would be grateful for your help in improving them
import nibabel.nicom.dicomwrappers as dw
Traceback (most recent call last):
File “/opt/miniconda-latest/bin/heudiconv”, line 11, in
load_entry_point(‘heudiconv’, ‘console_scripts’, ‘heudiconv’)()
File “/src/heudiconv/heudiconv/cli/run.py”, line 127, in main
process_args(args)
File “/src/heudiconv/heudiconv/cli/run.py”, line 323, in process_args
dcmconfig=args.dcmconfig,)
File “/src/heudiconv/heudiconv/convert.py”, line 160, in prep_conversion
grouping=None)
File “/src/heudiconv/heudiconv/dicoms.py”, line 96, in group_dicoms_into_seqinfos
studyUID, file_studyUID
AssertionError: Conflicting study identifiers found [1.3.12.2.1107.5.2.19.145371.30000018010610500918800000978, 1.3.12.2.1107.5.2.19.145371.30000018010610500918800001409].

Any idea(s) on how could I resolve the issue on the study identifiers?

Thank you in advance for your time.

Best,
Noelia

#2

Sometimes this error stems from a new study identifier being generated when a subject got out of the scanner mid-session and had to be re-registered. Not sure if you have any info on that? I have tried running the script here to fix those that didn’t have other problems (that this AssertionError was just indicative of).