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?CAP uses an expected-utility treatment threshold, chronic hip/knee PJI uses a two-threshold action model, and 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:
Chronic hip/knee PJI uses a lower stop-work-up threshold and an upper manage-as-likely-PJI threshold based on Pauker-Kassirer logic.
The default chronic-PJI base case uses three explicit harms: additional invasive work-up, missed chronic PJI, and unnecessary PJI-directed management. Patient factors then move those harms multiplicatively, which shifts both thresholds in visible ways.
The chronic-PJI evidence layer also uses a block-representative approach to reduce double counting: one serum inflammatory anchor, one aspiration-zone interpretation, and one reflex synovial adjunct rather than multiplying several correlated inflammatory tests at full weight.
Different syndromes can now use different decision layers:
- 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.
- If post-test p(PJI) falls between the two PJI thresholds, the app recommends diagnostic clarification rather than stopping or fully committing.
- Modules without a true utility model still use the older heuristic observe/test/treat fallback.
Utility-backed treatment models live in lib/probidExpectedUtility.ts. PJI action-threshold models and heuristic fallbacks live 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 and PJI decision 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.