Saturday, October 6, 2018

PACS troubleshooting tips and tricks series (part6): Unverified PACS cases.

In the last set of blog posts in this series I talked about network, addressing issues, incompatible file
types as well as transfer syntaxes and DICOM communication errors. This post deals with errors that might occur when there is a successful information transfer, however, the PACS determines that there are issues with the data that causes the file to be flagged as “Unverified” or “Broken.” This means that these images are NOT added to the queue to be interpreted by a radiologist. The following issues can occur –

·        Missing “exam complete” status – Some PACS systems will automatically add an incoming study to a radiologist’s worklist, some can be configured to do so, and some will require an “exam complete” status to be initiated. This exam complete can be entered at a radiology information system or an EMR by the technologist, which will typically cause a HL7 transaction to be sent to close out the order to the PACS. These updates could also be entered at the PACS, again, depending on the architecture.

It is possible to have this event automatically triggered at a modality by using MPPS (Modality Performed Procedure Step), however, there are relatively few institutions that make use of this feature, even though it is universally available at almost all digital modalities. Sometimes it is required to close out the study manually, for example, if the study requires loading additional information from a CD that is brought in by the patient, or requires additional processing and creation of derived images such as for using CAD or 3-D reconstructions.

Assuming that the PACS is configured to listen to the “exam complete” status, if this event is not issued because the technologist forgets to do so, or there is a communication error between the trigger initiator and PACS, it will cause the study to NOT appear on a worklist for interpretation.

·        Duplicate Identifier(s) – There are several important patient- and study-identifiers, which possibly can be duplicated or repeated for another study in error. The reasons for the duplication are incorrect manual entry, non-uniqueness, such as for the accession number and internal patient ID’s, especially when importing “foreign” studies, or due to software errors. The PACS core software will check for these situations because duplication will prevent them from uniquely identifying or indexing them for archiving and retrieval operations.

A special case occurs when the object number, aka SOP Instance UID, which is a Unique Identifier for that specific DICOM object, gets duplicated. The message “duplicate SUID” will typically occur. The SUID functions as a unique number, similar to a VIN number used for a car. Duplication can occur because of software errors, resending the same file twice to a destination or after a change is made in the file header. Different PACS systems might behave differently when receiving a duplicate SUID, some of them overwrite the original file, some of them will ignore them, and some might report the error causing an Unverified Study. One should never manually fix these SUID’s as uniqueness cannot be guaranteed, one should always use an off-line SUID generator in case these need to be fixed. If a “rogue” software implementation initiates duplicate UID’s on a regular basis for different objects, one could consider using a programmable router, which can be configured to create a new, unique number.

·        Missing identifier(s) – A missing identifier such as a Patient ID, Name, Accession Number, patient sex, birthdate, and several others will also cause an image to be Unverified. A user might actually use this behavior intentionally, for example by leaving an Accession Number blank when importing an external study, to allow it to be correctly and manually verified by a PACS system. The DICOM standard defines what information in the DICOM header has to be present, and a software application will typically flag when any of these are missing.

·        Exceeding length – Each data element in the header has, as part of its data type or VR (Value Representation) specification, an associated maximum length defined. Most of these are plenty, for example, the maximum length of a Patient Name is 64 characters which means that it will very rarely, if ever be exceeded. However, some of the attributes might be improperly used, such as including a long description in a field that is defined to have only 64 characters. Exceeding this maximum length could cause the object to be Unverified. If this is a common issue, one could use a DICOM router that can be configured to “fix” the header. This also might occur when migrating images to a new PACS where the old PACS did not care to identify this issue, and the new PACS would reject these cases as it interprets the DICOM standard more strictly than the initial source PACS.
·        Incorrect codes – Some of the DICOM data elements have defined terms that can be used that are identified by the DICOM standard as “enumerated values,” such as the value M, F and O (“Other”) for patient sex. If the initiating system, which can be an EMR or data entry system, has a different set of values for a certain data element, it can be rejected.

Fixing unverified studies provides the core of the work for many PACS administrators. Identifying the root cause and trying to prevent them will increase the data integrity of the system and relieve their jobs. There are routers that can fix chronic inconsistencies. Some PACS systems, especially those intended to be enterprise systems such as used by a VNA (Vendor Neutral Archive), can be configured to use “tag morphing” to fix the information. Tag morphing can also be used to clean up inconsistent study and series descriptions and/or body part identifiers. Note that some header issues could be unnoticed and are not flagged, which means that they only surface when someone tries to display the image or interpret the DICOM file. These errors, i.e. DICOM header issues will be covered in the next post.

Additional resources can be found in the DICOM textbook (ebook is available as well) and I also created a small DICOM/HL7 reference guide, which lists the DICOM data dictionary, UID’s and VR specifications.