Slicer 3 Webservices Infrastructure Fetch Medical Informatics Fetch

Slicer 3 Webservices Infrastructure & Fetch Medical Informatics (Fetch. MI) Module Steve Pieper, Nicole Aucoin, Wendy Plesniak

overview • Remote I/O architecture underpinnings • Fetch. MI current • Use case driver for XNAT Desktop • …

Slicer 3: Remote Data Handling Uses Slicer 3’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

Slicer 3: 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) SLICER REMOTE I/O Disabled in current release: • asynchronous xfer • cancel xfer

Slicer 3: Fetch. MI 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

Slicer 3: Fetch. MI 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 vtk. MRMLTag. Table populated with required markup • vtk. MRMLStorable. Nodes get a vtk. MRMLUser. Tag. Table to contain markup SLICER FETCHMI

Slicer 3: Data loading challenges Slicer-specific challeges: What kind of data are we loading? Fetch. MI module currently enforces a Slicer. Data. Type 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

Slicer 3: 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

Slicer 3: 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

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

Slicer 3: Use case driver Image Guided Therapy: 2. Tag and Manage with XND 3. Search/Browse & Download with Fetch. MI 4. Tag & upload MRML + referenced data for preop plan with Fetch. MI 5. Search/Browse & Download MRML + referenced data with Fetch. MI in OR SLICER / XNAT USE CASE

Slicer 3: XNAT next steps Challenges: Next steps: • 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 • 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