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

From NAMIC Wiki
Jump to: navigation, search
Line 44: Line 44:
 
==Meeting minutes==
 
==Meeting minutes==
  
−
* Slicer is intended for translational research; it has been approved (typically IRB) for specific uses
+
* Slicer is intended for translational research. It was approved (typically IRB) for specific uses in the past. FDA gives approval for a particular application.
−
* 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)
 
* 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
 
* 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
+
* There are many uncertainties:
−
* 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)
+
** 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
−
* 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, ...)
+
** 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
−
* 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.
+
** Plug-in architecture is probably OK to use (it's a software implementation detail), but installing new plugins on an approved system would be problematic
 +
** 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:
 
* 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 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.
 
* 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.
 +
* Kitware and Queen's are considering submitting grant applications for getting funding for implementing clinical applications that utilize Slicer
  
 
==References==
 
==References==

Revision as of 05:39, 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 was approved (typically IRB) for specific uses in the past. FDA gives approval 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)
  • DICOM part 19 may be relevant (http://medical.nema.org/Dicom/2011/11_19pu.pdf), some support in CTK is planned
  • There are many uncertainties:
    • 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 probably OK to use (it's a software implementation detail), but installing new plugins on an approved system would be problematic
    • 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.
  • Kitware and Queen's are considering submitting grant applications for getting funding for implementing clinical applications that utilize Slicer

References

Retrieved from "https://www.na-mic.org/w/index.php?title=2012_Summer_Project_Week:LeanSlicer&oldid=76810"