Part 2 – Separation of apps and data – the DICOM media interface

The first blog post of this series discussed the new operational problem for PACS admins – replacement of an older PACS and migration to a new system. This post will discuss the system architecture for a solution.

Let’s first acknowledge that the image data has more value and permanence than the PACS application, otherwise, why would we be willing to replace the PACS and keep the data? For such a data-primary system there is a basic software design principle to cleanly separate the apps with their “business logic” (in our case the PACS and radiology workflow management) from the data storage (the DICOM images). Such a separation is essential to ensure system management appropriately focuses on both the apps and the data, and to cost-effectively enable operations such as PACS replacement without having to rejigger the stored image data.

Note that when PACS application logic is cleanly separated from the data stored in the archive, it confirms that the data is owned by the healthcare organization. The data is separated from reliance on a PACS that will eventually become obsolescent, or that may be subject to failure. And here I am not only talking about software or hardware failure, but also about business failure, including license expiration or a vendor going out of business. The PACS (and its vendor) should not be able to hold the imaging archive data hostage through proprietary storage mechanisms.

In order to keep the data in place and be able to replace the PACS front end with a new front end, we need the data to be stored in a standard file format with a standard interface to the PACS application. In fact, DICOM already has such an interface standardized in the context of a small file set shared between apps, the well-known DICOM format for exchanged media such as CDs (formally the Media Storage Service Class, and informally called Part 10). DICOM media exchange has a well-defined separation of apps and data, as it specifies only the data storage, and allows a variety of different apps to read and use that data.

The DICOM media service interface is actually composed of several related standards. These include a standard file format, a file index (DICOMDIR), canonical file system I/O operations, standardized linkage to file systems and media, and application profiles tying together the various options for specific uses. PACS data storage would be a new application profile.

While the conceptual principles and the structure established by the DICOM for media services is readily reusable, we would need some enhancements to account for the scale of an entire institutional image archive. Rather than sending a file set representing an extract of the archive (typically for a single patient) from one PACS to another, we would in effect be sending the entire archive from one PACS to another – although in fact the data is staying in place and the new PACS is moving in on top.

However, just having the PACS store the images in DICOM compliant files does not make PACS replacement easy, it just eases the significant pain associated with having to move the images. One of the major activities will be constructing the database for the new PACS, which will be discussed in the next blog post.

Harry Solomon is an interoperability consultant for Laitek, Inc., and past Co-Chair of the DICOM Standards Committee. He has been involved in the development of DICOM since 1993, and has taught graduate courses in healthcare interoperability and standards at Northwestern University and at Oregon Health & Science University.