IMPAX 6.5.1 Server Knowledge Base home > Configuring IMPAX Server with Administration Tools > Network Management > Configuring communication settings for stations

Understanding how IMPAX handles duplicate SOP Instance UIDs

When IMPAX receives images with SOP Instance UIDs that already exist in its database, the following happens:

Note:

Note:

If you suspect studies with potential SOP Instance UID conflicts exist, to find any reassignment records, query the dosr_uid_mapping table by study_ref.

Conditions under which a new SOP Instance UID is generated

The following illustrates a workflow that causes IMPAX to generate a new SOP instance UID:

  1. The technician sends an image to IMPAX with a SOP Instance UID of 1.2.3.4 that belongs to study accession number AAA111.

  2. The technician realizes that the image actually belongs to another study with a study accession number of BBB222 and sends another copy of the same image (SOP Instance UID 1.2.3.4), under the correct accession number (BBB222) to IMPAX.

  3. IMPAX recognizes that the SOP Instance UID already exists in its database, but because the study accession number is new, IMPAX reassigns the image’s SOP Instance UID to 5.6.7.8.

    The image exists twice in IMPAX: Once under accession number AAA111 with SOP Instance UID 1.2.3.4 and once under accession number BBB222 with SOP Instance UID 5.6.7.8

CAUTION!

CAUTION!

Correcting the study information and resending the images does not remove the incorrectly identified images from IMPAX. When a new SOP Instance UID is assigned, the previous copy of the image is not deleted; it still exists in IMPAX under an incorrect accession number. To prevent misdiagnosis, modality technicians must ensure that incorrectly identified images are deleted from IMPAX as soon as possible.


See also


Topic number: 8993

Applies to: IMPAX 6.5.1 Server Knowledge Base