2006 IGT Workshop Workflow Breakout
From NAMIC Wiki
Home < 2006 IGT Workshop Workflow Breakout
Contents
Questions to be answered in the report-out session:
- Identify 3 main challenges in this area
- Identify 3 specific problems that can be solved by a collaborative effort between academic and industry partners
- Identify a problem that the NCIGT can help address in the next year
Attendees:
(From sign-up sheet)
- Stephen Aylward
- Heinz Lemke
- Randy Ellis
- Guy Shechter
- Steve Pieper
- Haying Liu
- Clmens Bulitta
- David Gustafson
- Desikacha Nadadur
- Ali Khamene
- Luc Bidaut
- Zohara Cohen
- Cynthia Lnadberg
- Purang Adolmaesumi
- Patrick Cheng
- Marcin Kociolek
- Arnon Amir
Agenda:
Scope of discussion:
Workflow
- A small number of workflow templates can capture the majority clinical cases
- "Analyzing the requirements for modeling IGS systems we concluded that four models is enough to model interaction."
- DG Trevisan, J Vanderdonckt, B Macq, C Raftopoulos, "Modeling Interaction for Image-Guided Procedures" SPIE Medical Imaging, 2003
- Download here
- "Analyzing the requirements for modeling IGS systems we concluded that four models is enough to model interaction."
- Workflows are effectively modeled as State Diagrams, Petri Nets and Timed Petri Nets[1]
- Each state has associated with it a finite set of events that invoke transitions to new states
- They provide an easy transition towards software implementation
- Workflows are not system architectures
- Workflows are already there, as a reality of the way humans perform activities
- Acknowledging its existance, when designing software, results in more realistic and safer software
Why look at workflow
- Improved application design
- Simplified application design
- Produce safer software, better suited for clinical applications
- Basis for testing: inputs/outputs/states
- Encapsulate technologies for research and integration
- Define a language that spans implementation toolkit
The Complexity Delusion
- At first sigth Workflows appear to be complex
- It is not the workflow analysis the one that creates complexity
- The complexity level is already there in the nature of the process itself
- Workflows reveal the real level of complexity that previously was hidden from view
Opening question
- What are the current/pending workflow-related projects?
- Goals
- Methods
- Strengths / weaknesses
- Schedule
Four questions to be considered per topic
- Where is the field
- Other fields using workflows
- Where can research have the most impact
- Where is industry / academic partnering needed / beneficial
- What is the timeline for the research (1 yr, 3 yr, 5 yr)
Topics:
What do we want from a workflow specification
- File for dynamic load / save (create applications)
- Specialize systems for a particular application (e.g., use method “MI registration with params X” at state “register images”)
- Test systems
- e.g. system should move from state A to state B given event C
- e.g. system should not move from state K to state M given even D
- Non-programmatic description of a system (“Our system does this…”)
- An API standard for states/transitions for method/device sharing (e.g., wrap IGSTK, wrap Slicer)
Workflow granularity
- Effect-level (patient) workflow = Guide needle to tumor
- Task-level (physician) workflow = Acquire an ultrasound image of tumor
- Data-level (system) workflow = Record tracker coordinates
Source of workflows
- OR observations
- Interviews
- Abstraction
- Component-level simulations
Level of detail in workflows
- Complete
- Logging / play-back specific cases
- Abstract
- Language for describing a system of method and devices
- Language for describing a network of abstract components
Primary/secondary/tertiary users of workflow descriptions
- Application development
- For FDA approval
- In the clinic
- In research labs
- Testing
- New applications
- Existing applications
- Methods / Devices
- Research
- Developing methods / devices
- Developing new toolkits
Role of patient safety
- Somethings should never happen: explicit workflow make possible to forbid some paths
- Error conditions
- Tracker unplugged – vs – track ultrasound probe
- Determinism
- Guarantee each event is handled and transition occurs successfully
- Patient safety
- Vs ease-of-use (new applications)
- Vs ease-of-extension (new states)
- Vs specialization (new components/devices)
- Vs development (infra-structure)
Workflow challenges
- Recording events in OR [Cleary]: Short lasting, repetitive, rapid, multi-parameter, simultaneous
- Handling/enumerating error conditions
- Deriving common states from multiple recordings
- Deriving common states from different procedures
- Workflow validation
- System testing using workflows
- File formats for workflows (UML2’s Activity Diagrams)
- Managing multiple workflows simultaneously
- Synchronization
- Data passing
- Workflows –vs– C++: Not traditional programming style
- Quantifying physicians time and mental effort
- Accruing error / uncertainty
- Accruing required accuracy
- Accruing risk to the patient / outcome
Concepts of Workflow
- Storyboarding
- How to illustrate handling error conditions
References
Siddoway, et al., "Workflow in Interventional Radiology." SPIE 2006 (PDF)
- Return to the IGT Workshop page
- http://en.wikipedia.org/wiki/Petri_nets
- http://en.wikipedia.org/wiki/Workflow_management
Minutes
Summary Report
Breakout report presentation (Stephen Aylward)