Analysing compliance w.r.t. vendor, model, and software version

[sinhaharsh]

We observed that Siemens scans were much more compliant (> 95 %) than GE and Philips (~75 %). As discussed in faculty meeting, it would be much more informative to this issue builds from vendor or there is some hidden issue. It was suggested to check software versions, model information and site name for each scan.

Site names are not present in DICOM tags. But the software version and model name is present. A preliminary analysis on 375 subjects shows

1. Siemens had no issues in software versions. All scans were performed with same software version - syngo MR E11 even though two scanner models were used - Prisma and Prisma-Fit.
2. Philips scans have multiple software versions
   5.3.0.0
   5.3.1.0
   5.3.1.1,
   5.3.0.3
   5.3.0.0
   And two different models were used Achieva dStream, and Ingenia
3. Similarly, for GE there are multiple versions
   27_LX_MR Software release:DV26.0_R01_1725.a,
   27_LX_MR Software release:DV26.0_R02_1810.b,
   27_LX_MR Software release:DV25.1_R01_1617.b,
   25_LX_MR Software release:DV25.0_R02_1549.b,

And there are 2 models - DISCOVERY MR750, Signa Creator

It would be interesting to investigate if these software versions are indeed leading to inconsistencies we observe in parameters.

[raamana]

we shoudl have fields in MRdataset to capture all this info and let users to restrict checks to different subsets of data

[sinhaharsh]

Given any parameter, we should have a general way to stratify scans. This would be very helpful down the line. As of now, we require stratification w.r.t.

1. echo time
2. AP/ PA
3. Vendor
4. Software
5. Scanner model

Last time we talked about stratification for echo time. But, as you suggested, we should allow the users to restrict checks to different subsets of data. MRdataset should have just all the info. The user would be able to do it only if there is some CLI option and associated function. I will get back to it later