Monday, April 15, 2013

Top ten things to consider when replacing your PACS system.

Many institutions are at a point where they need to replace their PACS systems, which for several, means changing the vendor as well. There can be multiple reasons for changing vendors ranging from being unhappy with the current vendor’s service level, to missing PACS functionality and/or reliability. In many cases, the reason may be because the hospital corporate headquarters decides to single-source all of their imaging equipment from a different vendor. This often occurs when a hospital is acquired and the corporate office wants to have a single vendor to improve information exchange between the institutions. In the rare case that one is not replacing a PACS system, but rather, buying a new one for the first time, most of the recommendations listed below equally apply.

When replacing a PACS system, it is highly recommended that you consider revisiting the fundamental image and information system architecture and workflow, as this is a prime opportunity to redesign it. In particular, one should consider the following:

1.       Use a Vendor Neutral Archive (VNA) – To avoid multiple data migrations in the future, it is strongly recommended that you disconnect the PACS database or image manager from its archive and use a different vendor for the archive from the PACS vendor. It is possible to purchase a VNA from the same vendor as the PACS; however, it is very hard if not impossible to prove that they are not very tightly coupled. For example, some vendors do not physically delete images from the archive but, rather only set a deletion flag in the database, which is not acceptable. The reason is that if one ever is going to migrate the archived images to a different vendor, the deletion-flagged images will almost certainly re-appear. One could argue that deletion of images is not a common scenario, however, it is necessary if the age of the images is past the retention rules, or if they are simply incorrectly labeled or have no diagnostic value. Regardless, just for the sake of being able to go with other vendors in the future without massive, lengthy and costly data migrations, a VNA from a different vendor makes every sense in the world.

2.       Consider an enterprise PACS solution – Another major advantage of using a VNA is that it allows a relatively easy transition to connect multiple PACS systems from several departments. The first one on the list is cardiology, however, this is probably also the most complicated as cardiology requires storage of not only images but waveforms and electrophysiological data as well. Other specialties ranging from gastroenterology to dermatology or dentistry have a need to archive MPEG files in addition to JPEG static images. A “true” VNA should be able to take care of these additional image format storage requirements.

3.       Determine what information should be migrated – Many PACS systems store so-called key image information and annotations in the database instead of encoding this as a DICOM object that can be migrated. It is possible to decode this vendor-proprietary information and create new DICOM objects, however, this goes beyond a “simple” migration and can become quite involved and costly. Therefore, one should decide what information is clinically important and critical, which depends on how the previous PACS system was used. For example, the chance that a five-year-old study is going to be retrieved is small to start with, and if a measurement resulting in an annotation has to be redone, that might not be a big deal. However, if technologists were using annotations to correct left and right positioning indications, this has to be recovered and recreated. In addition, migrating is a good time to revisit retention rules to avoid migrating information that exceeds the retention requirement. Lastly, some PACS systems store diagnostic reports, some don’t. If the new PACS doesn’t and if the old PACS does, these have to be either migrated from the old PACS to a RIS or EMR.

4.       Revisit document management – Many institutional systems have been scanning documents such as requisitions, release forms, and anything that was part of an order, as a DICOM object which is stored with the images. This made a lot of sense when the only access to electronic information for a radiologist was the PACS workstation. However, as most institutions can be expected to either have an EMR, or be in the process of installing one this year, it does not make sense to continue this practice, as it can be kept in the EMR. In addition, some of these documents, such as the requisition, should be available as an electronic order in the EMR, which includes the reason for the study and clinical history in electronic format, eliminating the need to scan requisitions.

5.       Phase out CD import and export – Burning CDs and importing images from them has become a logistical issue in addition to the fact that some CD’s are still created with image resolutions that simply have no diagnostic value such as simple JPEG’s, or are stored in a proprietary format. There are other options for importing and exporting images using file sharing or cloud services, some of those provided by the PACS vendor, some of them provided by a third party. Eventually, images will be exchanged through Health Information Exchanges (HIE’s), therefore, using a file-sharing service may serve as a logical step into that direction.

6.       Apply rules learned from IHE scheduled workflow – I am convinced that the majority of PACS systems don’t fully use the IHE scheduled workflow features, and thus do not take advantage of the efficiency and workflow benefits of those features. In particular, implementing a Modality Performed Procedure Step (MPPS) allows modalities to exchange exam status, the image count, and procedure changes with PACS and RIS, but MPPS has been sparsely implemented. Changing a PACS system is a good opportunity to review the bidirectional RIS/PACS interfaces and activate DICOM MPPS as well as Storage Commitment at all of the modalities. Storage Commitment (handing off archive responsibility) should be implemented between the PACS and VNA anyway to prevent information loss.

7.       Look beyond RIS/PACS to EMR/PACS – RIS systems might become obsolete as sophisticated Computerized Physician Order Entry (CPOE) systems are becoming available as part of an EMR. A radiology department would still need software to manage its resources, finance, supplies, and other typical department management items, however, the traditional RIS features that include ordering, scheduling and report management and distribution can be centralized in an EMR. An integration of a PACS with an EMR on the front-end might make more sense than integrating it with a RIS. If nothing else, a plan to phase out the RIS should be part of the PACS replacement objectives.

8.       Revisit the enterprise imaging solution – Images from the PACS have been made available throughout the enterprise by using web-servers that were part of the PACS system. However, when all images are going to be available at a VNA or enterprise archive, it makes more sense to have a viewer connected to the VNA instead of to the PACS. Most VNA’s support a web version of DICOM called WADO (Web Access to DICOM Objects) and there is actually a newly defined IHE profile that specifies how plug-ins would work with EMR’s (see for more information). A temporary solution is for the EMR to have a PACS “plug-in,” which allows the EMR access to the primary PACS archive, however, one should design the system architecture to eventually get the images from the VNA.

9.       Make sure there is support for all recent DICOM enhancements – There is a new generation of DICOM objects, which I refer to as DICOM 4.0, which are based on multi-dimensional object definitions with DICOM headers that are much richer, better defined and encoded. This family of so-called DICOM SOP Classes includes the enhanced MR and CT, and the new digital mammography, tomosynthesis. There are even new versions for cardiology, angio and RF. Instead of having to use dedicated modality workstations to view these new DICOM SOP Classes, one should make sure that there is support for them in the new PACS system. Other groups of SOP Classes are the Structured Reports that encode ultrasound measurements and CAD results, which should be supported and interpreted as well as displayed correctly. Lastly, there is an increasing demand to record dose information in the form of DICOM Structured Reports, which have to be managed in a PACS, i.e. recorded and exchanged.

10.   Consider the cloud – Outsourcing storage might make sense for some institutions, depending on available in-house IT resources. Concern about privacy, security and availability, and whether or not the information is considered to be of such an important strategic asset may be reasons that an institution would want to keep it in-house. If for no other reason, one should consider maintaining a copy of the data in the cloud to provide disaster recovery. If there are concerns with security, organizations could consider creating their own clouds, which is rather common for either large geographical areas (e.g. in Canadian provinces), or for large provider groups. For a small institution that does not have any affiliations, a commercially available cloud service might make sense.

In conclusion, replacing a PACS with the same or different vendor without redesigning the architecture of the system would be a major lost opportunity. It is strongly recommended that you review the current architecture, workflow and standards support, i.e. how open the system is and how it can be improved, to make sure the new system can serve the next generation of hardware and software.

Monday, April 1, 2013

The most common DICOM connectivity problems.

The most common DICOM connectivity errors are related to addressing issues and/or a mismatching of the negotiated capabilities. Addressing issues can be categorized as follows:

  • IP address issues The IP address might be incorrectly configured, or DHCP has created a new IP address different from the one that is used in the configuration file. One of the quirks with DICOM connections is its reliance on fixed IP addresses, which shows that it was defined in the early 1990’s, prior to the popularity of dynamic IP addressing. Any router can be configured to assign a fixed IP address, but IT maintenance or replacement of the router without reconfiguring can assign a new IP address to a host, which causes the fixed IP settings in the DICOM devices to be incorrect. Using the ping feature will allow a simple check of the availability and configuration of the IP address.
  •  Net mask or domain incorrect − Although the IP address can be correctly configured, if the domain or net mask settings do not match between the source and destination, there will be no communication. Checking the settings at both the destination and source will show if there are any discrepancies.
  • Port number incorrect − The initial port number that was commonly used was port 104, however this caused problems in some devices that did not allow low numbers to be assigned. The correct port number to be used instead is 11112, which is officially assigned to DICOM by the Internet Assigned Numbers Authority (IANA). Mismatching port numbers will show up in a sniffer log as multiple “SYN/ACK” sequences that cannot be resolved.
  • AE Title Incorrect − Note that AE-Titles are case-sensitive, which is probably the most common error made. Mismatching AE-title errors can easily be identified by a sniffer or DICOM error log as it is a standard status code.
  • Firewalls − Many computers and routers have firewalls configured. Make sure that the applicable ports are open.

The DICOM Association has always negotiated between devices using a specific presentation context which consists of an abstract syntax and one or more transfer syntaxes. An example of an abstract syntax is the CT Image Storage SOP Class. An example of a transfer syntax might be JPEG compression. If a proposed presentation context does not match the capabilities at the destination, the message that comes back will indicate a complete or partial rejection of the association. Examples of new SOP Classes that might not be supported are Dose structured reports (SR) from a CT, comprehensive structured reports containing measurements from an ultrasound, CAD results, or new image SOP Classes such as the enhanced CT, MR or digital mammography or tomosynthesis images.

These errors are easy to simulate by using a modality simulator that has the capability of sending exactly the same presentation contexts and investigating the log files and sniffer logs. The resolution is for the destination to be upgraded to support the new SOP classes or having a service engineer simply adding this to the configuration. Another option is to “downgrade” the SOP classes at the source, for example, instead of a CAD result or ultrasound measurement in a SR, send the information in a screen capture, or send the images in the “old” format.

New transfer syntaxes, which are often lacking, are MPEG for video clips, and new wavelet compression techniques. The solution is also upgrading the destination or downgrading the source.

In conclusion, with the right tools, it is relatively easy to visualize the reason why a DICOM connection cannot be made. A visual presentation on using the tools and how the data would look is available on YouTube, see link.