Issues Surrounding PACS Archiving to External, Third-Party DICOM Archives

Abstract

In larger health care imaging institutions, it is becoming increasingly obvious that separate image archives for every department are not cost effective or scalable. The solution is to have each department’s picture archiving communication system (PACS) have only a local cache, and archive to an enterprise archive that drives a universal clinical viewer. It sounds simple, but how many PACS can truly work with a third-party Integration of the Health Care Enterprise Compliant Image Archive? The answer is somewhat disappointing.

Background

As many health care providers are aware, in an era of declining reimbursements, the pressure to do more with less is irresistible. Sometimes, however, actions driven by necessity can prove beneficial. Such is the case in the following scenario.

Often an imaging department in the medical center has its own picture archiving communication system (PACS), with its own archive and clinical (web-based) viewer. Thus, if the Electronic Medical Record (EMR) is capable of synching patient/exam context to the various PACS clinical viewers, the EMR user is confronted with different viewers for every imaging exam the patient has had in different departments¹. Obviously, this can be a source of frustration as the user has to master multiple applications^2,3. Further, the enterprise is frustrated financially because it is paying for many small- to mid-size archives, with separate support contracts, rather than enjoying the economies of scale that one archive could provide, with central image management.

Another advantage of centralized image management is that it enables the possibility of any PACS to have enterprise comparison exams, even if some of those exams were acquired on different PACS^4,5. But some interesting issues arise in this case. A given PACS will not know about exams it did not perform, so it cannot pre-fetch them itself unless a migration occurs from the old PACS to the new. Clearly, this makes no sense for ad hoc consults between different PACS in a federated health care network. Rather, the PACS must query or accept pushes from the enterprise archive for all relevant comparisons, regardless of where they were acquired. But, how will a vended PACS recognize that a foreign exam is not new, but is in fact a comparison, and avoid putting that exam on the Unread worklist?

The preceding shows the inherent value in replacing permanent archives on each PACS with a small working cache, and ceding archiving of Radiology Information System (RIS)-finalized exams to a central Integration of the Health Care Enterprise (IHE) Image Archive with an attached clinical image viewer. But as we have seen, there can be challenges. Some of these are addressed in the following sections.

Methods: Modeling the Workflow¹

The time to assess the feasibility of a PACS to “work with” a centralized third-party Digital Imaging and Communications in Medicine (DICOM) archive is not after the purchasing contract has been signed, but rather as part of the contract negotiations. This is fair to both parties. The customer must announce to the vendor that part of the acceptance test will be validating the correct behavior of PACS with a third-party Image Archive, and the vendor needs to be able to estimate the billable work required to accommodate the requirement.

But what exactly do we mean by “work with” a third-party DICOM archive? First, we expect the vendor has not merely strung a point to point fiber or copper cable to a third-party storage cabinet. Rather, we mean that the PACS and the archive could be miles apart, that the archive will have both multiple inputs and outputs (from/to many departments), and the communication is via DICOM standards over TCP/IP.

At this point, many vendors will offer that they can perform a DICOM C-STORE to the third-party Archive and assume that is sufficient. But that is not what we mean either. To take a single example, if a PACS is archiving to a third-party archive, then it must support DICOM Store-Commit as a Service Class User (SCU), not a Service Class Provider. This simple adjustment is quite rare among vended PACS. Of course, it should be noted that this fault lies partly in DICOM and IHE. DICOM Workgroup 6 explicitly defined Storage Commit as used between a modality and an image storage system for the purpose of storage release on the modality. The IHE has yet to correct this and indeed the IHE Structured Workflow Integration Profile does not define any transactions between the Image Manager and the Image Archive (as originally envisioned in the SWF profile) and treats them as a single Image Manager/Image Archive actor. This viewpoint tends to prevent considerations of ceding archive operations to a central system.

A partial list of what constitutes ceding archive operations to a remote third-party archive includes the following desired operations (Fig. 1):

Fig 1.

Archiving steps for a PACS’ own exams. In this case, the PACS must send the Store-Commit to the enterprise archive as a Service Class User, and the archive is the Service Class Provider.

Archiving:

1. The PACS should support sending an initial copy of a QA’ed (in the PACS) and Completed (in the RIS) exam to the clinical image viewer to permit viewing of an exam by ER and urgent care practitioners in advance of a final read by a Radiologist. This and subsequent sends should also provide to the archive all presentation state information to duplicate the PACS QA’ed appearance (IHE CPI) via DICOM GSPS objects [cite].

2. The PACS should send a final copy of the exam to the Enterprise Archive after RIS Finalization. The original exam should be overlaid by the Final version to assure that new objects created by the Radiologist are also archived alongside the original images. This send should be accompanied by a Store-Commit by the PACS as an SCU. Presentation state at the moment of interpretation should also be sent via DICOM GSPS objects. A successful store allows the PACS to mark the exam as flush eligible from its Short Term Storage (STS) cache.

3. At a later point, defined either by high water marks or the closing of the patient’s Episode of Care at the facility, the exam will be flushed from the PACS STS. This event needs to be communicated to whichever process is acting as the pre-fetch engine for the PACS STS.

4. In the event that patient information changes (i.e., a John Doe is identified), the PACS must accept Reg/ADT patient updates from an external authoritative source, as will the archive, so that subsequent recalls of the exam have correct patient identity at both PACS and archive.

5. In the event that the exam performed on the PACS had mis-assigned images (from an incorrect exam or patient), such corrections on PACS will have to be shared with the archive.

Pre-fetch/Recall of Native Exams (Fig. 2):

1. Here, native exams refer to exams performed on this PACS.

2. Upon receiving an order from the RIS (either planned or ad hoc), the PACS initiates retrieves of relevant prior exams that have fallen off the STS, from the archive, based on pre-fetch rules (e.g., get three most recent CTs of the same body part).

3. The recalled exam is immediately recognized as a prior based on the fact that its status as a native exam on the PACS is final. This permits the exam to be marked flush eligible and prevents it from being listed in the “Unread” worklists.

4. The prior is flushed according to high water mark or Episode of Care rules.

Fig 2.

Steps involved in the pre-fetch of native exams. In this case, the task is simplified if the PACS is only expected to retrieve exams it knows about, and hence has the proper Patient ID for. The PACS also knows that these exams have been reported and does not mark them as Unread.

Pre-fetch/Recall of Foreign Enterprise Exams (Fig. 3):

1. To this point, the PACS could manage all image movement itself. Now, however, the PACS will be confronted with exams that may come from other PACS in the same Department, the Institution, or a RHIO partner with a different Patient ID scheme.

2. At this point, the need to adopt an external Image Manager and a Master Patient Index (MPI) arises. By definition, the PACS—will not—know about these exams or have any status information on them. Hence, a method is needed for PACS to know these exams are not “New” and not meant to be put in an “Unread” worklist, but rather are Finalized compares that are flush eligible.

3. The Image Manager actor, receiving a copy of the same orders going to PACS, finds all enterprise relevant priors in the Archive for the same patient, by using the MPI to map to all occurrences of that patient in the Enterprise.

4. The XDS actor must coerce the demographics on the foreign compares so that they profile correctly with the demographics used by the Patient at the PACS performing the new exam. This includes, but is not limited to, cross checking the original Patient Identifier against the MPI so as to present the proper Patient Identifier on the current PACS.

5. The archive should also be aware of SOP classes that are not supported by the PACS (or other target) that it is sending to, so that it can filter series by SOP class that would otherwise result in errors on the PACS. Alternately, a more elegant solution would be to convert such SOP classes to Secondary Capture objects which could be accepted on the PACS.

6. A method exists on the PACS so that the foreign priors are considered Finalized and flush eligible so they are not posted on “Unread” worklists.

7. Studies are flushed from STS according to high water mark or Episode of Care rules. A flush notification must be sent to the Image Manager so it knows for certain that the next time this compare is needed, it must be resent from the archive to PACS.

Fig 3.

Steps involved in the pre-fetch of foreign exams. In this case, there are likely exams that the PACS does not know of, from perhaps different registration systems that use different Patient IDs. So the first step is converting the Site A identifier into the MPI and query for all patient instances under that. The result set is then sent to PACS after Patient IDs are coerced. The PACS also has to somehow “know” that these exams are not to be marked Unread and consider them final and flush eligible.

Results

At our institution, we have instantiated all the elements above with our primary PACS and our institutional archive. This has garnered several benefits:

1. Our PACS storage needs are curtailed down to a 40- to 60-day cache, relieving the department from annual expenditures for more storage.

2. We enjoy the economies of scale that accrue by pointing multiple departments at a single large archive.

3. For all users of the central archive, we have a single Exam index that enables “one stop shopping” in our clinical viewer for any imaging exams done on the patient anywhere in our enterprise.

4. Various PACS are empowered to have enterprise comparisons for a patient regardless of where the historical exams were performed.

5. Clinical users have one image viewer, synched to the patient context of the EMR, for Radiology/Cardiology/ObGyn etc.

Another benefit that is not immediately apparent is the easing of migration to new PACS should such measures be needed. Rather than having to migrate images from an oftentimes proprietary format from the old vendor to the new, a centralized DICOM archive permits the images to stay in place if the PACS is swapped. Migration thereby becomes a matter of simply pre-fetching exams from the archive to the new PACS as they are needed by a patient’s next Episode of Care. Also, if the archive itself needs to be migrated, the fact that the images are stored in pure DICOM means that only the database pointers associating a given DICOM Study Unique ID to the file path needs to be converted to the new system, a very lightweight operation. The image data can remain on its storage file system.

We have not yet addressed all the complications that can occur in a federated medical facility. One such is the following “work-sharing” scenario. Consider a site A with PACS A. Their single radiologist has taken ill and they need to have the exams performed at site A that day interpreted by a radiologist on site B’s PACS. We have shown in the above sections that new exams from A can be sent to B and PACS B can also have Enterprise comparisons. But, once the exam is interpreted on PACS B: who archives it, how do the technical and professional fees get resolved, how does the exam get taken off the Unread worklist on site A’s PACS, how does the report get back to the original site, and how is flushing handled from the non-archiving PACS STS?

Conclusions

IHE compliance is an excellent goal to pursue when purchasing new health care information systems. However, IHE compliance alone does not guarantee that the systems so bought will behave in the optimum manner that purchasers expect. For example, IHE has not yet embraced the concept of separate image managers from image archives. Because of this oversight, there are no defined operations to update patient or exam information from a PACS and reconcile this change to the PACS’ downstream archive, or to an IHE compliant XDS/XDS-I infrastructure. A real world implementation must therefore transcend IHE to accomplish this required work.

Purchasers are well advised to discuss with vendors, even during the Request for Proposal stage, the total workflow requirements and expected behaviors of the vended product in their institution.

Terms
DICOM GSPS (Gray Scale Presentation State)	A DICOM object type that can be used to share presentation state via the IHE CPI Profile [6].
EOC (Episode of Care)	The time corresponding to when the patient entered the health care provider (admission) and their leaving (discharge). These events are broadcast by the Reg/ADT actor in a facility.
IHE (Integration of the Health Care Enterprise)	A consortium of interests that have defined the use cases for major workflows within health care institutions and how actual products “Actors” facilitate those workflows [7].
IHE Actor	A device that performs the various workflows assigned to it by the IHE technical frameworks and the Integration Profiles therein. For example: Image Archive, Image Manager, Image Viewer, etc.
IHE CPI (Consistent Presentation of Images)	An Integration Profile that assures that presentation state information is shared among all image viewer Actors so that all users experience the same image appearance [8].
IHE Integration Profiles	The name given to specific workflows that document the messages exchanged among actors to perform the indicated task.
MPI (Master Patient Index)	A universal mapping of all local patient identifiers across an Enterprise to a common identifier.
PACS (Picture Archive and Communication System)	Receives its orders from the RIS. The order also maps to a study which may or may not have images. Statuses are: New, In Progress, QA’ed (like RIS Complete) but Unread (goes into Unread Worklist), prelim Read, Final Read, and Archived.
PACS STS (Short Term Storage)	An image cache on PACS, sized to only 30–60 days for an exam’s time to live before flushing. Alternately, flushing can be triggered when the patient is discharged and the Episode of Care for that patient is closed.
PIX (Patient Identifier Cross Referencing Integration Profile)	The PIX profile assures that a patient’s local ID can be cross-referenced to a Master ID (the MPI) and hence tied to any other IDs that happened to be aliased to the patient throughout the MPI’s domain [9].
Reg/ADT (Registration/Admission/Discharge/Transfer)	The system that captures patient demographics, tracks their location within a medical center, and logs the patient discharge from the facility.
XDS (Cross Enterprise Document Sharing Integration Profile)	For members of an Affinity Domain (a group of providers that agree to work together), XDS, combined with PIX, enable a standard format for representing the patient’s medical record [10].
RIS (Radiology Information System)	Receives orders from external systems or within the department. The order maps to a study that can have the statuses: New, Arrived, Complete, Preliminary report, and Final report.