Standards Watch | IHE Radiology Integration Profiles: What To Ask For

The Integrating the Healthcare Enterprise (IHE) activity seems to be at the same stage as DICOM was several years ago: Most people knew at that time to ask for DICOM compatibility when purchasing a new device. However, they did not know enough about DICOM to recognize that a DICOM print command would not get your images from a modality to the PACS; that support of the DICOM image quality standard was the only guarantee to make sure images on the CR workstation would match the look of the images on the printer and PACS workstation; and that modality worklist support was a requirement to guarantee image information integrity. So, through consistent education and promotion during meetings such as RSNA, many people now know to ask for IHE support. However, the problems with IHE compliance are similar to those with DICOM in its early stages — there are 14 different profiles available in the 2005 specification alone for radiology, and another six are available as drafts. As a user, there is, first, the challenge to understand all the profiles and, second, how to prioritize among them.

In this article, let’s go through the first set of profiles and explain their functionality

1. Workflow profiles

These profiles are generic, that is, they apply to the basic workflow to conduct an exam, perform postprocessing, create the reporting, and bill for the procedure.

1.1. The Scheduled Workflow (SWF) integration profile establishes a seamless flow of information that supports a patient care workflow for a typical imaging procedure. It specifies transactions that maintain the consistency of both the requisition and patient information from registration through ordering, scheduling, imaging acquisition, storage, and viewing. Systems involved in this profile are:

• Enterprisewide information systems that manage patient registration and services ordering. This is typically the HIS but also could be taken care of by the RIS
• Radiology department information systems that manage department scheduling, such as a RIS
• Acquisition modalities
• Image management and archiving, such as a PACS

This profile is unquestionably the most important one. It also serves as the basis for other specialties such as cardiology, eye care, and others still to be defined. It includes HL7 as well as DICOM transactions between the HIS/RIS modalities and PACS. Supporting this profile has also a major impact on the workflow because of features such as procedure updates and completed status from the modality back to the RIS and PACS, supporting Storage Commitment to transfer responsibility, etc.

1.2. The Postprocessing Workflow (PWF) integration profile addresses the need to schedule and track the status of the steps of the typical postprocessing workflow, such as CAD or image processing. Worklists for each of these tasks are generated and can be queried, work items can be selected, and task status returned from the system performing the work to the system managing the work.

This profile uses the DICOM General Purpose Worklist, a feature that does not have widespread support. Storage Commitment support from a workstation to the PACS does make sense, though. Unless the DICOM workstation worklist get wider support, this profile should not be a high priority.

1.3. The Reporting Workflow (RWF) integration profile addresses the need to schedule and track the status of the steps of the typical report workflow. Worklists are generated and can be queried, work items can be selected, and the resulting status returned from the system performing the work to the system managing the work.

This profile is very similar to the postprocessing integration profile and also uses the DICOM general-purpose worklist, a feature that does not have widespread support. Also note that the reports are assumed to be in DICOM format, which is not often the case.

1.4. The Charge Posting (CHG) integration profile specifies the exchange of information related to charges among departmental systems, enterprisewide information systems, and billing systems. Departmental systems provide billing with precise information about procedures performed, while enterprisewide information systems provide information about patient demographics, accounts, insurance, and guarantors. The exchange provides all of the procedure data required to generate a claim, resulting in more complete, timely, and accurate billing.

This profile makes sense because it closes the loop to get proper billing information. It uses the actual performed procedure information to make sure charges reflect what actually was performed. It could be viewed as an extension of the Scheduled Workflow profile.

2. Workflow exception profiles

There might be exceptions to the general workflow profiles because of trauma cases and specific complex procedures.

2.1. The Patient Information Reconciliation (PIR) integration profile extends Scheduled Workflow by providing the means to match images acquired for an unidentified patient (e.g., during a trauma case) with the patient’s registration and order history. This allows subsequent reconciliation of the patient record with images acquired (either without a prior registration or under a generic registration) before the patient’s identity could be determined.

The same actors/systems that are involved with Scheduled Workflow are also involved here. If you already have Scheduled Workflow implemented then this is a simple extension (i.e., providing a so-called HL7 Patient Update transaction back to the RIS). Based on the fact that the work is relatively minor and the workflow impact high (no manual reentry required), this is also highly recommended to support.

2.2. The Presentation of Grouped Procedures (PGP) integration profile addresses the complex information management problems entailed when information for multiple procedures is obtained in a single acquisition step (e.g., CT of the chest, abdomen, and pelvis). PGP provides the capability to view image subsets resulting from a single acquisition and relate each image subset to a different requested procedure. A single acquired image set is produced, but the combined use of scheduled workflow and consistent presentation of images transactions allows separate viewing and interpretation of the subset of images related to each requested procedure.

This profile is somewhat controversial. Some vendors and users actually argue that a radiologist should always look at the complete study, and splitting them up does not make sense. Some institutions require studies to be split up to make subsets available for different specialists. Some institutions train their staff so that they know that the images for the “abdomen” are always under “head.” In any case, using the presentation state information to convey this seems to be somewhat farfetched, and support in practice is not widespread. The problem with scheduling, acquisition, and reporting/billing mismatch has to be addressed; however, whether this profile is the best answer remains to be seen.

3. Modality-specific profiles

Some modalities have very specific workflow or presentation requirements.

3.1. The nuclear medicine (NM) integration profile is geared toward the storage and display of NM images, which includes the basic display capabilities of these devices. It also includes recommendations for static and dynamic result screens.

Anyone who wants to integrate NM in their PACS should require the support of this profile for their PACS and its modalities; otherwise, the chance for proper handling of these images is slim based on previous experience.

The following profiles are new and are set to be incorporated this year:

3.2. The Cardiac Nuclear Medicine (CNM; draft) integration profile adds specific requirements for stress tests that generally are acquired for cardiac imaging. The original NM is now called “general NM.” This profile includes selection, sorting, and viewing requirements and specifies what exactly should be in the DICOM header as well for the specific exam types.

Anyone that is considering integrating cardiac NM imaging should require the support of this profile.

3.3. The Mammography (MAMMO; draft) image profile specifies how acquisition modalities should store full-field digital mammography images, how CAD systems act as evidence creators, and how image displays should retrieve and make use of images and CAD results. It defines the basic display capabilities that image displays are expected to provide and which attributes should be used to implement those capabilities. The profile also addresses workflow related to the acquisition and reporting of digital mammography images.

Digital mammography interoperability has been spotty at best, especially among different acquisition and display vendors. Even though many vendors are still in the process of implementing this profile, this should be a definite requirement (if only for future support) for anyone implementing digital mammography.

3.4. The Evidence Document (ED) integration profile defines interoperability for observations, measurements, results, and other procedure details. This information is typically generated by workstations or modalities, managed by a PACS, and should be retrieved and displayed by viewing and reporting systems. This information is typically non-image but image-related and can have several different appearances, but are mostly measurements and CAD output. These results need to be properly integrated into the workflow.

To the extent that a user is integrating CAD systems or other devices that produce structured reports (e.g., for ultrasound or cardiology), this profile is useful.

4. Radiology information management profiles

These profiles specify how information can be accessed, how specific images can be identified, and how simple reports and measurements can be generated.

4.1. The Access to Radiology Information (ARI) integration profile specifies support of a number of query transactions providing access to radiology information, including images and related reports. Such access is useful both to the radiology department and to other departments such as pathology, surgery, and oncology. Non-radiology information (such as lab reports) may also be accessed if made available in DICOM format.

Almost all PACS products make previous reports available on a workstation. This profile, however, requires the reports to be available in a DICOM-structured report format, which would require them to be converted, if not available in that format, to the DICOM format. This profile is only usable if the reports are in DICOM format, which is by far the minority of PACS implementations.

4.2. The Key Image Note (KIN) integration profile specifies a transaction that enables a user to flag as significant one or more images in a study by referencing them in a note linked with the study. This note includes a title stating the purpose of the flagged images and a user comment field. These notes will be properly stored, archived, and displayed as the images move among systems that support the profile. Physicians may attach key image notes to images for a variety of purposes: referring physician access, teaching files selection, consultation with other departments, and image quality issues, to name a few.

Key images are an important feature, and the support of this profile, instead of the many proprietary solutions that have been around, is relatively simple and therefore definitely recommended.

4.3. The Simple Image and Numeric Report (SINR) integration profile facilitates the growing use of digital dictation, voice recognition, and specialized reporting packages by separating the functions of reporting into discrete actors for creation, management, storage, and viewing. This enables a vendor to include one or more of these functions in an actual system by separating these functions while defining transactions to exchange the reports between them.

The reports exchanged are encoded as DICOM structured reports and have a simple structure: a title; an observation context; and one or more sections each with a heading, text, image references, and, optionally, coded measurements. Some elements can also be coded to facilitate computer searches. Such reports can be input to the formal radiology report, thus avoiding reentry of information.

Although this profile is very useful, its use is limited because it only applies to the exchange of DICOM-structured reports. Reports are in practice generally encoded as HL7 messages, which is not covered by this profile. Its use is therefore very limited.

In the next article of this series (online in December), we will go through the second set of profiles that are critical. Remember, it is important to prioritize IHE profile support to optimize resources and impact.

Herman Oosterwijk is president of OTech, provider of PACS training classes and study resources.