Hello,
I wonder. When using mrconvert to covert from DICOM to NIFTI (or when using mrinfo directly on DICOM files), what does the DOS field in the NIFTI comments section stands for? Does it stand for date of scan, or date of study?
We have images from a Siemens PRISMA scanner, and the DOS field is populated with the date that was in the DICOM’s InstanceCreationDate. This is in contrast with dcm2nii, for example, that takes the date from the DICOM’s StudyDate.
Whatever is the mapping, will be good to document it somewhere in the MRtrix documentation.
Best,
Oren
Hi Oren,
There are indeed a lot of dates in these files, it’s not obvious which to report…
I am however surprised to hear this. It’s supposed to be Date of Series (i.e. scan, I suppose?), but I’m not sure there should be any difference with Date of Study. I can see how that might differ from InstanceCreationDate though, but I can’t see how this could happen in our codebase.
According to the standard, InstanceCreationDate is tag (0008,0012), which is completely ignored in our codebase, as far as I can tell. Tracking through the code (which is a bit complicated, to be fair – this is DICOM, after all…), I can see that the DOS entry is set on this line from the MR::File::DICOM::Series::date field, which is only set once at this point, by reading the contents of tag (0008,0021) – which according to the standard, is indeed SeriesDate.
So I’m really surprised by what you’re saying. Any chance I could see the output of dcminfo -a one_of_your_DICOM_files on these data, and the corresponding output for mrinfo? Assuming these have been sufficiently anonymised, of course.
So sorry, Donald, for causing a confusion. I think the code works fine, and it indeed takes the date from SeriesDate, only that in my specific DICOM, SeriesDate=InstanceCreationDate.
Saying that, why did you choose to populate the NIFTI comment field with SeriesDate rather than the other fields? (and why, in contrast, dcm2nii preserves StudyDate from all fields?) I don’t know enough about the DICOM date fields to say which is the correct/important one.
Please see below for the output of mrinfo and dcminfo -a. The weird dates are due to the fact that it’s a brand new scanner, and nothing is set yet (we are testing it now). It might be that in production, StudyDate always equals SeriesDate, and then it’s a non-issue. Saying that, would be good to 1) document somewhere what DOS stands for, and 2) preserve the StudyDate field as well (if dcm2nii saves it, I guess it’s important).
mrinfo:
mrinfo: [100%] reading DICOM series “Knee”
Image: “ServiceImages (1) [MR] Knee”
Dimensions: 1 x 320 x 320
Voxel size: 3.9 x 0.5 x 0.5
Data strides: [ 3 -1 -2 ]
Format: DICOM
Data type: unsigned 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 0.9989 -0.04013 0.02441 79.66
0.04012 0.9992 0.0009805 -22.95
-0.02443 -3.736e-10 0.9997 -80.88
EchoTime: 0.032
FlipAngle: 150
PhaseEncodingDirection: k
RepetitionTime: 3
SliceTiming: 0
TotalReadoutTime: 0
comments: ServiceImages (1) [MR] Knee
study: SequenceRegion ServiceSequences [ ORIGINAL PRIMARY M ND NORM FSH4_3 ]
DOB: 01/01/1960
DOS: 03/11/2009 10:43:09
dcminfo -a (only fields with ‘Date’ in their name):
[DCM] 0008 0012 DA 8 406 InstanceCreationDate 2009/11/03
[DCM] 0008 0020 DA 8 542 StudyDate 1998/05/08
[DCM] 0008 0021 DA 8 558 SeriesDate 2009/11/03
[DCM] 0008 0022 DA 8 574 AcquisitionDate 2009/04/14
[DCM] 0008 0023 DA 8 590 ContentDate 2009/11/03
[DCM] 0010 0030 DA 8 1384 PatientBirthDate 1960/01/01
[DCM] 0040 0244 DA 8 85844 PerformedProcedureStepStartDate 2009/04/14
OK, your data are indeed a bit messed up! 
I have to admit it’s really difficult to figure out exactly what these different fields should be set to. But the DICOM model is basically that you have patients, who have one or more studies, which can contain one of more series, which consist of a set of image slices. My understanding is that the StudyDate refers to the date the study was registered on the system (i.e. when the patient’s details were entered on the scanner, typically immediately prior to the scans themselves), the SeriesDate refers to when the series (scan) itself was started, and the AcquisitionDate refers to when the data for that particular slice was acquired (I think…). I’m not sure about the InstanceCreationDate (maybe when the record was created on the server?). They will typically all be exactly the same. You’ll find more differences in the equivalent *Time entries.
So in your data, none of these dates are consistent… I’m not sure how that can happen. I expect this will sort itself out once the scanner is fully set up.
As to which is best to record, I’ve always operated on the assumption that the SeriesDate/Time was the most appropriate: this is the one that refers specifically to when that scan was started, and I think that’s the least ambiguous. I’ve not sure why dcm2nii have picked the StudyDate, but there’s nothing actually wrong about that either. Under normal circumstances, they should always match anyway! Exception being a Study that starts before midnight, with some of the individual Series starting after midnight – they’d then have different dates recorded (correctly, in my opinion!).
Happy to document this somewhere, though not sure where the most appropriate place would be – here presumably?