Structured Report for VNA synchronization (part 3 of DICOM SR series).

There is one category of Structured Reports (SR) that I really haven’t covered in the previous two

parts and that concerns “specialized” SR’s. The content of each structured report is defined by its reference to a so-called template using a DICOM defined template ID, for example, TID 5000 is used to encode an ultrasound OB/GYN procedure report. There is a complete list of those templates in part 16 of the DICOM standard.

For the so-called “generic” SR’s such as used for ultrasound measurements, the template ID is specified in the DICOM header so that the receiver knows how to interpret the information. The corresponding SR documents or DICOM objects are identified in a workstation worklist with the modality defined term of “SR”.

What I refer to as specialized SR’s encode the used template as part of the so-called SOP Class such as used for Key Images and Computer Aided Diagnosis (CAD), similar to the ones used for Dose reporting. The advantage of supporting a specialized SOP Class is that when the DICOM connection (association) is being established, the receiver can determine if it supports this particular type of data structure and if not, reject the proposed information exchange.

An example of such a specialized SR is the key image, formally called the “Key Object Selection Document,” which is used to identify what image of a study is significant or important. It is of great help for example, when the a study is quite large, let’s say a 3000 slice whole body CT scan, and the radiologist wants to identify which images contain a significant finding so that a referring physician or specialist such as a surgeon does not have to flip through all of the images, but merely selects the most important or “key” ones. This SR is identified with “KO” as the defined term for the modality, which is how it shows up in a workstation worklist.

Not only can the KO SR be used to identify a target audience such as a referring provider or surgeon, it also can be used to synchronize two image management, storage and archiving systems such as a PACS and Vendor Neutral Archive (VNA). This addresses the fact that changes and deletions are unavoidable, for example, if an image was misidentified (e.g. the incorrect orientation), has a replacement image with better quality or has patient demographic errors. 

A PACS system administrator (SA) typically updates and corrects these types of issues at the PACS “back-end,” or, if trained properly technologists might fix their own study mistakes. Imagine that the images are managed at different locations such as in the PACS and VNA or even cloud storage, the PACS SA has to do the correction work multiple times. This is one of the most common complaints I hear from the early VNA adopters, i.e. that it doubles the work load as the number of unverified or broken studies to be fixed is duplicated at the PACS and VNA.

The Integrating the Healthcare Enterprise (IHE) profile that deals with this issue, called IOCM or Imaging Object Change Management profile specifies exactly this, addressing the following scenarios:

§  Data Retention Expiration

§  Correction or Rejection of imaging instances for Quality Reasons

§  Correction or Rejection of imaging instances for Patient Safety Reasons

§  Correction of Modality Worklist Selection

A KO object will be created by the change initiator so that they can automatically be forwarded to all locations that have a copy of the image to be corrected. The work only needs to be done once. Unfortunately, support of this profile by PACS vendors is spotty at best; hopefully this will change as VNA’s and enterprise archiving solutions are becoming more mainstream. Implementation is relatively simple, but of course, it needs to be tested, verified, and requires most likely an upgrade of your PACS software. Knowing that some of the PACS installations are running 3-5 years behind their latest software upgrades, support is likely not there (yet). Your DICOM conformance statement, which you should be able to download from the web will specify it, look for the “Key Object selection Document Storage” support and make sure that the applicable codes to specify the reason for the changes are supported, or, better, look for the support of the IOCM IHE profile.

More information can be found at the DICOM website, IHE website, and OTpedia as the resource for DICOM and PACS terminology. Otech also has a PACS, DICOM and IHE Core essentials class coming up in July which is online so you can follow this from your own desk at your own location, see the OTech training schedule.