[IGSTK-Developers] Application Framework Concept

Thu May 4 07:23:40 EDT 2006

This notion of workflow and application framework fits well with the idea of reusable components that can be plugged into various scenarios.  It is pretty common in many research circles  and domains (E-commerce, logistics, warfare, etcs.), although I am not aware of any significant efforts that are specific to the medical domain.  As Kevin said, this basic concept was introduced fairly early and specifically as a part of or companion component to the viewer component, but did not gain much traction at that time. I think this is a good time to explore a graphical app builder. The realm of possibilities are endless. The app builder becomes the perfect dissemination vehicle to share different embodiments of IGSTK as well as a wonderful debug and analysis tool.

But if you are talking about extending the app-builder to consider tasks inside the components as they relate to events outside of the software (this is more of the open workflow definitition) then I have different thoughts...

Workflow has this sort of on-again off-again relationship with industry. Although it sounds like sliced bread on paper, at times adopters are slow because it requires either relatively rigid notion of how a process is completed or a tedious definition of how a process should be allowed to be ad-hoc. I could imagine, like other domains, medical specialists have their own special ways that they do what they do.  The niche that workflow has always worked well for, is the interplay between two roles (i.e. the role of the surgeon vs. the role of the radiologist vs. the role of the supporting software).  Identifying the right trigger points where IGSTK functionalities can be plugged in would be helpful in a real-time process sense and as a marketing vehicle. 

Just another $.02

-Brian 

M. Brian Blake, Ph.D
Associate Professor
Georgetown University
Washington, DC 20057
mb7 at georgetown.edu
http://www.cs.georgetown.edu/~blakeb/

----- Original Message -----
From: Kevin Gary <kgary at asu.edu>
Date: Wednesday, May 3, 2006 9:40 pm
Subject: Re: [IGSTK-Developers] Application Framework Concept

> Stephen,
> 
> The application of workflow concepts as you suggest makes sense 
> and is
> appropriate for certain types of applications. A few things -
> 
> - "workflow" has a lot of connotations, particularly in the 
> business 
> application
>  space. While that is not our domain, NIH folks might start 
> equating it 
> with
>  patient information applications, where the term workflow is 
> heavily used.
> - The workflows referred to sounds like usability patterns as much 
> as 
> they are
>  workflow "architectures" - and this is a good thing. Guide, hub, 
> and 
> wizard
>  patterns that incorporate an ease-of-use, task-oriented "flows" 
> would show
>  we are thinking about how to make these applications easy to 
> use, easy to
>  develop, and consistent (for safety).
> - You use the term "framework" but I am not sure what the term 
> refers to in
>  the context you use it. I think the word can be dropped altogether.
>  Common terms are "workflow" or "process" to refer to the 
> template and
>  "workflow instance" or "process instance" to refer to a bound 
> instance.- Worklow languages and GUI-oriented development are 
> complementary. I can't
>  imagine supporting one without the other. Certainly I cannot see 
> how or
>  why one would have GUI-driven development without an underlying 
> language -
>  how else could one demonstrate safety with any rigor?
> - I find it curious that a graphical design tool with code 
> generation is now
>  being considered after such an approach was quickly dismissed 
> early in the
>  project. Perhaps the application-oriented nature of this 
> discussion and
>  the maturity of IGSTK state machines have caused this change of 
> heart?- The implication of a workflow-oriented model is that the 
> "trigger" for a
>  cascading set of events would be from the user, presumably via 
> the GUI.
>  Given recent discussions on concurrency, can we assume this? Do 
> we 
> need to?
>  Concurrency modeling in workflows is common but certainly more 
> complex.- Our UML activity diagrams from Brian's requirements 
> represent a few
>  application-oriented workflows we have explored.  Activity 
> diagrams with
>  OCL is considered a workflow language - and a specialization of 
> statecharts
>  in UML 2.0
> - Our state machines govern the activity of an individual 
> component, but not
>  an entire workflow. State machines may be used for this, but I 
> am pointing
>  out that we use them on an entirely different level right now.
> - Finally, I would caution against us recreating the wheel. For 
> example, 
> there
>  are an awful lot of process definition languages out there. 
> There are
>  many GUI-driven component composition tools. There are many code 
> generators,
>  particularly those following a Model-Driven Architecture (MDA) 
> approach,  such as Rational Rose RT and Rhapsody.
> 
> While I have a number of questions, I like the idea very much. 
> Creating an
> application framework that allows application developers to think 
> in terms
> of tasks that have to be accomplished more closely resembles the 
> strict way
> in which surgical procedures are defined, and as such are a 
> natural way to
> present IGSTK to developers. Furthermore, thinking about how 
> componentsinteract to complete tasks will resolve an issue that is 
> gnawing in my
> gut about IGSTK.
> 
> Brian?
> 
> K2
> 
> 
> 
> Patrick Cheng wrote:
> 
> > 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
> 
> 
> 
> -- 
> ===
> Kevin A. Gary, Ph.D.
> Assistant Professor
> DCST, ASU East       
> (480)727-1373
> http://kgary2.east.asu.edu
> kgary at asu.edu
> 
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
> 