[IGSTK-Developers] Crash recovery?

Fri Sep 9 00:52:10 EDT 2005

Hi David,
I like your characterization that workflow patterns in the OR are very
robust!  I have often been amazed at how the show keeps going on regardless
of which piece of equipment fails that day... And I agree that accuracy of a
system is what will determine if it gets used at all... After that, it is
the robustness and ease of use that will determine how often it gets used.

In any case, thanks for the discussion, and I have my clarification on crash
recovery. 

-Tina 

>-----Original Message-----
>From: 
>igstk-developers-bounces+tkapur=epiphanymedical.com at public.kitw
>are.com 
>[mailto:igstk-developers-bounces+tkapur=epiphanymedical.com at pub
>lic.kitware.com] On Behalf Of David Gobbi
>Sent: Thursday, September 08, 2005 7:24 PM
>To: David Gobbi
>Cc: 'IGSTK Developers'
>Subject: Re: [IGSTK-Developers] Crash recovery?
>
>I think that I should clarify a bit: a lot of the equipment 
>found in an OR is remarkably reliable, such as the anesthesia 
>machines and the bed itself.  For electrical or mechanical 
>devices that actually go into the patient, such as bipolar 
>tweezers or drills, I saw the surgeon do a quick equipment 
>check every single time before touching the patient.
>
>Anything associated with a PC was a different story, though.
>The Windows 2000 that is used in the OR is no different from 
>the Windows 2000 that goes on a home PC.
>
>David Gobbi wrote:
>
>> 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
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>
>>>>
>>>>   
>>>
>>>
>>>
>>>
>>>  
>>>
>>
>>
>> _______________________________________________
>> 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
>
>