gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Image-acquisition, storage and reporting pluggin
Date: Sat, 19 Feb 2011 13:22:05 +0100
User-agent: KMail/1.13.5 (Linux/2.6.34.7-0.3-default; KDE/4.6.0; i686; ; )

On Saturday 19 February 2011 11:13:33 address@hidden wrote:

Hi,

Thanks for elaborating on this. I will comment in the text.

> 
> Single image is worth 1000 words of description. Last two decades have
> revolutionised diagnostic medicine due to development of imaging
> techniques.
> 
> Clinical images are acquired by various ways in medicine. Pathologist
> obtain it through microscope.
> 
> Radiologist obtain through ct, mri or ultrasound. Endoscopist obtain them
> using endoscope or c-arm. Dermatologist can document them using digital
> camera.
> 
> 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!
> 

The scenario is clear. What you could do for a start is run a tool that 
converts images to dicom. That could be stored in a PACS.

> Gnumed has a image acquisition module. There is need to expand it to use it
> with above mentioned setting.
> 

Actually it is an archive module (with built in image acquisition). So yet the 
groundwork is there. I would make sense to develop a new plugin (tab) for your 
sepcific use case. The tutorial (for e.g. student) how to do a plugin is 
there. Time permitting we will have a look and might allocate ressources to 
it. 

Do you intend to use it in your daily routine ? Or would you classify it as 
'nice to have'. In other word would the avaiability make a difference to *you* 
in your daily routine ?

> 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.

Many TV tuner cards can be used in Linux so getting images should be possible. 
Connecting a foot switch is technically possible but needs extra work.

In Windows tv-tuner cards can sometimes be accessed through a twain driver. If 
that is possible getting images into GNUmed should be possible already.

>    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. 4.

Foot switch depends on how it is connected and what drivers are needed.

For Windows a driver is most likely needed and it depends on that driver what 
can be done. If the foot switch emaulated mouse clicks (through the driver) it 
could be usable. Please find out what the manufacturer is of the foot switch 
and use Google to find out about Windows software that makes use of it so we 
can maybe guess or find out how the foot switch is connected and works.

> 
>    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) 

It is not that important as formats can be converted into each other. PNG is 
fine for LATEX and DICOM

> 5.
> 
>    Images are then stored in database.

Yes. This can be done already.

>    Tagging for image search may be an
>    additional capability.

This will be part of the plugin. The plugin will most likely not look like the 
final report. It will allow you to list (and/or) display the captured images 
and select them for inclusion into the report. It could let you tag the images 
next to the picture.

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

Sure. Video streams will be stored on Disc or maybe inside a PACS and only a 
reference will be placed in the GNUmed archive, SOAP entry and so on.

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

For the moment this should not be part of GNUmed itself. However you could use 
GNUmed's feature to export the image to some image editing software (GIMP 
etc.) and import there. Or you could look at 

http://medisnap.sourceforge.net/index.html

which I think was developed for that sort of thing. You could even think about 
using MediSnap for image capture and manipulation and GNUmed only for report 
writing (with a connection to medisnap)

>    8.
> 
>    Reporting: for reporting an images, images need to be selected and then
>    exported to the reporting templates.

Actually the template pulls the images but that is not relevant here.

>    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. 

Yes. Absolutely.

> The template should allow
> writing the desired text for reporting purposes. Something like this..
> 

The plugin, not the template will have a field where you write text. The 
template will pull in that text.

> 
>  patient demography
> 
> images 1, 2, 3 | vertically or horizontally placed
> 
> images 4, 5,6 |
> 
> <text of report>
> 
> 
>  signature of reporting clinician
> 

Yes. That can be done.

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

Well. The image will be stored in the GNUmed archive. So what you ask is 
simply a matter of double clicking the image (which will be opened in a image 
viewer or editor) and having a beamer connected.  One can always save the 
image (once exported and displayed) and integrate into presentation software.

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

For that we could have a hook in GNUmed (hook system is explained in the Wiki) 
'after_report_finished' which will call any script (which would send the SMS) 
you like. 

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

This can be done through the document archive which is in GNUmed already.

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

This is best left to specific software. I think Medisnap can help here. So you 
would go into the document archive , select a number of images/procedures and 
export them to MediSnap (I hope that is possible).

> 
> 
>  I would like to know what you think
> 

All in all reasonable feature request. The first thing to make it happen is to 
file a 'wishlist bug' at launchpad (ask if you are unsure how to do this).

Regards,
Sebastian Hilbert



reply via email to

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