PACS and RIS: three approaches offer integration

May 28, 2001

Traditionally, PACS and RIS have coexisted in the same hospital but kept separate databases containing supposedly identical data -- a situation ripe with potential for inaccuracies. Ideally, hospitals should be able to address user needs through use of a

Traditionally, PACS and RIS have coexisted in the same hospital but kept separate databases containing supposedly identical data - a situation ripe with potential for inaccuracies. Ideally, hospitals should be able to address user needs through use of a single database.

"Integration is not the same as connectivity," said Dr. Nogah Haramati, director of informatics and an associate professor of radiology and orthopedic surgery at Albert Einstein College of Medicine, in a paper published last year (J Healthc Inf Manag 2000;14:69-81).

Connectivity is established through bidirectional HL7 or DICOM links, whereas integration implies that the two systems are truly working together, according to Haramati. True integration is what is missing.

One example of an emerging PACS and RIS integration problem is control of archiving and prefetching processes, traditionally a PACS function. Some RIS vendors are assuming this role, however, by overseeing archival functions and issuing DICOM commands to prefetch images to various locations. The problem is that users wishing to view a patient's images may get different results depending on whether the image was prefetched from the RIS or from the PACS, Haramati said.

While the RIS may have issued a prefetch and sent the image to the RIS user rapidly, the PACS may be unaware the exam has already been prefetched and busy itself obtaining the exam again from the slow archive. The result for the PACS user is a delay caused by lack of integration.

Haramati categorizes three types of solution to PACS-RIS integration:

  • Active-passive applications delegate all database activity to the active application with local user data entry or display functions relegated to the passive application.
  • The centralized approach requires that one database be given control of one data object (such as medical record number). The actual record containing multiple objects (name, allergies, surgical history) might be scattered among several databases, but there is no duplication of objects.
  • The decentralized approach allows for disparate databases to be used for different data elements or objects. In this way, the centralized and decentralized approaches can actually work together.

"Although perhaps not an optimal configuration, this combined decentralized approach might be preferable to database duplication," Haramati said. "Active applications actually become centralized with respect to a single database object."

None of these solutions is mutually exclusive of the other, and all three can be implemented together on RIS and PACS, he said.