Fri, 19 Aug 2005 17:31:18 GMT

The latest buzz in the PACS world, especially in a few Discussion Threads on AuntMinnie.com, is the "web-enabled" PACS. Two of the more significant features of a PACS that would qualify it as web-enabled are communications between client displays and server based on http:// or http(s):// and the image objects are all assigned their own URL. The merits of a web-enabled PACS aside, I have a concern about the assignment of a URL to all of the image objects.

The implication is that all study data objects would be treated as URL objects. This is in fact the way Fuji treats the study objects in Synapse. While I would agree that there are some distinct advantages to "organizing" a database using URL, the problem is when the use of URL supercedes the use of DICOM.

Web tools like http:// and URL are effectively standards, but there is only one universally recognized standard in medical imaging communications and that is DICOM. A lot of effort continues to be poured into defining DICOM objects and DICOM communication SOP Classes. The vendors are being pushed hard to keep up with the advancements in the DICOM standard and nowhere is this more evident than in the area of IHE-inspired DICOM objects and SOP classes like Presentation States and Key Image Notes. To this day there are a number of major PACS systems that still treat key data objects associated with the study as proprietary objects. It's very difficult to extract and migrate non-DICOM data objects to another DICOM-conformant PACS.

My fear is that the adoption of URL as the primary method of managing study related data will de-emphasize the importance of first making all study-related data DICOM objects. There is no way to predict how many PACS systems will be able to exchange URL data objects five years from now. However there is a very good chance that most PACS systems will be able to exchange DICOM objects five years from now.

There may be a number of good arguments for tagging all study related data objects with a URL, but let's keep the pressure on the PACS vendors to make all of those data objects DICOM objects first.

Document dilemma

Thu, 04 Aug 2005 20:07:37 GMT

It might be useful to re-open the subject of Document Scanning: [1] Where should the document objects be stored (PACS vs RIS), and [2] What would be the best file format for the scanned document object?

A number of radiology departments with PACS are currently managing scanned document objects in the PACS. Many of these PACS are managing the document objects as a DICOM Secondary Capture objects and storing the objects as a new series in the study file. This makes it easy for the radiologist to access and view the document along with the images. This also assures that documents can be migrated along with the study data, whenever necessary.

One of the problems with this method includes having to accommodate this new study series (document objects) in pre-existing hanging protocols. Another problem is the fact that all of these document objects subsequently travel everywhere the study file travels, ending up on display screens all over the enterprise.

Comments in favor of or against this approach are welcomed.

Michael J. Gray: Pitfalls

Document dilemma