Re: [Gnumed-devel] Free FotoFinder Replacement: MediSnap

[Sebastian Hilbert]

Am Freitag, 21. Januar 2011, 07:29:59 schrieb Jan Kechel:
> Hi Jim,
> 
> > I am only just wondering about the decentralization (fragmentation?)
> > of information.
> 
> surely this is an issue

This stems from the fact that MediSnap serves other software as well which 
might not have image handling capabilities I guess.

> 
> > What I am less certain about is the case of images captured (photos)
> > or generated (marked-up photos, sketches, mappings) by the doctor
> > where the creation occurs in the praxis:
> > 
> > 1) What should determine whether such images should live in the GNUmed
> > database or in MediSnap?
> 

images captured via a scanner should live in the GNUmed database for network 
wide access.

same for marked up photos and sketches. Pretty much all the content short of 
huge dicom cine (echo, flouroscopy ) files should live in the GNUmed db. Dicom 
still images could very well live in the GNUmed db as well.

However for Dicom cine studies the whole point is to store them somewhere 
where they can be accessed by a dedicated viewer. For echo and fluoroscopy I 
recommend setting up a PACS even in a small practice and using the GNUmed 
archive only to store pointers.

For Osirix it is possible to write an XML/RPC based connector which would 
follow the link in the GNUmed archive, pull up the correct patient and study 
in Osirix. For a smaller practice those studies could be stored in Osirix but 
Osirix could grab them from a PACS as well.

For Linux and Windows there was no such thing until recently. The people at 
Ginkgo-CADx replied that they are looking into an XML-RPC interface.

Back to Medisnap. I guess it should be possible to use MediSnap for its image 
acquisition and viewing/manipulation capabilities. It should be possible to 
grab photos through it and feed those back to GNUmed. When looking at the 
images again GNUmed could export them, feed them to medisnap and let medisnap 
handle them.

I have to take a better look. It all depends on the use case. If there is one 
it can be done mostly.

> I don't know. But actually it should be quite easy to tell via GDT
> either one where to store pictures with what names .. its just not
> implemented yet ;)
> 
Exactly.

> > 2) If they live in MediSnap, is this under the model of
> > separate-but-co-ordinated "services" where the doctor's "record of the
> > patient" is being divided across multiple separate databases?
> 
> there wouldn't be anything coordinated right now
> 
keeping databases in sync is a pain. medisnap could work as layed out above.


> > 3) Does this depend on "federation" of unbreakable patient identity
> > across the databases? Will there exist persistent links that allow the
> > data to be unified in later joins / views either for patient care or
> > when evidence of the adequacy
> > or quality of the care becomes later demanded?

One way to do it is GNUmed as a master exporting data on demand and medisnap 
as a slave working with this data. As long as there is a 1:1 interaction upon 
finishing work in medisnap freshly produced content can be fed back


> 
> MediSnap does not store any image in the database. I'm just using
> file-based access to this. 

that is why in our scenario GNUmed should store the data so there is network 
wide access without the hassle of 

> The appropriate network-drive can be
> configured in the properties file.
> 

network drives.

> .. anyway, all the meta-information like what picture of which
> localisation was shot when is stored to the db.
> 

In our scenario the metainformation would be stored in GNUmed as well and 
exported and fed to medisnap on a case by case basis.

> The 'good' thing about gnumed is, that it's free software, so you can
> create a perfect adaptor to work together with medisnap .. something
> that's not possible with those proprietary 'things'. So in the end there
> obviously should be all images in one place and actually exist only a
> single db.

That is my understanding as well.


> The 'bad' thing is, that the olympus camera drivers are only available
> for windows .. which is one of the reasons why i didn't like medisnap
> anymore some years ago.
> 

that is ok. Since GNUmed runs on Windows as well the workstation next to the 
camera could be a Windows one.

> Jan
> 
> PS: I just created a binary-release and uploded it as file to
> sourceforge. This should make it a lot easyer to experiment with MediSnap:
> https://sourceforge.net/projects/medisnap/files/20110121-first-public-relea
> se/

Good to know. WIll have a look.

Sebastian