Difference between revisions of "2012 Summer Project Week:LeanSlicer"

From NAMIC Wiki
Jump to: navigation, search
Line 53: Line 53:
 
* Kitware and Queen's are considering grant applications for getting funding
 
* Kitware and Queen's are considering grant applications for getting funding
 
* Unclear how FDA and Health Canada considers open-source software (is it good, because so many people test it independently; or it is bad, because the roles and responsibilities are not obvious)
 
* Unclear how FDA and Health Canada considers open-source software (is it good, because so many people test it independently; or it is bad, because the roles and responsibilities are not obvious)
 +
* ITK, VTK, QT, etc. are part of many commercial systems as "software of unknown pedigree". It's unclear how Slicer would be considered (from software development point of view there is not too much difference between Slicer components, such as MRML library, 2D and 3D viewers, plugin loader, etc. and other components, such as ITK, VTK, ...)
 +
* It's unclear how changes could be managed. Change tracking in the big infrastructure libraries (VTK, QT, etc.) is not feasible. How can we upgrade to a new VTK version then? Need to clarify, consult with regulatory agencies.
  
 
Next steps:
 
Next steps:

Revision as of 05:32, 22 June 2012

Home < 2012 Summer Project Week:LeanSlicer

Meeting Participants

  • Stephen Aylward (Kitware)
  • Taylor Braun-Jones (GE)
  • Andriy Fedorov (BWH)
  • Jean-Christophe Fillion-Robin (Kitware)
  • Dan Groszmann (GE)
  • Ron Kikinis (BWH)
  • Jim Miller (GE)
  • Andras Lasso (Queen's)
  • Tamas Ungi (Queen's)
  • Chris Wedlake (Robarts)

Objective

Build a stripped down version of Slicer containing core functionalities only. To be used for image-guided therapy in the OR. Need to be stable enough for OR use and feasible to apply for Health Canada / FDA approval.

Approach, Plan

Discuss past experiences and future plans for obtaining approval for clinical use of Slicer. Identify major risks, challenges, potential next steps.

Develop a use-case scenario. It would be important to have an easy way to toggle between FDA compliant and standard mode, including customizations and plug-ins.

Progress

Discussed challenges and potential approaches (see details below). Need to identify a specific clinical use and get funding to get started. Groups that require regulatory approvals will help each other, sharing information and experience.

Meeting minutes

  • Slicer is intended for translational research; it has been approved (typically IRB) for specific uses
  • FDA approves for a particular application
  • Approved version has to be locked down (the exact same hardware and software configuration shall be used that has been approved)
  • It might be possible to allow changes (not lock down the system completely), but detect any changes automatically and let the user know that the system is in non-FDA compliant mode
  • Probably lots of work in specification (hardware, software environment, tools, ...), unit testing, tool validation, etc. could be leveraged in multiple submissions; verification and validation probably should be repeated completely for each application
  • Plug-in architecture is OK to use (it's a software implementation detail), but installing new plugins on an approved system would be problematic
  • DICOM part 19 may be relevant (http://medical.nema.org/Dicom/2011/11_19pu.pdf), some support in CTK is planned
  • Kitware and Queen's are considering grant applications for getting funding
  • Unclear how FDA and Health Canada considers open-source software (is it good, because so many people test it independently; or it is bad, because the roles and responsibilities are not obvious)
  • ITK, VTK, QT, etc. are part of many commercial systems as "software of unknown pedigree". It's unclear how Slicer would be considered (from software development point of view there is not too much difference between Slicer components, such as MRML library, 2D and 3D viewers, plugin loader, etc. and other components, such as ITK, VTK, ...)
  • It's unclear how changes could be managed. Change tracking in the big infrastructure libraries (VTK, QT, etc.) is not feasible. How can we upgrade to a new VTK version then? Need to clarify, consult with regulatory agencies.

Next steps:

  • For Slicer developers: keep in mind that having a small, stable, high-quality Slicer core is essential for the groups that would like to use Slicer-based systems (or reuse parts of Slicer) in the operating room
  • For groups that need regulatory approval: get funding, start the work, collaborate with other groups with similar goals. Some feasibility work could be done, such as analysis of all the dependencies of Slicer to see which of them are really needed and try to make the inclusion of not essential parts optional.

References