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 well. > > 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 defects). > It seems that these modest file sizes > are well within the 1GB maximum per document "part" suggested at > http://wiki.gnumed.de/bin/view/Gnumed/DocumentManagementConcepts 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:: > http://radiographics.rsnajnls.org/cgi/content/full/24/6/1763 > http://www.blackwell-synergy.com/doi/pdf/10.1111/j. > 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 formats'. 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 specialist. -- Sebastian Hilbert Leipzig / Germany [www.gnumed.de] -> PGP welcome, HTML ->/dev/null _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
