ProbID Methods
ProbID uses likelihood ratios (LRs) and Bayes’ theorem to update a pretest probability into a post-test probability. This page explains what an LR is, how it’s calculated from test performance, how the current decision layer works, and how the app preserves a shareable case state.
1) What is a likelihood ratio?
A likelihood ratio tells you how much a test result changes the odds of a diagnosis. It links the result you observe (positive or negative) to how likely that result would be in people with the disease versus without the disease.
How much more likely a positive result is in disease vs no disease.
How much less likely a negative result is in disease vs no disease.
- LR+ > 10: strong “rule-in” effect
- LR+ 5–10: moderate rule-in
- LR+ 2–5: small-to-moderate rule-in
- LR− 0.1–0.2: moderate-to-strong “rule-out” effect
- LR− < 0.1: strong rule-out
2) Bayes’ theorem in odds form (what ProbID does)
ProbID updates odds, not probabilities, because odds update by simple multiplication.
When multiple independent findings are selected, ProbID multiplies their likelihood ratios to create a combined LR. This is convenient, but assumes conditional independence—correlated findings can overestimate certainty.
3) Worked example (step-by-step)
Suppose a test has Sensitivity = 0.80 and Specificity = 0.90. And your patient’s pretest probability is 20%.
Same pretest probability (20%), but use LR− instead:
4) Decision Layer: How Treatment Thresholds Are Computed
ProbID now separates two questions: how likely is the disease? and at what probability does treatment become worth it?The CAP module now uses an expected-utility treatment threshold; other modules still use a transparent heuristic fallback while they are being upgraded.
CAP uses four outcome utilities over a short acute-illness horizon:
- Treat + true CAP
- No treat + true CAP
- Treat + no CAP
- No treat + no CAP
These values are structured estimates anchored to published lower-respiratory-infection burden data, adult CAP severity concepts, and outpatient antibiotic adverse-event burden. Patient factors shift the utilities in transparent, visible ways.
For CAP, expected utility is computed directly:
Treatment is justified when EU(treat) > EU(no treat). Solving that equality for probability gives the treatment threshold:
The CAP module currently uses a binary decision threshold:
- If post-test p(CAP) is below threshold, the app recommends reassessment or further testing rather than immediate empiric antibiotics.
- If post-test p(CAP) is above threshold, the app recommends empiric CAP treatment.
- Modules without a true utility model still use the older heuristic observe/test/treat fallback.
Utility-backed treatment models live in lib/probidExpectedUtility.ts. Heuristic fallback thresholds remain configurable in lib/probidDecision.ts.
5) Shareable Case State
ProbID now keeps the current case setup in the page URL so the tool can restore the same syndrome, setting, findings, and decision modifiers when the link is reopened or shared.
- Selected syndrome and setting
- Present and absent findings
- Stepwise selection order
- CAP utility modifiers
- VAP and endocarditis pretest modifier selections
- Score-panel inputs such as VIRSTA, DENOVA, and HANDOC
- No backend account or saved server-side record is created
- No patient-identifying data should be entered into the tool
- The URL is meant to preserve educational case logic, not protected health information
The app serializes the current tool state into a URL query parameter and restores it on load. This is a convenience feature for reproducibility and teaching. It does not change the underlying LR, expected-utility, or heuristic decision calculations.