Month: August 2005

The latest buzz in the PACS world

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.

Test Server Shortfalls

I started reading a discussion thread last week on AuntMinnie.com dealing with downtime during PACS software upgrades. While reading comment after comment, I’m thinking about how test servers are intended to minimize that downtime. Then it occurs to me that there are very few PACS systems out there with Test Servers. First of all they are expensive if they are configured to test more than a few modalities and more than a few display stations, Secondly, there are some PACS vendors that do not even offer a Test Server.

A properly configured Test Server will be configured to accept all of the modality inputs and have a small Directory database and sufficient local storage to accommodate the studies that are acquired during the testing. You don’t want to add test studies to the primary PACS database. It will have two network interfaces, so it can be used when the primary network in undergoing periodic scheduled maintenance. It will include a HIS/RIS interface component, so that functionality can be tested. It will include all of the display applications. In short, the real Test Server is as close to being a mirror of the production server’s interfaces and applications as you can make it. That’s the point of it being a Test Server. On the other hand, the vendors should realize that a Test Server is just that, a Test Server. Placing it in service once a year to test a new release does not warrant pricing the software anywhere near that of the production server.

Even though a true Test Server is configured as close to a Production Server as possible, that does not necessarily make it a back-up server. The Test Server is typically configured on a much smaller, less robust server platform than the Production Server. A Test Server configured with sufficient horsepower to be a Business Continuity Sever would be considerably more expensive. A true Test Server and a Business Continuity Server differ primarily in the server hardware. While the concept of a Business Continuity Server is very valid in parts of the country that are at greater risk for natural disasters, most facilities would consider it a luxury. The true Test Server however, should be a requisite in every system.

Tackling the Exam Room Display

Consider marketing the use of CDís as the means of transferring study data from radiology to the referring physicianís office. All studies required for a dayís worth of office visits are ordered in advance and placed on one CD. The referring physicianís office staff transfers the studies from the CD to specific desktop or lap top computers in the offices and exam rooms. This strategy minimizes network complexity, eliminates time-consuming steps required to access studies, utilizes existing office workflow by assigning all time consuming tasks to the office staff.

Document dilemma

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.

Time for a check-up?

There are probably a few PACS out there that have yet to fulfill all of the expectations.

So how much time after “go-live” should it take to achieve the goals that were originally set? Is it time for a check up?

There ís probably nothing seriously wrong with the system, certainly not enough to suggest it should be replaced. Maybe there are just little things, details that can only come to light after you’re up and running. A year or more of run time is more than enough experience with the system. By now you should be very close to achieving that drop in film demand. You should know exactly what the problems are, and how you’re going to correct them. If not, maybe it’s time for a check-up.

Take a look at these check-up questions and test yourself with the answers.

Check-up questions

  1. How close are you to achieving the drop in film costs projected in those pre-PACS plans? Exactly what is keeping you from reaching that goal?
  2. How many of the true image users in the referral community are still asking for film? What are your current plans for correcting that?
  3. How close are you to eliminating the problems caused by paper in the workflow?
  4. Have you thought of more than five ways to use the CD?
  5. What can you do to reduce the report turnaround time even further?
  6. Have you been successful establishing a “virtual seat” for the Emergency Department and high-value outpatient studies?
  7. What features unique to PACS have your radiologists adopted in an effort to attract more referrals?
  8. Besides sticking a display in the ED, what have you done to improve the workflow between the Emergency Department and Radiology?
  9. Who spends more time per study on QC tasks, your technologists or the system administrator?
  10. What is your long-term plan for the inevitable data migration?

Take the check-up test yourself, and let me know what the results were when you took it.