[IGSTK-Developers] Crash recovery?

[David Gobbi]

Hi Tina,

Your OR experience matches mine fairly well.  Surgeons are very
accustomed to
dealing with unreliable equipment, and if something goes wrong, they
always find
a way to continue.  You could say that the workflow patterns in the OR
are very
robust.

Surgical robotics and certain categories of minimally invasive surgery
need to be
a little more robust than a typical IGS system, though.  Even more
importantly
than robustness is mathematical accuracy, because being a centimetre
from the
target is far more damaging than a mere system crash...

- David

P.S.  I had my own software in the OR for my PhD (for data collection
purposes
only), and after the first trip I added an auto-save feature so that all
fiducial
locations were automatically reloaded after a crash.  It saved me a fair
bit of time
in the end.

Tina Kapur wrote:

>Thanks, David, Andy.
>
>Like you said, David, systems crashes can be independent of the robustness
>of the application software, and for whatever reason (stress photons?) they
>happen frequently in the OR.  In my experience with various types of
>surgeries/IGS systems, while a system crash is considered a
>fact-of-life-that-leads-to-delay, a system unable to recover its state is a
>bad thing.  For example,  typical neurosurgery IGS applications use
>point-based registration that is performed at the start of the procedure,
>before the patient is draped. If this system were to crash well after the
>patient has been draped and the sterile field set up, without crash recovery
>capability, the surgeon will have to abandon use of the system completely
>for the rest of the case because even if they were willing to start over, at
>this point in the surgery they can no longer access points/landmarks on the
>patient's skin. This will make the surgeon less willing to put in the
>upfront effort of doing the registration and generally using IGS the next
>time.
>
>And yes, logging specific information about all steps that are perfomed
>(data loading, all registrations, image manipulation) would need to be
>stored, if you were to do this.
>
>Finally, if the goal is to have an application use IGSTK as one of it's
>components, it makes sense to leave crash recovery to the individual
>application writers.  However, if applications will be written using IGSTK
>only, it might be worth planning this in.
>
>-Tina
>
>  
>
>>-----Original Message-----
>>From: David Gobbi [mailto:dgobbi at atamai.com] 
>>Sent: Thursday, September 08, 2005 3:39 PM
>>To: Tina Kapur
>>Cc: 'IGSTK Developers'
>>Subject: Re: [IGSTK-Developers] Crash recovery?
>>
>>Hi Tina,
>>
>>So far we've focused on crash avoidance, but crash recovery is 
>>definitely a good thing too.  Crashes can't be completely 
>>avoided (at least not on Windows or Linux, which are the 
>>target operating systems).
>>
>>Right now the way that igstk object do their logging isn't 
>>suitable for recovery, the loggers are being used to keep 
>>track of method calls, state changes, etc.
>>
>>What we would need is to keep a log of specific information 
>>that can be used for crash recovery, e.g. which data sets have 
>>been loaded, what the result of most recent patient 
>>registration was, etc. 
>>
>>There are no plans to support this in the current iteration, 
>>but since the Reader and Registration classes have just been 
>>added, it's probably worth considering how those classes can 
>>log some info that can be use for recovery.
>>
>>- David
>>
>>
>>Tina Kapur wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>Does IGSTK have a mechanism for crash recovery?  I was making a wish 
>>>list of what such a toolkit should have, and I can see how 
>>>      
>>>
>>the logging 
>>    
>>
>>>mechanism could be used for recovery from a mid surgery 
>>>      
>>>
>>crash, but just 
>>    
>>
>>>wanted to check if the feature was planned for anytime in the 
>>>      
>>>
>>near future.
>>    
>>
>>>Thanks.
>>>-Tina
>>>
>>>
>>>_______________________________________________
>>>IGSTK-Developers mailing list
>>>IGSTK-Developers at public.kitware.com
>>>http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>
>>> 
>>>
>>>      
>>>
>>
>>    
>>
>
>
>
>  
>