2011 Winter Project Week:FetchMIAPI

Key Investigators

• Wash U: Dan Marcus, Misha Milchenko

Objective

Recode the FetchMI interface to work with the XNAT 1.5 REST API

Approach, Plan

FetchMI was originally coded to work with the XNAT Desktop API which is now being updated to look like the XNAT 1.5 API. So updating FetchMI will allow Slicer to exchange data with both Desktop and Enterprise systems.

Short term plan: Implement for workflow for Slicer3.6 like this:

• The user will go to the XNAT web interface to navigate to the data they want.
• They will download these data (probably DICOM) locally and load into Slicer.
• In Slicer, the user will construct a scene file and then upload that scene file to the XNAT through the FetchMI upload interface.
• Only scenes will be downloadable from XNATE into Slicer via FetchMI.
• Once a scene has been uploaded to XNAT, it will be accessible, along with all of the required data files, from FetchMI’s download interface.
• The scene files will be posted to the project-level resources and will need to have some basic slicer metadata added to the format and/or content tags to allow the (for short term) implicit filtering for .mrml files through the query interface.
• FetchMI's existing query interface will display *only* project tags for search to user initially (this eliminates the need to modify GUI to do hierarchical queries for short term) and will only look for files with format=MRML. So all Scenes will be uploaded at the project level, and will be searched at the project level.
• There may be a need to add additional tags as well.

Long term plan:

• All refined work will go into Slicer 4.
• And extensions to query, parsing, tagging, upload and download LOGIC to accommodate moving individual (non-mrml) datasets to the XNE repository.
• This will include substantial GUI revisions.

Progress

The FetchMI code has been reviewed and relevant replacement code has been identified.

Classes to be added:

• vtkFetchMIWebServicesClientXNE <-- vtkFetchMIWebServicesClient (generates queries, performs queries, UL, DL, etc. via curl.) (is an existing vtkFetchMIWebServicesClientXND)
• vtkFetchMIParserXNE <-- vtkFetchMIParser (parsers server responses) (is an existing vtkFetchMIParserXND)
• vtkFetchMIWriterXNE <-- vtkFetchMIWriter (writes required XML for upload) (is an existing vtkFetchMIWriterXND)
• vtkMRMLXNEHandler <-- vtkMRMLHTTPHandler (both in RemoteIO Lib) (is an existing vtkMRMLXNDHandler)

Places in code to be touched:

• vtkMRMLFetchMINode
• vtkFetchMILogic

NOTES

upload scene.

Notation: test project will be named proj1; resource for all the scenes will be named scenes.

• suppose we have a scene file scene1.mrml
• create a unique catalog resource under projects/proj1/resources, (can be one or two REST calls, to ensure uniqueness, should be verified. Say the resource is labeled scene1_files.
• check whether the scene file with name scene1.mrml already exists:

GET REST/projects/proj1/resources/scenes/scene1.mrml If yes, prompt the user to change the file name or overwrite.

• upload all parts of the scene1.mrml to scene1_files

PUT REST/projects/proj1/resources/scene1_files/all_scene_files.zip?unzip=true

• put URI's for all the resources for the scene into the scene1.mrml:

http://xnatserver/projects/proj1/resources/scene1_files/file1.ext1 ... fileN.extN

• upload scene1.mrml

PUT /REST/projects/proj1/resources/scenes/scene1.mrml

• configure the format tag on resource and any other metadata we might want.