ari-validator

Note

For step-by-step instructions on running any pipeline, see Running Pipelines on XNAT. To enable pipelines for your project, see Enabling Pipelines for Your Project. For running pipelines across multiple subjects in parallel, see Running Pipelines Across Multiple Subjects.

The ari-validator pipeline validates ARI project datasets by checking BIDS and ARI-specific compliance, producing a detailed log file which can be used to track the status of your data.

Similar validation pipelines can be created for your projects if you have specific requirements for your scans and want to have a way to validate your data before spending time on preprocessing.

Validation Steps

  1. Sbref Phase Encoding: Validates phase encoding directions of sbref scans.

  2. Fieldmap IntendedFor: Ensures bold images are associated with the correct fieldmap.

  3. DWI Parameter Matching: Verifies diffusion parameter between DWI and reverse b0.

  4. NIFTI Properties: Checks image dimensions, TR, and other parameters

  5. Required Files Presence: Verifies all necessary files exist

  6. Unexpected Extra Files: Identifies files that shouldn’t be present

  7. Protocol Version: Checks the version of of the protocol used for the DWI and ASL scans.

Input Requirements

Required: - dcm2bids must have been run on the data before running the ari-validator pipeline.

How to Launch the Pipeline

Note

For step-by-step instructions on running any pipeline, see Running Pipelines on XNAT. To enable pipelines for your project, see Enabling Pipelines for Your Project. For running pipelines across multiple subjects in parallel, see Running Pipelines Across Multiple Subjects.

Output and Reports

Validation Log: - Creates ari-validation-details.txt in session directory with detailed logs

Example log of valid data

Example log of data with issues

can you tell what is wrong with the data on the right?

Data Validation Dashboard

Loading validation summary...
Subject ID Status Sbref Direction IntendedFor DWI Parameters File Properties Missing Files Extra Files DWI Version ASL Version

For detailed validation information including specific file names and parameters:


Troubleshooting

  • SBREF: Sometimes the phase encoding directions is flipped even though the the AP/PA direction in the file name is correct. You should delete the incorrect sbref files. See example of incorrect SBREF

  • IntendedFor: Check the intendedFor field in the epi.json file in fmap and see exacly what is incorrect. First thing to check is if there’s missing or extra files. If that’s not the issue, then please contact us and we can help you take a look.

  • DWI Parameters: Version 1 of the DWI protocol is deprecated due to mismatches in the DWI and reverse b0 parameters. If someone was not scanned under version 1 yet still has mismatching issues then you need to investigate further.

  • Incorrect dimensions and TR: Check if data is incomplete or if wrong sequence was used.

  • Missing files: transfer missing files to the correct location.

  • Extra files: delete extra files depending on the reason.

  • Multiple sessions: Scans collected in separate sessions should be merged into one session. For example, if anantomicals were skipped because they had already been collected before, please transfer a copy of the anat files to the new session so the data is complete.

  • Repeated scans: If a scan was collected multiple times, please delete the extra scans according to why the scan was repeated. Ideally, invalid scans should not be sent from scanner to XNAT in the first place.


Validation Scope & Disclaimer

Note

We provide a simple validation check to ensure data compliance with basic BIDS standards, but it is ultimately the researcher’s responsibility to verify their own data in detail.

We do not check everything. Do not assume that data passing our check is perfect.

  • What we check: Basic properties of BIDS rawdata (e.g., anat, fmap, func, dwi, asl).

  • What we do NOT check: Data currently outside the standard pipeline scope, such as abdomen scans, OCT scans, or behavioral data.

  • Custom Checks: If you have specific properties you wish to validate (e.g., checking for specific parameters), please inform us, and we can work on implementing those checks if suitable.


ARI Project Versions

Over time, several ARI project folders have been created. This log clarifies the purpose and status of each:

1. ARI (ari) - Current / Active

  • This is the main project folder displayed on the dashboard above. All new data collected after Summer 2025 is stored here.

  • Data here is supposed to be verified and valid. If invalid scans are found, they are removed.

  • This is the primary folder for end-users.

2. ARI HFS - new (rokerslab_ari-hfs_2024_001) - Archive / In-Progress

  • Contains all older data collected, includes both valid and invalid data.

  • RAs are actively validating this folder. Valid data is being migrated to the new ARI folder, while invalid data is either removed or kept here as an archive.

3. ARI Clean (Rokerslab_ari-clean) - Internal / Testing

  • Made for temporary analysis of the 100 ARI dataset. XNAT admins also use this as a testing ground for pipelines.

  • Users do not need access to this folder.

4. ARI HFS (Rokerslab_vri-hfs_2024_001) - Deprecated

  • The first ARI folder on XNAT. It had many issues and is now outdated.

  • Users no longer need to access this folder.

5. UAEU ARI (uaeu_ari) - Active / External

  • Project hosting the ARI data collected at UAEU.


Next Steps