[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Re: Image acquisation, storage and reporting pluggin

From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Re: Image acquisation, storage and reporting pluggin
Date: Thu, 24 Feb 2011 14:55:41 +0100
User-agent: KMail/1.13.5 (Linux/; KDE/4.6.0; i686; ; )

On Thursday 24 February 2011 08:36:13 address@hidden wrote:
> There were certain doubts regarding the need for endoscopic module.
> I have included the article from the pubmed.
> Moreover, I doubt that any gastroenterology unit exists who do not believe
> in photodocumentation. In our practice, we document all endoscopies with
> photographs. That helps assure patient if it is normal, and guides surgeon
> in better ways than mere description.

There is no doubt about that.

> Foot switches: Foot switches are available with local vendors. They are
> configured to work as joysticks. Drivers are provided by the vendors.

That is is undisputed. The question here is 
a) is your particular foot switch supported by any means by your installation 
of Ubuntu ? In other words is there a driver or a software under your Ubuntu 
which does accept and acts on the footswitch. You will have to try. If yes 
then we would need to find a way to get the event of a footswitch action into 
GNUmed. This can be easy if the footswitch does indeed work like a joystick or 
mouse which sends special events signals to an application and will be hard if 
some special (black box) software glue is needed to make the application 
(GNUmed) recognize that you actually did press the footswitch. That will need 
to be researched. 

b) Then it would be nice to know if all footswitches work the same way or if 
each footswitch is different.

> Twain source: endoscope in my experience do not act like a twain source.
> and capture card is needed.

Yes.This is undisputed. However we need to know how to talk to the capture 
card. On Windows the capture card often either provides itself to other 
aplications through a twain source or some (groups of) cards provide special 
interfaces which can be accessed by applications such as GNUmed.

Same for Linux. Some cards can be accessed through SANE. Others need special 
interfaces such as the bttv driver/interface.

Then we need a way to access the twain source from pyhton (and thereby 
GNUmed). This we already have. Or a way to access the driver from python. This 
we do not have and will be unique for each driver.

On Linux we need Python (and thereby GNUmed) to access SANE or the driver of 
the capture card. SANE access works (e.g. through image scanners). Direct 
access is missing from GNUmed.

But more important we need to think about how to store the images and the 
reports. There is no doubt that the report needs images. And ideally the 
images can be picked for the report inside GNUmed. But the images can be 
stored outside GNUmed (e.g. on disk as file, inside Medisnap, in a PACS) and 
referenced by / linked into GNUmed.

I recommend that still images can be stored directly in GNUmed. They can be 
picked in a future special gastroenterology plugin in GNUmed and at the same 
time presented in the image archive in GNUmed.

Larger endoscopy units might prefer to store the images as DICOM inside a PACS 
so they are accessible with an Dicom viewer as well. Future GNUmed might even 
have the option to export as Dicom or to a PACS.

This is the bird's eye view of the situation. For this to become reality the 
potential with the most interest in this plugin can improve the chances of 
this getting produced by

a) describing a potential workflow (what gets done how and what goes from 
where to where)

b) preparing a mock-up user interface (on paper, as screenshot of other apps, 
in a thousand words)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]