PoolPy: Unified Group Testing Framework

• PoolPy is an open-source framework that unifies ten distinct group testing methods into a common decision-support system.
• The framework employs a shared formal representation to simulate over 10,000 designs, balancing tests, pool size, turnaround time, and error tolerance.
• Its web interface and precomputed experimental plans streamline screening in clinical, QC, and environmental contexts under varying prevalence.

Searching arXiv for recent and directly relevant papers on PoolPy and related context. PoolPy is an open-source framework and web app for designing, comparing, and selecting group testing strategies for large-scale screening. It was introduced to unify ten different methods within a single decision-support environment, represent them through a common sample-to-pool formalism, and rank candidate designs under user-defined constraints such as turnaround time, cost or test number, group size, sample dilution, expected prevalence, maximum number of positives to resolve, and error tolerance. By computing over 10,000 group testing designs through a web interface, it advances a central claim: no single pooled-testing method is universally optimal, and design choice must be case-specific (Talamanca et al., 3 Sep 2025).

1. Problem setting and scope

PoolPy addresses a standard difficulty in pooled or group testing: although combining samples into pools can greatly reduce the number of assays relative to individual testing, method selection is nontrivial because different constructions behave very differently as the sample count, prevalence, and expected number of positives change. The framework is therefore aimed at large screening campaigns, especially low-prevalence settings and operational regimes in which tests are expensive, slow, or resource-limited (Talamanca et al., 3 Sep 2025).

The paper situates the framework in practical screening contexts such as clinical surveillance, molecular screens, manufacturing QC, and environmental monitoring. Across these settings, the main trade-offs are not only combinatorial but also logistical: minimizing total test count can conflict with minimizing pool size, reducing dilution, shortening turnaround time, or maintaining robustness when the realized number of positives exceeds the design assumption. PoolPy exists to make these trade-offs explicit rather than leaving pooling design to ad hoc method choice (Talamanca et al., 3 Sep 2025).

A defining premise of the framework is that group testing performance is application-dependent. The relevant decision variables include prevalence, acceptable error rate, allowable group size, acceptable number of steps, desired turnaround time, and total assay burden. This suggests a shift from asking for a universally best pooling scheme to asking which scheme is best under a specified operational constraint set.

2. Formal representation and decision framework

PoolPy adopts a common notation for heterogeneous pooling methods. The sample set is written as $\mathbb{S}=\{s\}$ with $S$ total samples and $s=0,\dots,S-1$. The pool set is $\mathbb{W}=\{w\}$ with $W$ pools and $w=0,\dots,W-1$. The framework assumes that at most $D$ positives are expected or resolvable; $D$ is also described as the “differentiate” value (Talamanca et al., 3 Sep 2025).

A pooling design is represented by a Boolean assignment matrix

$PA \in \{0,1\}^{S \times W},$

where $(PA)_{sw}=1$ means that sample $S$0 is included in pool $S$1. The notation $S$2 denotes the samples in pool $S$3, and $S$4 the pools containing sample $S$5. The total number of pools is method-dependent:

$S$6

This shared representation is the basis on which PoolPy compares adaptive, semi-adaptive, and non-adaptive constructions that are otherwise combinatorially dissimilar (Talamanca et al., 3 Sep 2025).

Within this formalism, the framework can implement and compare ten conceptually different methods, design pooling matrices, simulate designs across prevalence and sample-size settings, estimate trade-offs among tests, tests per sample, pool size, number of steps, maximum positives, and probability of error, rank methods under user-defined constraints, and return downloadable experimental plans. The decision procedure is not a single global optimization formula; instead, it enumerates candidate designs for each method over relevant $S$7 values, constructs the corresponding assignment matrix, computes design metrics, compares methods directly, and ranks designs against the specified criteria (Talamanca et al., 3 Sep 2025).

3. Method classes and canonical constructions

The ten methods implemented in PoolPy are organized into three classes: one adaptive method, five semi-adaptive methods, and four non-adaptive methods. The class distinction is operationally important. Adaptive methods minimize tests but require later rounds to depend on earlier results; semi-adaptive methods often complete in one step at very low prevalence but may require a second validation step; non-adaptive methods fix all pools in advance and permit one-step identification (Talamanca et al., 3 Sep 2025).

Method	Class	Characteristic profile
Hierarchical	Adaptive	Few tests, multiple rounds
Binary	Semi-adaptive	Minimal tests for $S$8, very large pools
Matrix	Semi-adaptive	Simple, small pools, more tests
Multi-dimensional - 3	Semi-adaptive	Middle ground in tests and pool size
Multi-dimensional - 4	Semi-adaptive	Compromise design, weaker as prevalence rises
Random	Semi-adaptive	Flexible heuristic search
Shifted transversal	Non-adaptive	One-step, balanced tests and pool size
Chinese Remainder	Non-adaptive	One-step CRT construction
Chinese Remainder Backtrack	Non-adaptive	CRT variant with reduced pool count
Chinese Remainder Special	Non-adaptive	Special-case CRT for small $S$9

Several methods are singled out in the paper as structural reference points. Hierarchical testing is a recursive split-and-test strategy. For $s=0,\dots,S-1$0, splitting into $s=0,\dots,S-1$1 parts at each step yields

$s=0,\dots,S-1$2

The paper argues that the associated objective is maximized near $s=0,\dots,S-1$3, implying that splitting by 3 is near-optimal in integer practice, with 2-way splits used for small remainder cases. Hierarchical designs are therefore favored when minimizing tests matters more than speed and multi-round workflows are acceptable (Talamanca et al., 3 Sep 2025).

Binary designs encode each sample by its binary membership pattern. For $s=0,\dots,S-1$4, the number of pools is

$s=0,\dots,S-1$5

possibly plus one extra pool to distinguish the $s=0,\dots,S-1$6 case from the exactly-one-positive case. The paper reports that for 500 samples and at most one positive, the binary method required only 9 tests. Its weakness is structural fragility: performance collapses when more than one positive is present, and the method relies on very large pools (Talamanca et al., 3 Sep 2025).

Matrix pooling arranges samples on a two-dimensional grid with row and column tests. If $s=0,\dots,S-1$7 and $s=0,\dots,S-1$8, then

$s=0,\dots,S-1$9

This makes matrix designs intuitive and practical when small group size is the binding constraint, even though they usually require more tests and become ambiguous with multiple positives (Talamanca et al., 3 Sep 2025).

Shifted transversal occupies a distinct place among one-step designs. It is a structured non-adaptive construction based on layered cyclic shifts and is presented as a strong all-around choice when fast turnaround is essential. The paper notes that for 4 positives out of 100 or more, shifted transversal outperformed all non- and semi-adaptive methods in tests per sample while keeping pool sizes relatively low. The Chinese Remainder family provides other one-step constructions: a basic CRT design, a backtracking variant that searches exponents to reduce total pool count, and a special-case CRT formulation for small $\mathbb{W}=\{w\}$0, especially $\mathbb{W}=\{w\}$1 and $\mathbb{W}=\{w\}$2 (Talamanca et al., 3 Sep 2025).

4. Evaluation criteria, trade-offs, and empirical behavior

PoolPy ranks designs against four explicit criteria: reducing test number, minimizing group size, minimizing number of steps, and scaling with high prevalence. Methods are assigned qualitative ratings from very poor to very good. For test number and group size, rankings are based on $\mathbb{W}=\{w\}$3 designs; for number of steps and high-prevalence scaling, averages over $\mathbb{W}=\{w\}$4 are used (Talamanca et al., 3 Sep 2025).

The main efficiency metric is the total number of pools $\mathbb{W}=\{w\}$5, often normalized as tests per sample,

$\mathbb{W}=\{w\}$6

This normalization is emphasized because it permits cross-method comparison as batch size varies. The paper repeatedly identifies a strong trade-off between minimizing tests and minimizing group size. Binary designs sit at one extreme, using the fewest tests but the largest pools. Matrix designs sit at the other, using the most tests but the smallest pools. Multi-dimensional and shifted-transversal constructions occupy intermediate regions (Talamanca et al., 3 Sep 2025).

Prevalence is treated as decisive. Each design is built for a maximum resolvable number of positives $\mathbb{W}=\{w\}$7, but the realized number of positives $\mathbb{W}=\{w\}$8 depends on prevalence $\mathbb{W}=\{w\}$9. The paper gives the probability that a batch exceeds design capacity, $W$0, and also gives a family-wise-error-style correction when an experiment is split into sub-batches:

$W$1

with $W$2 and $W$3. For equal splitting into $W$4 parts, the first-order approximation is

$W$5

This is used to quantify the risk that actual prevalence invalidates a chosen design (Talamanca et al., 3 Sep 2025).

The paper’s empirical summary is sharply constraint-driven. Group testing is described as mostly applicable below 10% prevalence, and at 0–2% prevalence appropriately chosen designs can keep error rates below 0.1%. Binary is characterized as excellent but fragile: outstanding for at most one positive, but potentially worse than individual testing once multiple positives become plausible. One-step methods are valuable when turnaround time dominates, and among them shifted transversal is presented as especially strong overall. The reported “probability of error” aggregates wrong positive identification, missed positives, and inconclusive results; in prevalence simulations, cases with $W$6 are also treated as errors (Talamanca et al., 3 Sep 2025).

5. Software implementation and operational use

PoolPy is provided as an open-source codebase together with a web interface and precomputed downloadable designs. The software perspective is central to the paper: rather than merely cataloging pooling constructions, it exposes them through a unified workflow in which users specify screening conditions and receive candidate designs ranked by suitability (Talamanca et al., 3 Sep 2025).

The user-facing inputs include number of samples, expected prevalence, error tolerance, and logistical constraints such as turnaround time, group size limit, desired trade-off between test count and pool size, and the maximum number of positives to resolve. The outputs include comparisons across all methods, recommended or best-suited designs under the chosen constraints, downloadable pooling designs or experimental plans, and estimated performance in terms of number of tests, tests per sample, group size, number of steps, and expected error under the assumed prevalence regime (Talamanca et al., 3 Sep 2025).

The framework’s practical guidance follows directly from these metrics. Binary is appropriate when batches are expected to contain 0–1 positives and assay count dominates all other constraints. Matrix or Multi-dimensional-3 is preferable when pool size must remain small. Hierarchical is appropriate when minimizing total tests matters more than speed. Shifted transversal is the default one-step candidate when rapid turnaround is essential. If prevalence is uncertain, the paper recommends using the prevalence/error estimation machinery to choose a design with larger $W$7 or to split the batch into smaller sub-batches. A plausible implication is that PoolPy is best understood ոչ as a single pooling algorithm but as a constraint-aware method-selection layer above a library of pooling constructions.

6. Limitations, caveats, and nomenclature

The paper is explicit about several limitations. Prevalence estimation is required, and if prevalence is unknown an initial round of individual testing may be necessary. The formal method descriptions assume ideal binary tests, but real assays have imperfect sensitivity and specificity. Dilution effects can reduce sensitivity, especially in biomedical settings, making group size a first-class constraint rather than a secondary consideration. Some methods fail when the actual number of positives exceeds $W$8, which can yield inconclusive or incorrect decoding. The random-design module is heuristic and does not guarantee a globally optimal construction. Above all, no single method is universally optimal, so theoretical efficiency can be overridden by practical constraints such as lab workflow, automation, or turnaround requirements (Talamanca et al., 3 Sep 2025).

The framework also needs to be distinguished from several similarly named systems in other domains. It is unrelated to the LHC data persistency framework POOL described in "POOL File Catalog, Collection and Metadata Components" [0306065]; to "PaPy: Parallel and distributed data-processing pipelines in Python" (Cieslik et al., 2014); to the PyTorch point-process toolbox PoPPy (Xu, 2018); to the ridepooling simulator RidePy (Jung et al., 2023); and to the pool-based active learning algorithm UPAL (Ganti et al., 2011). Within the 2025 paper, PoolPy refers specifically to pooled-testing design for large-scale screening rather than to pipeline execution, temporal point processes, mobility simulation, or active learning.

Taken together, these caveats clarify the status of PoolPy. It is not a universal decoder, not a biochemical sensitivity model, and not a guarantee that pooled testing will dominate individual testing. It is a unified design-and-selection framework whose technical contribution lies in placing ten group-testing methods into a common representational and evaluative space, precomputing a large design inventory, and formalizing the operational fact that method choice depends on prevalence, dilution tolerance, acceptable error, assay budget, and workflow latency (Talamanca et al., 3 Sep 2025).