[IGSTK-Developers] Application Framework Concept

Luis Ibanez luis.ibanez at kitware.com
Wed May 3 15:59:36 EDT 2006


Hi Stephen,

The framework looks very nice.


The approach of starting from the clinical workflow and
mapping it into an application is definitely a good way
to address our concerns about patient safety.


The idea of generating the source code of the corresponding
StateMachine will also help to address the concerns of
developers who may find this task too complicated or at
least boring.


I'm not quite sure that a "Language" is the best mechanism for
formalizing the workflow in this context, but it is certainly
the approach that many "state machine" based frameworks have
taken. So it will be easy to find references to other projects
that have followed this approach and therefore provide support
for our decision.


Intuitively I would have preferred a sort of visual programming
environment where the developer would have selected IGSTK components
by dragging blocks into a canvas, connect them using colored lines.
This will create the infrastructure of the application (e.g. if it
has 2 Viewer2D and 1 Viewer3D, what SpatialObjects it needs, and so on.
In a second canvas, it could represent the clinical workflow using
also blocks that are dragged from a toolbar. Then generating the
source code of a state machine from this flow diagram.


On the other hand we all know that developing GUIs will require a large 
amount of effort (time/money); so a language version of that interaction
may be a more realistic approach.


One thing that I would suggest to add is to have the notion of
"checkpoints" at the application level. They may end up being
implemented as transitions of the state machine, but from
the point of view of the clinical level, they should be the
ones that define when it is appropriate to pass from State A
to Stage B or the intervention.



    Luis


===========================
Stephen R. Aylward wrote:
> Hi,
> 
> I wanted to run a concept by ya'll.  Please take a second to let me know 
> what you think of the following design for the application framework 
> solution:  (please comment on the feasibility of the solution, no need 
> to pick apart the text...yet... :) )
> 
> [SNIP]
> 
> Generating an IGSTK application at a minimum requires (1) carefully 
> considering the workflow of the medical procedure and (2) implementing 
> that workflow as a comprehensive set of state machine transitions that 
> integrate chosen IGSTK modules.
> 
> Our analysis of several interventional radiology tasks [REF] has 
> revealed that there are a few general workflow frameworks that are 
> common to many interventional radiology procedures, and substituting 
> appropriate modules into a workflow framework is sufficient for 
> specializing a workflow for a particular procedure.
> 
> We propose to provide an application-builder program that allows a user 
> to choose from a list of pre-defined workflow frameworks and to specify 
> modules for the components of the chosen framework.  The 
> application-builder program will then automatically generate the source 
> code and CMake files needed to build that IGSTK application.
> 
> The tasks of this project are
> 
> 1)    Develop a language for defining workflow frameworks as application 
> templates.
> 2)    Develop a language for describing available IGSTK modules that can 
> be plugged into the components of a workflow template.
> 3)    Develop and validate a program that can load a framework and 
> multiple module definitions, accept user input to assign modules to the 
> components of the framework, and generate code that implements a 
> complete application.
> 
> The concept of an application-builder program is the penultimate 
> embodiment of patient-safety-centric programming that has driven the 
> development of IGSTK.
> 
> [SNIP]
> 
> Stephen
> 





More information about the IGSTK-Developers mailing list