anonymous wrote on Thursday, September 10, 2009:
Was there any resolution to viewing DICOM images within OpenEMR? Can OpenEMR view DICOM Images?
tmccormi wrote on Friday, September 11, 2009:
There are several free DICOM image viewers for Linux and Windows, it would be a simple matter to launch one of them when selecting a DICOM image. There is likely to be opensrc that could be embedded. This may have all be discussed before, I didn’t search. but a user on the client side should be able to related a DICOM file to a local image viewer easily w/o the need for integrated viewing. Not that it wouldn’t be nice …
–Tony
anonymous wrote on Friday, September 11, 2009:
Tony,
It would be nice to be able to store DICOM images within the document repository in order to view at a moments notice. Is there a way to convert DICOM images into a standard image file for viewing from the document repository in OpenEMR?
aperezcrespo wrote on Friday, September 11, 2009:
Here is an old thread discussing this:
https://sourceforge.net/forum/forum.php?thread_id=1891218&forum_id=202504
I still believe that OEMR should just use a DICOM Viewer and link into a PACS server to view the images. Having OEMR store that much data would make it that much more difficult to backup and restore.
At one time there was mention of moving the images into MySQL BLOBs, having DICOM images in there would really bloat the DB.
But then again with MySQL replication for redundancy that would also protect the images.
Thanks
drbowen wrote on Friday, September 11, 2009:
I think that ultimately OEMR will be a DICOM server. DICOM servers can easily use MySQL backends and there open source solutions already (PACSONE) that use this architecture.
DICOM header info should not be stripped off or you will lose the already existing interoperability that DICOMs already provide.
Free DICOM viewers (K-PACs) already exist. I believe K-PACs will run in either Windows or Linux.
I love my digital x-rays but I am bitter about the proprietary solution I had to buy to get them.
Sam Bowen,MD
cfapress wrote on Friday, September 11, 2009:
Just my 2-cents here…
Why not have an extension in the patient files section that detects if a file is a DICOM image. Then it would display the relavent header info and then the image as a JPG. Sort of like how PDF files appear right now.
Imagemagick can convert a DICOM image to JPG and we’re already relying on that library for some other image routines.
Personal Disclaimer - I have *very* little knowledge of DICOM images and zero knowledge about how a practitioner would use them.
Jason
zhhealthcare wrote on Monday, May 16, 2011:
Hey
Just wondering if there was any solution to the DICOM viewing?
Thanks and regards
Shameem
tmccormi wrote on Monday, May 16, 2011:
jason posted this in 2009 … doesn’t sound hard:
Why not have an extension in the patient files section that detects if a file is a DICOM image. Then it would display the relavent header info and then the image as a JPG. Sort of like how PDF files appear right now.
Imagemagick can convert a DICOM image to JPG and we’re already relying on that library for some other image routines.
zhhealthcare wrote on Monday, May 16, 2011:
Sounds fair to me, Tony. Are there any other issues involved than just viewing the images?
Shameem
aethelwulffe wrote on Monday, May 16, 2011:
application/dicom is the dicom MIME type. That in of itself should pose no great problems for us to allow viewing with a client-side viewer if we allow that mime type in the documents and encounter documents interface. Dicom uses jpeg compression (of various types). If we wanted to bundle a viewer for dicom with the EMR that belongs to Openemr, I can make a Windows client-side dicom viewer with measurement tools with little trouble. If I learn OpenGL instead of Directx (shouldn’t be too hard), and get a cross-platform compiler, I should be able to make a set of apps for windows, osx, and Linux (I would hope) with GLX11, WGL, and CGL.interfaces. I am not familliar with window interfaces and networking in Linux or Mac, but one day I need to “Go There” anyway.
Unfortunately, That isn’t the whole cat in the bag. Peeps want native formats for their medical imaging equipment so they can use their fancy utilities that came with their machines to make measurements and finish the study back in their office away from that horrible trackball pointing device and horrible keyboard on their Echo machine or whatever. They may also want to view in the native format to revise or review data during a procedure. If OpenEMR wants to get treated seriously and punch through the bullshit proprietary data-hogging incompatibility that our buddies at GE, Phillips Midmark and Medtronic promote, then we need to address setting up user interfaces for designating image storage locations and retrieving same across a clinic/Hospital LAN.
I have been meaning to bring this up (and I may have already), but I think I’ll proselytize on another thread.
mukoya wrote on Monday, May 16, 2011:
Single DICOM images can be uploaded via documents on the patient summary screen or via Scanned notes form for encounter specific images. (I would like to ask the ever useful Brady to consider including the working version of scanned notes form if not yet, possibly within the default package). The images are then easily downloaded and viewed via the configured default DICOM viewer on your machine. Note that direct viewing within OEMR is not supported.
Images that can be imported in this manner include CR, RF and single images in a series of MR, CT, US, XA. I have not found a way yet to import DICOM folders with entire study/series e.g to enable scrolling of CT, MRI studies.
My best free/OS DICOM viewers include Microdicom and Clearcanvas Workstation (for windows)
As already pointed out, Importation of entire crossectional images especially CT, MRI will require much more resources and it is better to integrate a viewer only that opens images stored elsewhere e.g a PACS server.