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

[Jim Busser]

On 2011-01-20, at 4:05 AM, Karsten Hilbert wrote:

> Hello Jan,
> 
> we are highly interested in making GNUmed and MediSnap work
> together.

I am only just wondering about the decentralization (fragmentation?) of 
information.

For the scenario of radiological images (DICON etc) we had been taking the view 
that GNUmed would avoid duplicating the storage… GNUmed could happily store the 
report, and a reference to where the original image may be living. That makes 
sense when the image is in a repository managed by another arm's length group 
such as a hospital or community radiology laboratory. Even when such an 
arms-length (by which I mean "outside the praxis") repository would exist, it 
can make sense in the case of specific patients in GNUmed to store one or 
images of greatest interest within the GNUmed database proper. Another example 
would be the the case of a patient who brings a CD or DVD with important images 
into the praxis where there is doubt about reliable access to the original. 
Maybe here too, the clinician would decide to load the entire study into the 
GNUmed database (or maybe in some other directory on the clinical server?).

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?

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?

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?