I am interested in linking FHIR resources to external NIfTI resources [1]. NIfTI is widely used by researchers in preclinical neuroimaging to encode MRI, EEG, ECG, MEG… This evidently overlaps DICOM, but the simplicity of NIfTI makes it extremely appealing to researchers.
My question is: What is the recommended way to associate a FHIR “Patient” module with an external NIfTI study stored on a network drive (i.e. outside of the FHIR server)?
I don’t think that the “Media” module is appropriate, as NIfTI can encode non-image/video/sound data (such as EEG or ECG). Likewise, the “ImagingStudy” is not adapted, as it is specific to DICOM.
I was therefore considering of using the “DocumentReference” module, with an “content / attachment” field that would point to the URL of the NIfTI. This “DocumentReference” would in turn be linked to an “Observation” module through the “derivedFrom” field.
Is this the expected solution? If so, is there a full example of such a setup? I thank you much in advance!
I don’t know anything about NIfTI , so I am going only on what you have said.
The DocumentReference can certainly point at non-FHIR objects that have a mime-type. The elements in DocumentReference are intended to be able to describe the content in various vectors helpful to description, identity, and discoverability. This is the FHIR solution for pointing at non-FHIR objects. (Note Media is going away, with the use-cases folded into DocumentReference).
Is the URL you are wanting to point at a static object, or is it another defined API? If it is a defined API, you might want to look at EndPoint which is used to advertise services available.
In both of these solutions, you will have a problem of translating Patient Identity between the FHIR system and your NIfTI system. Likely other concepts need to be bridged like orders, results, interpretations, procedures, etc. These are the things that the DICOM world have found needed to be expressed in a FHIR friendly form, and thus the ImagingStudy.
From what you describe, it seems like NIfTI should discuss with DICOM a forward path. Much of the intention you point out is already supported by DICOM.
Your sentence stating that DocumentReference “is the FHIR solution for pointing at non-FHIR objects” is exactly the confirmation I was looking for.
To answer your question about API, in my context, the NIfTI files are essentially static objects accessible from a network drive, so I guess that EndPoint is not really needed (the API is essentially WebDAV).
Being myself a DICOM developer, I fully agree that going DICOM would be the best solution, especially in light of the ongoing work of DICOM WG-32 (Neurophysiology Data).
However, in the preclinical setup I work for, researchers entirely rely on NIfTI for their signal/image processing tasks. It is indeed sad that by design, NIfTI doesn’t provide a global identifier like the SOPInstanceUID of DICOM. My plan is to use the URL of the NIfTI files as such a global identifier, and to leverage FHIR in order to track the relations with the Patient Identity.