[IGSTK-Developers] Application Framework Concept

[Kevin Cleary]

Hi all:

As a related note, workflow analysis is a topic that Heinz Lemke, the
driving force behind the Computer Aided Radiology and Surgery meeting, has
been trying to promote in the past few years. As a matter of fact, they got
a German project funded at the University of Leipzig (former East German
city) to look at this. It would be really cool to specify the workflow of a
clinical procedure and then map it into the state machine concept. 

Maybe we can find some way later on to spin off some of these ideas into
separate funding, but as most of us know the problem is that these things
are difficult to get funded.

Kevin

-----Original Message-----
From: igstk-developers-bounces+cleary=georgetown.edu at public.kitware.com
[mailto:igstk-developers-bounces+cleary=georgetown.edu at public.kitware.com]
On Behalf Of Patrick Cheng
Sent: Wednesday, May 03, 2006 4:28 PM
To: Luis Ibanez
Cc: IGSTK; Stephen R. Aylward
Subject: Re: [IGSTK-Developers] Application Framework Concept

Hi Luis,

The visual programming environment sounds very interesting to me 
especially when applying it to programing the state machine.

As I have mentioned before, there are some project called FSMC (Finite 
State Machine Compiler), which has a GUI canvas for user to design the 
state machine by drag and drop states and transitions. And later on they 
can generate the state machine code base on this graphic model.

I think this will help the developer a lot for the first stage of 
mapping out the application work flow and state machine frames.

Patrick

Luis Ibanez wrote:
> 
> 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
>>
> 
> 
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
> 
> 
_______________________________________________
IGSTK-Developers mailing list
IGSTK-Developers at public.kitware.com
http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers