[Top][All Lists]

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

Re: [Gnumed-devel] Re: DICOM viewers (was Feedback)

From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Re: DICOM viewers (was Feedback)
Date: Mon, 31 Dec 2007 00:01:49 +0100
User-agent: KMail/1.9.6 (enterprise 20070904.708012)

On Sonntag 30 Dezember 2007, James Busser wrote:

> If the Tools > DICOM menu option simply provides a link to an
> external application (viewer) --- which the user can *optionally*
> choose to install --- then can I conclude correctly that Python
> Imaging Library (PIL) is needed for something unrelated to DICOM,
> perhaps to assist GNUmed to open non-DICOM image formats like TIFFs,
> GIFs, PNGs and JPEGs etc?
True. It is used to convert image file format and so on. On Linux it is 
actually used as a SANE bridge through the PIL-SANE-module. On Mac this might 
be an option as well.

> Or does some non-GNUmed application need to 
> be installed on every computer in order to be able to view these and
> is this to be mapped using the Setup plugin?
Yes. To view any file type one needs an appropriate viewer. This could be 
preview on Mac. We have some heuristics in GNUmed that tries to be as helpful 
as possible in figuring out which viewer to call. We are actually much more 
helpful then most programs by not only relying on the file extension but also 
look at the files itself. We even handle files that have no extension at 
all - a case which makes MS Windows fail badly.

It is not yet mapped to the user but makes use of the systems configuration. 

> Also, if we work through the use-cases *storing* a patient's
> images... given that most doctors desire to receive and store (only)
> the radiologists' interpretations (text file reports), preferring to
> avoid having to save copies of the images in their own EMRs, but even
> if this is true...
In Germany there are some doctors who prefer to have the digital films as 

> 1) If another copy of the original may be impossible, or difficult,
> or simply inconvenient to try to access if it may be needed in the
> future (for example if the patient obtained the study and the CD
> while on a trip in another country) might a doctor wish to save these
> 0.5 MB to 10 MB files in GNUmed and would they do this through
> "Patient > import documents"?

Yes that was our intention. Any file can be saved. E-Mails, scanned paper 
reports, audio recordings of heart sounds ( my stethoscope saves them as wave 
file - very helpful in detecting infarction caused ventricular septum 

> It seems that these modest file sizes 
> are well within the 1GB maximum per document "part" suggested at

Yes that it possible and intended. When files sizes reach 100 to 600 MB or 
more it is still possible but not feasible because the file is retrieved 
completely before it is displayed. We have no streaming implented. No many 
viewers do streaming anyway. 

So for cath files or any Dicom file I envision storing those in a local PACS 
system and handling them through a DICOM viewer. This is not too hard to 
setup and can be done in FOSS completely. GNUmed stores just a reference to 
the object in the PACS and knows how to call that object in the dedicated 
viewer. Osirix has an XML-RPC interface and can be told by GNUmed what to do 
(e.g. display a study).

> 2) if the local, regional or national medical system supports local
> storage of a pointer to the image, the ability to save and manage
> this could make it much easier to later re-access the same image.

Any security implication aside a patient might opt to store the digital images 
online and hand access pointer (like URL in webbrowsers) to the physician.

> This could be implemented as an extra field in the "Document" and
> "Import Documents" notebook tabs as soon as any host imaging systems
> would provide and handle permalinks.

Yes we can support those permalinks instead of files as soon as this is 
available. Since Osirix will provide somethinf like this (actually the PACS 
provides it) I will look into implementation as soon I can run Osirix version 
3. Taking this one step futher one could use tools like Dicom-Donkey and 
convert any image file to a Dicom study. So one could scan a document, 
convert it to a DICOM study and store it in a PACS instead of the GNUmed 
database. GNUmed would then store the permalink instead. This would ensure a 
lean GNUmed database in offices where large studies are produced on a daily 
basis (like echo departments)
> -------
> ps - I found links online to a medical journal paper from 2004 that
> reviewed free viewers for Mac but has possible generally useful
> information such as typical DICOM file sizes (Table 2), and to a
> study that assessed the acceptability of working with JPEG Web-
> converted DICOM images::
> 1747-4949.2007.00092.x?cookieSet=1

If you are a radiologist you must care about the question 'is what I see 
really what is there' or 'do I see something altered by compression and file 

or The rest of us conversion is just fine as long as we 'don't use it for 
diagnostic purposes'. At least in German no patient will complain if a 
physician tells him: I saw something (in the jpeg compressed image) digital 
document of your chest that looks suspicious and needs futher workup by a 

Sebastian Hilbert 
Leipzig / Germany
[]  -> PGP welcome, HTML ->/dev/null

reply via email to

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