Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...


 
Any medical image viewer that is capable of communicating via DICOM should be able to easily integrate with dcm4chee as shown by (A) in the image above.  This mode of communication would use DICOM Query (C-FIND), and DICOM Retrieve (C-MOVE) to locate and fetch the images to the local machine.  The images may then be viewed, manipulated, and potentially re-stored (via DICOM C-STORE) back into the archive if they have been modified.  This is a very well known, and common manner of integrating a viewer with a DICOM-capable PACS or archive system such as dcm4chee.  See here for a list of DICOM viewers that are known to work with dcm4chee.  dcm4chee also supports such things as the storage and retrieval of hanging protocols, and a General Purpose Worklist (GPWL) .  dcm4chee does not supply a 'reading worklist' as can be found in most PACS systems.  A reading worklist would typically lock studies while they are being read, and handle the workflow of finalizing the studies and producing reports.  It is possible to achieve this workflow, however, by other meanswhich can have a positive effect on the viewing environment - providing the viewer supports the integration of these standards.

In addition to the standard DICOM integration, there is also a Web-based application supplied with dcm4chee, as shown in (B) above.  dcm4chee-web utilizes HTTP to communicate between the archive and a standard Web browser.  dcm4chee-web uses the WADO standardto display images in the browser. The WADO services may be used in a stand-alone fashion as well, according to the standard. WADO is a good thing for DICOM, but access to the imaging study is limited to a single image at a time.  This is not sufficient for a physician who needs to review an entire study or series.  WADO wasn't written to address this need, as that is covered by other pieces of the DICOM standard.  However, in some cases, it is useful or even beneficial to have a Web-based viewer that is the primary reviewing/reading component.  Oftentimes, this 'Web-based viewer' is simply a Java Web Start application that is launched from a Web page, but then uses DICOM to communicate with the archive.  It is uncommon (but not unheard of) to have a complete diagnostic viewer that runs entirely within the Web browser.  This is because running an application within the browser sandbox places a lot of restrictions on the application.  Some of these restrictions can be eliminated through the use of digital certificates signifying that the application is trusted and may operate outside of the sandbox, but the biggest hurdle to overcome is memory.  Some medical images, and studies, are very large - often reaching sizes of thousands of images for a single study, or hundreds of megabytes for a single image.  It is difficult to run this through a browser without performing some type of streaming and/or caching.

...