2006 IGT Workshop Workflow Breakout

Back to workshop agenda

Follow-on tcon

• http://wiki.na-mic.org/Wiki/index.php/IGT:_Workflow:_TCon_-_Nov_28%2C_2006

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

1. 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. PDF
2. Workflows are effectively modeled as State Diagrams, Petri Nets and Timed Petri Nets[1]
   1. Each state has associated with it a finite set of events that invoke transitions to new states
   2. They provide an easy transition towards software implementation
3. Workflows are not system architectures
4. Workflows are already there, as a reality of the way humans perform activities
   1. Acknowledging its existance, when designing software, results in more realistic and safer software

Why look at workflow

1. Improved application design
2. Simplified application design
3. Produce safer software, better suited for clinical applications
4. Basis for testing: inputs/outputs/states
5. Encapsulate technologies for research and integration
6. Define a language that spans implementation toolkit

The Complexity Delusion

1. At first sigth Workflows appear to be complex
2. It is not the workflow analysis the one that creates complexity
3. The complexity level is already there in the nature of the process itself
4. Workflows reveal the real level of complexity that previously was hidden from view

Opening question

1. What are the current/pending workflow-related projects?
   1. Goals
   2. Methods
   3. Strengths / weaknesses
   4. Schedule

Four questions to be considered per topic

1. Where is the field
2. Other fields using workflows
   1. Real-Time systems
   2. Embedded systems
3. Where can research have the most impact
4. Where is industry / academic partnering needed / beneficial
5. What is the timeline for the research (1 yr, 3 yr, 5 yr)

Topics:

What do we want from a workflow specification

1. File for dynamic load / save (create applications)
2. Specialize systems for a particular application (e.g., use method “MI registration with params X” at state “register images”)
3. Test systems
   1. e.g. system should move from state A to state B given event C
   2. e.g. system should not move from state K to state M given even D
4. Non-programmatic description of a system (“Our system does this…”)
5. An API standard for states/transitions for method/device sharing (e.g., wrap IGSTK, wrap Slicer)

Workflow granularity

1. Effect-level (patient) workflow = Guide needle to tumor
2. Task-level (physician) workflow = Acquire an ultrasound image of tumor
3. Data-level (system) workflow = Record tracker coordinates

Source of workflows

1. OR observations
2. Interviews
3. Abstraction
4. Component-level simulations

Level of detail in workflows

1. Complete
   1. Logging / play-back specific cases
2. Abstract
   1. Language for describing a system of method and devices
   2. Language for describing a network of abstract components

Primary/secondary/tertiary users of workflow descriptions

1. Application development
   1. For FDA approval
   2. In the clinic
   3. In research labs
2. Testing
   1. New applications
   2. Existing applications
   3. Methods / Devices
3. Research
   1. Developing methods / devices
   2. Developing new toolkits

Role of patient safety

1. Somethings should never happen: explicit workflow make possible to forbid some paths
2. Error conditions
   1. Tracker unplugged – vs – track ultrasound probe
3. Determinism
   1. Guarantee each event is handled and transition occurs successfully
4. Patient safety
   1. Vs ease-of-use (new applications)
   2. Vs ease-of-extension (new states)
   3. Vs specialization (new components/devices)
   4. Vs development (infra-structure)

Workflow challenges

1. Recording events in OR [Cleary]: Short lasting, repetitive, rapid, multi-parameter, simultaneous
2. Handling/enumerating error conditions
3. Deriving common states from multiple recordings
4. Deriving common states from different procedures
5. Workflow validation
6. System testing using workflows
7. File formats for workflows (UML2’s Activity Diagrams)
8. Managing multiple workflows simultaneously
   1. Synchronization
   2. Data passing
9. Workflows –vs– C++: Not traditional programming style
10. Quantifying physicians time and mental effort
11. Accruing error / uncertainty
12. Accruing required accuracy
13. Accruing risk to the patient / outcome

Concepts of Workflow

1. Storyboarding
   1. How to illustrate handling error conditions

References

Siddoway, et al., Workflow in Interventional Radiology. SPIE 2006.

• Return to the IGT Workshop page
• Petri Net
• Workflow Management

Summary Report

Breakout report presentation (Stephen Aylward)