[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/2.6.34.7-0.3-default; 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)
Regards,
Sebastian