Thursday, April 3, 2014

IOCM, critical to synchronize a VNA with your PACS.

One of the most common complaints and challenges is how to keep the Vendor Neutral Archive (VNA) synchronized with a PACS system, particularly, with making sure that deletions and modifications made within the PACS are executed within the VNA as well. As a matter of fact, one of my PACS students recently complained and told me that her workload almost doubled because of the recent VNA implementation as she has to make all changes, updates and deletions twice, once at the main PACS and second at the VNA. One could argue that this is not a “level 5” VNA as defined here (add link), but, rather a partial and limited VNA implementation without any automated coordination between the PACS and VNA. Even if it were implemented, in what is commonly done in a proprietary manner, a standard implementation would be much better.

Implementing the IOCM, or Imaging Object Change Management profile as defined by IHE by both the VNA and PACS systems should largely address the synchronization issue and provide a standards based solution. The IOCM profile does not specifically name a VNA or PACS, but, rather addresses the need to synchronize whenever images need to be shared between a local and other systems i.e. anytime multiple copies of the same image or other DICOM objects are available. This can be the case when copies are stored on a VNA, an EMR, or any enterprise or regional repository. IOCM addresses the following use cases, i.e. when a user needs to:
·         Correct and/or update demographic information for images and other DICOM objects
·         Split or combine studies, which is mostly due to incorrect Modality Worklist item selection
·         Remove “bad” images, for example, when they are incorrectly labeled (such as an incorrect Left/Right indicator)
·         Permanently delete old imaging instances or entire studies as may be required by institutional record retention policies (typically after seven years).

The combination of needing to distribute copies of images and needing to modify them leads to copies, which are inconsistent, and in turn creates the potential for confusion, error or loss of data.
The IOCM integration profile supports the following three change management use cases:
·         Data retention expiration
·         Correction or rejection of instances for quality or patient safety reasons
·         Correction of modality work list selection

If you are interested how this works, it is important to realize how IHE profiles are defined. IHE profiles include so-called actors, which have a well-defined role and function, and the transactions between these actors. Examples of existing actors are the image manager (database) and image archive, which both provide the core of any PACS or VNA. The IOCM profile defines a new actor: Change Requester. This actor can be grouped with existing actors that manage these objects and that have the ability to apply changes to existing imaging objects, in order to support IOCM. The Change Requester would, for example, be resident at a PACS system, which can then communicate with a VNA, to communicate any updates and changes.
The information is exchanged using a DICOM Key Object Selection Document, aka a “rejection note.” This is a special case DICOM structured report (SR). SR’s are typically used when there is a need to communicate information about images such as which ones are Key Images, where and what type of measurements or CAD results are available, and other applications, hence it is a perfect template for these rejection notes as well.
In addition to the IOCM rejection note, there could also be transactions used that include any modified replacement images, and in case there was an issue with an incorrect patient selection, one could use the so-called Instance Availability Notification to communicate this information with the department scheduler.
In the case of my overworked PACS student, I only hope for her that her VNA vendor is taking notice of this new profile and starts implementing and/or upgrading its system. This assumes that the PACS vendors do this as well, otherwise the VNA does not have anyone to listen to, but I assume they will follow suit soon.

No comments:

Post a Comment