NIfTI metadata extension

The current NIfTI header definition does not contain enough metadata to completely describe a dataset. We propose a NIfTI header extension that is a JSON object using NeuroLex IDs as the field names, with values stored as strings (as per the JSON standard). We need a machine-readable JSON schema that defines the specific NeuroLex terms that may be included, the data types (e.g., int, float, array, ...), and the common human-readable names. This schema should be maintained and hosted by the NIF/INCF.

Note that only the NeuroLex ID will be stored. But the JSON object will also contain a reference to the schema that provides the definitive definition of the field names and the human-readable string. Any software parsing this header extension will either look up the names from the provided URI of the definitive schema, or use a cached version of the schema. (This is similar to the DICOM dictionary concept.)

Software implementing this new header extension will choose which fields to include when it writes the header. Certain fields may be included by default, and others may be options that the user choses to add. If the Neurolex schema flags fields that are known to be free of PHI, then the default fields can be chosen to only include fields that are PHI-safe, and the software can warn a user when they chose to include fields that are not known to be PHI-safe. Unlike the standard NIfTI header, we propose that this JSON object only include fields that have a meaningful value assigned to them. Fields that are unassigned are not written in the header. E.g., the Inversion Time field will not be included for non IR-type scans.

We propose to structure the JSON object like this:

We should provide a reference implementation in nibabel that includes a selected set of metadata from the dicom header that is deemed (by us) to be useful and that is guaranteed to not include PHI. Any implementation writing a file that includes the proposed object could chose to include addition data, including fields containing PHI. Maybe we should define a field that flags files containing PHI? Or add information to the field definitions in the schema that indicates whether a particular field may contain PHI?