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

[Karsten Hilbert]

On Sat, Feb 19, 2011 at 03:43:33PM +0530, address@hidden wrote:

> Though radiological images are DICOM compatible, others are typically
> non-DICOM compatible. Many database programes are available for DICOM
> images. But for others eg. Endoscopy images, very few options are there.
> These programs do not integrate with emrs. Moreover, none is available in
> gnu domain!
> 
> Gnumed has a image acquisition module. There is need to expand it to use it
> with above mentioned setting.

One basic thought: GNUmed itself may not be that well suited
for storing large amounts of images or videos. It might work
well but hasn't been tested so far. GNUmed can, however,
also collaborate with external applications.

> To enable development, I would like to elaborate the requirement further in
> next few paras.

>    2.
> 
>    Image acquisition: Images are acquired using a image capture card (tv
>    tunner card) which is connected to endoscopic processor by s-video cable
>    (olympus). Other endoscopes (fusinone) connect using composite output from
>    processor.

This is already possible as long as there is a TWAIN or SANE
driver. Under Linux most capture devices tie into
Video4Linux which in turn can be accessed by SANE.
Alternatively, GNUmed could use something like VLC which can
capture the video.

>    3.
> 
>    Images are captured using a foot switch with two buttons. These buttons
>    are configured using games controller in windows. I am not aware how it is
>    done on linux. One switch is used to capture images. Other is for video.

That does not sound like the job of GNUmed. There really
should be a dedicated standalone software for capturing the
raw data (which can then be pumped into GNUmed).

>    4.
> 
>    Image format can be anything (bmp, jpg, png etc). Though eps should be
>    preferred, if we plan to use LaTex for reporting template (I may be wrong)

These days LaTeX can make do with most image formats.

>    5.
> 
>    Images are then stored in database. Tagging for image search may be an
>    additional capability.

Arbitrary tags are not directly supported but are certainly
possible by judicious use of per-document descriptions.

>    6.
> 
>    Care has to be taken regarding video-format, as it may take up lot of
>    space.

If there's a use case to capture video there must be storage
room for that requirement. PostgreSQL certainly can store
such data. It will be a problem when individual videos go
over 1 GB.

>    7.
> 
>    Image editing: Basic editing features such as annotation, marking the
>    lesion, and cropping may be sufficient.

That is best left to external applications, just like it is
handled now.

>    8.
> 
>    Reporting: for reporting an images, images need to be selected and then
>    exported to the reporting templates. Templates which allow one, two, five,
>    six and nine images on single page can be created and allowed as a choice 
> to
>    the user to select one from them. The template should allow writing the
>    desired text for reporting purposes. Something like this..

I agree. This would need a new widget to select the images.
All in all not difficult.

>  Additional features that may be expected
> 
>    1.
> 
>    export of images to presentation software/beamer

Already possible.

>    2.
> 
>    automated sending sms of a conclusion of procedure to referring doctor

Already possible (using the post-document-creation hook or
re-using the "fax/mail document" function from the document
context menu.

>    3.
> 
>    selection and export of images to a folder : interesting images

Export already possible, selection not supported so far.

>    4.
> 
>    comparision between images (You may just want to compare a lesion seen
>    days before with the present status

Comparison is so far only possible for visual progress notes.

I would think it would be best to leave this to an outside
"light table" application.

GNUmed can improve selecting images for export, though.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346