With the trend toward Enterprise Imaging, studies become distributed across multiple PACS and on a central archive (VNA). Inconsistencies between archives emerge when one system applies a change, such as to correct, coerce, or update patient demographics. Before delving into the question posed in the title about the role of the IHE Imaging Object Change Management (IOCM) Integration Profile, consider the use cases for modifications in the context of the study’s lifecycle.

Between the start the procedure to the completion of primary interpretation, a typical scenario may include several activities: the acquisition modality images the patient; a technologist or process may create image-derived findings and store them in a Structured Report; a technologist may review images at a QA workstation to check for image quality, adjust presentation, and if needed, correct metadata and labeling errors such as laterality, procedure context, and patient identity. As the physician reads the Study and creates the report, additional objects may enter the Study such as image annotations and Key Objects that identify clinically significant images.

During this phase, mistakes happen and must be corrected. Uncorrected mistakes can affect patient safety or interrupt workflow. Scrutiny by clinical staff and quality procedures prevent risk of erroneous data entering downstream workflow, through a central archive and into another PACS. A mechanism for the technologist to corrects mistakes in objects sent to the PACS is a primary IOCM use case.

After interpretation, during ongoing patient care, the need to modify historical studies is infrequent; and the motivations to do so are very different. Some PACS apply local metadata localizations to optimize local workflow and products. Metadata may change when a Study transits from one PACS to another. As shown in the figure below, PACS Y applies some change to Study A from PACS X. Such changes are not corrections, and not really inconsistencies either. Normally a site would not intend to reflect such changes back to the origin of the Study. Nor, would a site intend that the second, localized copy (Study A’) replace the Study in the central archive. Studies arriving at a central archive via multiple paths is likely an avoidable complexity. Other variations of this scenario may occur when importing foreign exams. These types of inconsistency are intended, tolerable, or otherwise preventable.

At expiration of retention period studies can be purged from the archives within the enterprise. A mechanism to communicate expiration is another IOCM use case.

IOCM in a nutshell

As described earlier, during the imaging procedure the probability of errors is significant, and the potential impact of uncorrected data can be severe. The urgent need was a way to delete and replace erroneous objects sent to a PACS. Below are the IOCM use cases as excerpted from the IHE Radiology Technical Framework:

“The supported changes include (1) object rejection due to quality or patient safety reasons, (2) correction of incorrect modality worklist entry selection, and (3) expiration of objects due to data retention requirements. It defines how changes are captured and how to communicate these changes.” – IHE Technical Framework RAD Vol 1 TF-2.1.26 Imaging Object Change Management (IOCM)

The first two cases correct errors during the imaging procedure, and the third facilitates purging studies for image lifecycle management across multiple archives. The scope of IOCM did not include changing historical studies in ongoing patient care.

IOCM needed a DICOM mechanism to delete an incorrect stored object. The DICOM Key Object Selection SOP Class already provided a way to identify poor quality or mislabeled images (DICOM Supplement 59 and Change Proposal 885). So DICOM added document titles for “patient safety” and “incorrect worklist” so that Key Objects can act as “Rejection Notes” (DICOM Change Proposal 1152). IOCM defined a Change Requester actor, typically grouped with the Acquisition Modality or Evidence Creator, which sends the Rejection Note to the Image Manager/Archive actor. According to IOCM rules, actors that receive these objects, including Image Display actors, must hide them. Subsequently, the Change Requester can send the corrected objects to replace rejected objects. In the case of image quality, it is a configurable policy to completely hide these objects or to keep them for clinical or quality control purpose.

Note that corrections may incur risks such as breaking referential integrity of objects referring to other objects, notably GSPS, SR, and Key Image Notes. IOCM provides rules and guidance to the Change Requester (an Acquisition Modality or Evidence Creator). IOCM does not require the archive to correct broken referential integrity. (IHE Technical Framework RAD Vol 3 4.74.4.1.2.2 Maintenance of Instance Referential Integrity)

Relevance to consistency between PACS and archive

In theory, this model of a Change Requestor sending Rejection Notes and replacement objects to an Image Manager/Archive could propagate modifications to objects in connected archives. There has been misunderstanding about IOCM propagating patient demographic changes. However, the IHE has integration profiles for patient demographics use cases, so IOCM states that the Change Requester model shall not be used this way. (IHE TF Vol1 28.3 IHE Patient Information Reconciliation (PIR) uses HL7 ADT to broadcast patient identity changes)

The name of this IHE Integration Profile-Imaging Object Change Management-does suggest that it may tackle consistency problems. Indeed, the original proposal to the IHE back in 2009 alluded to resolving inconsistency between a central archive and local PACS. IOCM dropped this use case. Later, a Shared Study Management proposal was presented to the IHE but was not selected for development.

What can be done to resolve inconsistency?

Manufacturers have implemented their own approaches to address consistency problems, often going outside Standards: direct database connection or retired SOP Classes such as DICOM Study Content Notification and Detached Study Management.

To reconcile historical data between archives and PACS consider:

• What are the types of changes actually needed, and where do they fit into the workflow? Are there established IHE integration profiles to handle these changes such as IHE Patient Identity Reconciliation and other reconciliation workflow Integration Profiles?
• Who, or what products should authorize changes? Which products should honor those changes? Bidirectional changes are problematic. Consider the complexity, risks, and how to mitigate them. Keep it simple.
• If a vendor states they have a solution, examine the DICOM Conformance Statements of the interconnected products to understand and verify those products are consistent with intended change management.
• Are there risks, such as referential integrity? One cannot be sure what will happen to a viewing or other product when objects have broken referential integrity without testing.
• What are security aspects and audit message requirements?

One last thing to note about IOCM from a migration perspective: typically, the PACS or central archive flags the rejected objects in its database when receiving and interpreting rejection notes. The actual rejected object may or may not be deleted. This is something to keep in mind when migrating. Internal product implementations vary, so it is important to verify that the future migration and product adoption preserves IOCM related behavior.

Depending on reader interest, the problem of consistency between image archives may become a topic for a future blog article. If attending an upcoming RSNA, HIMSS, or SIIM, please drop by the Laitek booth to learn more.

 

Author Doug Sluis, PhD is a consultant on Quality & Interoperability for Laitek Inc. His experience includes software development, systems engineering, test automation, interoperability, industry standards for electronic medical records, and quality and regulatory compliance. Doug has spent decades developing and applying Standards (DICOM, IHE, coding systems) to enhance products and clinical information continuity within clinical workflow.