Part 4 – Journaling updates in the Enhanced DICOMDIR

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. The second post discussed a system architecture for a solution based on a standard DICOM interface between a PACS front end and a DICOM compliant file set; this would allow the data to be transitioned to the new PACS without needing to move it. The third post discussed an Enhanced DICOMDIR for the archive file set, which could be used to create the database in the new PACS. This post addresses a challenging topic for interoperability of enterprise scale archives, the journaling of updates.

When patient demographics change, or procedure coding is updated, many PACS journal the changes in their databases, but do not propagate those changes into the stored DICOM objects. Rather, if and when such objects are retrieved, the journaled updates are applied at that time, either just to the outgoing data, or also to the objects that are then rewritten into the storage.

Historically, journaling is used when updating the storage is slow compared to the writing the journal. For PACS, this has been the case when using long latency archive media, such as tape or optical drives or remote file servers, or when there are many files to update, as with a 3000 slice CT study. For these, the database could immediately commit to the update transaction without needing to wait for the relatively slow archive media I/O. Even with fast storage, such as disk arrays or solid-state drives, there are still use cases for bulk updates where the time to propagate changes to all affected files would be extremely costly. Examples of these bulk updates include implementing a new patient ID scheme, or transitioning to a standard radiology coding system such as RadLex. A particularly important situation for patient ID bulk update is during merger of healthcare organizations, where archives are being consolidated under a single PACS. In all these cases, journaling the updates is an important technical mechanism supporting efficient archive operations when update of substantial numbers of objects is invoked.

In the storage architecture described in this blog series, support for journaled updates must be considered. For the reasons just cited, they are an integral part of the operational design of many PACSs, and it is unwise and unnecessary to require a change to that design. Journaled updates should be stored in the DICOM file set, such that an application that reads an object file must also read the journal and apply any relevant updates. While there are a number of different approaches that could be used, I would suggest that the Enhanced DICOMDIR file should also be the location for journaled update information.

An application accessing the archive file set directly, rather than through the PACS, navigates to the desired information by reading the Enhanced DICOMDIR, the index to the data set. By placing the journal in the Enhanced DICOMDIR, the application is provided with the necessary update information without needing to read another file. Moreover, since the Enhanced DICOMDIR is the standardized mirror of the PACS database, it would be logical for the PACS to update it when it updates its internal database to record the journaled updates.

There is, of course, a potential patient safety issue with a journaled update. When an application accesses the archive file set directly, there is no guarantee that it will check the journal, and hence may operate with incorrect or obsolete data. I would not want to minimize the seriousness of this concern, which deserves a full risk assessment (evaluation of probability of occurrence and severity of consequence), and development of necessary mitigation mechanisms for unacceptable risk. That is beyond the scope of this blog post, and is a task that will need to be performed in the DICOM Working Group that undertakes this proposal. But let us not forget that the current PACS architecture has its own patient safety concerns, which are addressed by a variety of mitigation strategies. In fact, separation of the data archive to a DICOM Standard file set may mitigate some of the risks inherent in PACS.

To summarize: I propose that to address the archive migration use case, DICOM should define a standard interface between the PACS and the archive date set based on the well-established DICOM Media Services, including an Enhanced DICOMDIR serving as the index, and that journaled updates be explicitly supported. In the next blog post I will address additional use cases that would be supported by this architecture.

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.