2012 Summer Project Week:LeanSlicer - Revision history

Lasso: /* Meeting minutes */

2012-06-22T12:53:24Z

Meeting minutes

Lasso: /* Meeting minutes */

2012-06-22T05:42:52Z

Meeting minutes

Lasso: /* Meeting minutes */

2012-06-22T05:42:27Z

Meeting minutes

Lasso: /* Meeting minutes */

2012-06-22T05:42:05Z

Meeting minutes

Lasso: /* Meeting minutes */

2012-06-22T05:41:15Z

Meeting minutes

Lasso: /* Meeting minutes */

2012-06-22T05:41:05Z

Meeting minutes

Lasso: /* Meeting minutes */

2012-06-22T05:40:19Z

Meeting minutes

Lasso at 05:39, 22 June 2012

2012-06-22T05:39:59Z

Lasso at 05:32, 22 June 2012

2012-06-22T05:32:56Z

Lasso at 05:23, 22 June 2012

2012-06-22T05:23:50Z

@@ Line 57: / Line 57: @@
 ** 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
+** Kitware and PerkLab (at Queen's) are considering submitting grant applications for getting funding for implementing clinical applications that utilize Slicer
 ==References==

@@ Line 43: / Line 43: @@
 ==Meeting minutes==
+(notes taken by Andras Lasso)
 * Slicer is intended for translational research. It was approved (typically IRB) for specific uses in the past. FDA gives approval for a particular application.
 * There are many uncertainties:

@@ Line 54: / Line 54: @@
 ** 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==

@@ Line 46: / Line 46: @@
 * Slicer is intended for translational research. It was approved (typically IRB) for specific uses in the past. FDA gives approval for a particular application.
 * There are many uncertainties:
-** Approved version has to be locked down (the exact same hardware and software configuration shall be used that has been approved), but how much and how can it be managed?
+** Approved version has to be locked down (the exact same hardware and software configuration shall be used that has been approved), may have to be supported for a certain amount of time - how it is applicable in an open-source / research setting?
 ** 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

@@ Line 46: / Line 46: @@
 * Slicer is intended for translational research. It was approved (typically IRB) for specific uses in the past. FDA gives approval for a particular application.
 * There are many uncertainties:
-* Approved version has to be locked down (the exact same hardware and software configuration shall be used that has been approved), but how much and how can it be managed?
+** Approved version has to be locked down (the exact same hardware and software configuration shall be used that has been approved), but how much and how can it be managed?
 ** 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

@@ Line 53: / Line 53: @@
 * 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)
 Next steps:

@@ Line 4: / Line 4: @@
 </gallery>
-==Key Investigators==
+==Meeting Participants==
-* Queen's: Andras Lasso
+* Stephen Aylward (Kitware)
-* Robarts: Chris Wedlake
+* Taylor Braun-Jones (GE)
-* Harvard SPL: Ron Kikinis
+* Andriy Fedorov (BWH)
-* Kitware: Stephen Aylward
+* Jean-Christophe Fillion-Robin (Kitware)
-* Isomics: Steve Pieper
+* Dan Groszmann (GE)
-* Other Slicer core developers?
+* Ron Kikinis (BWH)
-* Taylor Braun-Jones?
+* Jim Miller (GE)
 <div style="margin: 20px;">
 <div style="width: 27%; float: left; padding-right: 3%;">
@@ Line 24: / Line 28: @@
 <h3>Approach, Plan</h3>
-Discuss past experiences in obtaining approval for clinical use of Slicer.
+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.
@@ Line 35: / Line 37: @@
 <h3>Progress</h3>
 </div>
 </div>
-==Delivery Mechanism==
+==Meeting minutes==
-Summary of discussions and planned next steps will be posted on this page.
+Next steps:
 ==References==