Slicer3 Webservices Infrastructure & Fetch Medical Informatics (FetchMI) Module Steve Pieper, Nicole Aucoin, Wendy Plesniak

overview Remote I/O architecture underpinnings FetchMI current Use case driver for XNAT Desktop …

Slicer3: Remote Data Handling Uses Slicer3’s Remote Data Handling Architecture built last year: Load: checks URI to decide: Local or Remote? If remote, downloads to cache & performs local load from there Save: checks URI to decide: Local or Remote? If remote, performs local save to cache & uploads from there. SLICER REMOTE I/O

Slicer3: Interfaces for managing I/O Presentation layer: Application registry interface for setting data transfer and cache preferences Download manager panel with transfer feedback , cache & process control, and summary information (automatic raise) Disabled in current release: asynchronous xfer cancel xfer SLICER REMOTE I/O

Slicer3: FetchMI SLICER FETCHMI FetchMI module is a sandbox for experimenting with client side interface to data repositories Includes: Select/Specify Server & Type (XND) Search Browse Download (MRML) Tagging Upload (MRML + data) SLICER FETCHMI

Slicer3: FetchMI SLICER FETCHMI FetchMI module architecture Logic collection to contain webservices clients for supported services. (XND webservices client) Client: Logic mechanisms to handle transactions w/server (curl/curl_easy) for each service type (XND) known Webservice types get a vtkMRMLTagTable populated with required markup vtkMRMLStorableNodes get a vtkMRMLUserTagTable to contain markup SLICER FETCHMI

Slicer3: Data loading challenges Slicer-specific challeges: What kind of data are we loading? FetchMI module currently enforces a SlicerDataType tag… …so that Slicer knows what kind of MRML infrastructure to create during load Historically Slicer could infer the data type by way of the load channel. Slicer creates MRML infrastructure, then loads data into it MRML encapsulation conveys that info – but not a lone URI. SLICER FETCHMI

Slicer3: Data loading challenges Slicer-specific challeges: What kind of data are we loading? Also…Slicer has slightly different ways of loading many kinds of data types: many independent developers; no enforced pattern for this… SLICER FETCHMI

Slicer3: Use case driver Image Guided Therapy: Value Streamlines development priorities. Grounds development to real user needs Avenue for early adoption and feedback SLICER / XNAT USE CASE

Slicer3: Use case driver Image Guided Therapy: SLICER / XNAT USE CASE

Slicer3: Use case driver Image Guided Therapy: 2. Tag and Manage with XND 3. Search/Browse & Download with FetchMI 4. Tag & upload MRML + referenced data for pre-op plan with FetchMI 5. Search/Browse & Download MRML + referenced data with FetchMI in OR SLICER / XNAT USE CASE

Slicer3: XNAT next steps Challenges: Security & Authentication QA (upload complete & successful?) Recover / Resume after broken network connection UXP that’s rich enough and simple enough using openssl for RESTful webservices accommodating non RESTful webservices Talking directly to XNAT Enterprise Next steps: Adapt Slicer code to use new harmonized XNAT ws API Move UL/DL functionality into Slicer Base load/save Design appropriate metadata authoring interface with simple/advanced views & features Design appropriate search/browse interface with simple/advanced views & features SLICER / XNAT NEXT STEPS