Skip to main content

Prefetching Priors Overview

In a clinical setting, it is often desirable to have ready access to similar studies performed in the past when doing a diagnosis. Different specialties and individual radiologists will have their own definitions of what constitutes clinical relevance. Factors that affect relevance include:

  • Age of the prior study
  • Body part imaged
  • Modalities used in acquisition
  • Specific imaging procedure performed

The Relevant Prior Matching subsystem of the RamSoft software provides a very powerful and flexible mechanism for identifying clinically relevant prior studies, both on the local server and configured remote system. These relevant priors are routed along with the original reference study. The reference study is the study for which relevant priors are being sought.

The mechanism is triggered by a routing rule that requires all priors to be sent along with the current study to a predetermined destination. The Relevant Prior Matching subsystem operates in three distinct phases when processing studies. These stages are Fetching, Matching and Sending and are always performed in the same order.

In the Fetching phase, PowerServer performs DICOM Query and Retrieve operations against the configured Sources. The Fetch is done first to import all candidate studies into the local PowerServer, so that all relevant fields can be reliably found. The matching cannot be done from the remote machine as the required information cannot be retrieved with a simple DICOM query. The studies that are Fetched satisfy some broad criteria defined in the Query Model - generally a matching patient identity and a time window. The detailed comparison will be performed in the next phase, once Fetching is complete.

In the Matching phase, each study that satisfies the broad criteria defined by the Query Model is compared against the Reference Study. First, the Reference Study is characterized. Characterization consists of finding the first Constraint Group to which the Reference Study belongs. This Constraint Group will serve as the context for all comparisons between the Reference Study and Prior Studies that have been identified in the Fetching phase.

After characterization each Prior Study is Compared against the Reference Study in the context of the Constraint Group selected during the Characterization step. Any prior Study that matches the Reference Study is considered a Relevant Prior, and will be sent to the list of Destinations associated with the triggering Routing Rule.

Finally, all Relevant Priors are Sent (along with the Reference Study) to each Destination associated with the triggering routing rule, if that Destination is configured to receive Relevant Priors.

A Query Model is used to define the broad criteria that will be used to fetch prior studies. The attributes included in the definition of a Query Model are as follows:

  • Patient Name: If selected, the Patient Name attribute from the Reference Study will constrain the Fetch.
  • Patient ID and Issuer: If selected, both the Patient ID and Issuer of Patient ID attributes from the Reference Study will constrain the Fetch.
  • Modality: If selected, the Modality attribute from the Reference Study will constrain the Fetch.
  • Facility: If selected, the Facility attribute from the Reference Study will constrain the Fetch.
  • Study Date: If selected, the Study Date attribute must precede the Reference Study by no more than the specified number of weeks.
  • Study Status Values: If selected, the Status attribute will constrain the Fetch.