Tracking coincidence events in pet even when count rates are extremely high: The Lost-Event Tally packet concept

We describe techniques which extend the usefulness of real-time data-handling architectures designed for clinical PET - especially for instances of extremely high count rate. As is widely known, Rubidium-82 (82Rb) with a 1.3 minute half-life is often used in clinical PET. When used, 82Rb is more often applied for dynamic and/or gated studies - typically with little or no delay between tracer injection and start of acquisition. The use of 82Rb for short-duration-framed studies in clinical PET has its own set of challenges. Rapid decay means that later frames in a study collect far fewer counts. Increasing the dosage of 82Rb can help increase the counting statistics for short-duration frames. On the other hand, a larger (or too large) dose may temporarily exceed the acquisition throughput. When such saturation occurs, coincidence events are lost. In the case of 82Rb, such loss is typically short lived and limited to the count-rate peak. Such saturation also leads to a truncation of the count-rate profile - a truncation which often limits curve fitting essential for an accurate compartmental model across the entire study. The clinician may simply reduce the 82Rb dosage to avoid such saturation. But this reduction also limits the counts available in later frames - as stated. The techniques offered here help revolve this dilemma. By electronically keeping track of those events which are subject to saturation loss, the complete count-rate profile itself is preserved. Such tracking is done in real time with an accurate log of loss quantities added to the list-mode stream. This approach enables the clinician to raise the 82Rb dose without a specific concern over count-rate profile truncation. We describe a special 64-bit non-event (i.e. “tag”) packet which is automatically inserted into the list-mode stream. The “Lost-Event Tally” tag packet stream enables a full recovery of the rate profile even when event packets are lost. During acquisiti- n, this tag packet is repeatedly inserted into the stream to report the counted event-packet loss (up to 1048575) since the previous such tag packet was inserted.