MedCalc-Pro: Solving Complex Medical Calculations with LLM Agents

Chennuo Zhang; Ruihui Hou; Siran Zhao; Tong Ruan; Ziyue Huai

REVIEW 4 major objections 6 minor 14 references

Realistic medical calculation needs multi-tool agents with nested calling and parameter validation, not single named calculators.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · grok-4.5

2026-07-12 06:25 UTC pith:GHOKCR7P

load-bearing objection Solid systems paper: harder medical-calc benchmark plus a structured agent that wins the tables; nested n=62 is the main soft spot, not a collapse of the claim. the 4 major comments →

arxiv 2607.02879 v1 pith:GHOKCR7P submitted 2026-07-03 cs.AI

MedCalc-Pro: Solving Complex Medical Calculations with LLM Agents

Siran Zhao , Ruihui Hou , Ziyue Huai , Chennuo Zhang , Tong Ruan This is my paper

classification cs.AI

keywords medical calculatorsLLM agentstool useMedCalc-Pronested toolsmulti-calculatorparameter validationclinical decision support

verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Existing medical LLM benchmarks mostly test one calculator whose name is already in the question. Real clinical work often needs several scores at once, scores that depend on other scores, and questions that only state a goal such as “assess stroke and bleeding risk.” The authors introduce MedCalc-Pro—2,268 clinical cases, 77 calculators, three progressive settings (single, multi, nested)—and a four-stage agent that rewrites the goal, retrieves candidates, selects tools, then runs them in dependency order with structured parameter checks and evidence review. Across open-source, closed-source, and medical-specialized models the agent leads every setting, with the largest gains on multi-calculator and nested tasks. The paper’s point is that clinical calculation agents must handle fuzzy goals, multi-tool selection, nesting, and error suppression if they are to matter beyond simplified demos.

Core claim

The paper establishes that single-calculator, tool-named benchmarks understate clinical difficulty, and that a four-stage agent—multi-dimensional query rewriting, multi-route retrieval with reciprocal rank fusion, tool selection, and dependency-aware execution with completeness/type/enum/unit validation plus evidence audit—achieves the best tool-selection, parameter-extraction, and score accuracy on MedCalc-Pro’s single-, multi-, and nested-calculator tasks versus prior agent baselines.

What carries the argument

The four-stage medical calculator agent: rewrite the physician query into clinical-context, key-parameter, and core-function routes; retrieve and RRF-rerank candidates; select tools (with dependency declaration); then execute in dependency order under a structured validation and evidence-review loop that backtracks on bad parameters.

Load-bearing premise

The multi- and nested-calculator cases—partly merged from prior data, partly regex-harvested, with model-written fuzzy queries, only 62 nested examples, and single-turn clean text—are representative enough of real multi-tool clinical work that benchmark wins will transfer.

What would settle it

Rebuild or expand the multi/nested sets with independent clinician-written goal-driven queries and substantially more nested dependency chains; if the same agent no longer leads prior methods on score accuracy and parent/sub-calculator scores, or if nested gains vanish under that expansion, the generalizability claim fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

Benchmarks that name a single calculator hide failures that appear under multi-tool and nested use.
As tasks move from single to multi and nested, the bottleneck shifts from tool recovery to parameter extraction and error propagation.
Structured validation and evidence review after extraction are required to keep intermediate mistakes from cascading through nested scores.
Goal-driven (fuzzy) queries need rewrite-plus-retrieve-plus-select pipelines; formula lookup alone collapses when the calculator name is absent.
The same agent stack remains strongest across open-source, closed-source, and medical-specialized base models on all three settings.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Single-score wrappers will systematically miss joint workflows such as stroke-plus-bleeding risk or ICU severity scores that depend on GCS-like sub-scores.
Because residual errors are dominated by parameter values and enum mapping, further gains may come more from structured EMR extraction than from larger general models alone.
Single-turn clean-text evaluation likely overstates readiness for noisy, incomplete, multi-turn real records the paper itself flags as next work.
Accuracy gains without ReAct-scale token cost suggest multi-route retrieval plus validation is a practical hospital-latency design pattern.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Desk Editor's Note

Solid systems paper: harder medical-calc benchmark plus a structured agent that wins the tables; nested n=62 is the main soft spot, not a collapse of the claim.

read the letter

Punchline: this is a useful medical-NLP systems paper. They raise the bar from “named single calculator” to multi-tool and nested fuzzy-goal calculation, and their four-stage agent (rewrite → multi-route retrieve+RRF → free multi-tool select → dependency-aware execute with completeness/type/enum/unit checks and evidence audit) is best across MeNTi, MedRaC, and ReAct on six models.

What is actually new is the evaluation design more than any single module. Table 1 is fair: prior suites (MedCalc-Bench, CMedCalc, OpenMedCalc, CalcQA, AgentMD/RiskQA, MedRaC) are mostly single-tool and often name the tool. MedCalc-Pro’s 2,268 cases / 77 tools / 14 departments, goal-driven queries, and explicit multi + nested tracks match real joint risk/severity workflows better. Construction is documented: MedRaC for single; same-patient merges from MedCalc-Bench plus PMC regex for multi; nested from PMC with parent+sub names/scores then computability filter; three-stage QC with student review and 20% clinician audit to >95%. Ablations (rewrite, retrieval, validation), K_route/K_cand grids, error typology, difficulty-by-parameter-count, and cost table are the right experiments. Gains are largest where the problem is hard—multi Score Acc and nested parent/sub—and MedRaC’s zero on fuzzy multi/nested is a real failure mode of formula RAG, not noise.

Soft spots, in proportion: nested is only 62 cases, no CIs or IAA, so Table 3 should not be over-read as a definitive multi-tool law. Regex that required explicit sub names/scores can make dependency detection easier than pure clinical text even after scrubbing; multi partly merges same-patient entries, so joint selection may be understated. Parameter value and enum errors still dominate residual failures; single-turn clean text is not noisy EMR. Artifacts are not clearly public in the manuscript. None of that invents a load-bearing contradiction—the agent still wins single and multi with larger n, and validation ablations move the needle the way the story claims.

Who it is for: people building clinical tool-using agents or calculator benchmarks. Cite for the task framing and the validation-against-propagation pattern; treat nested numbers as directional. I would send it to peer review. Engage, use the suite if released, and ask for nested expansion, variance, and code.

Referee Report

4 major / 6 minor

Summary. The paper introduces MedCalc-Pro, a medical calculation benchmark of 2,268 clinical cases over 77 calculators and 14 departments, with three settings: single-calculator, multi-calculator, and nested-calculator, emphasizing fuzzy goal-driven queries rather than explicit tool names. It also proposes a four-stage agent (query rewriting along clinical dimensions, multi-route dense retrieval with RRF, LLM tool selection, and dependency-aware execution with Completeness→Type→Enum→Unit validation plus evidence audit). Across MeNTi, MedRaC, and ReAct on six LLMs (open-source, closed-source, medical-specialized), the framework reports the best R-F1, extraction, and score metrics on all three settings (Tables 2–3), with ablations (Tables 4–5), hyperparameter grids (Tables 6–7), error typology (Table 8), difficulty stratification (Table 9), and cost comparison (Table 10).

Significance. If the results hold under stronger evaluation, the work fills a clear gap: prior medical calculator benchmarks (Table 1) are largely single-tool with named calculators, whereas multi-tool joint evaluation and nested sub-score dependencies are clinically realistic. The systematic multi-model, multi-baseline comparison, ablations isolating rewrite/retrieval/validation, and explicit process metrics (dependency detection, sub-calculator accuracy) are genuine strengths. The structured validation pipeline and public-style toolkit construction are practically useful for agent research in high-stakes numerical clinical workflows. The main significance is therefore both a harder benchmark and an agent design that measurably improves multi- and nested-tool execution over strong baselines.

major comments (4)

Table 3 and §3.2: Nested-calculator results rest on only 62 cases constructed by regex matching parent+sub calculator names/scores in PMC-Patients, then filtering for computability. Parent Overall and Sub Overall are load-bearing for the claim of dependency-aware multi-tool superiority (e.g., gpt-oss-120b Parent 75.80 vs MeNTi 61.29 / ReAct 11.74). With n=62 and no confidence intervals, bootstrap, or case-level difficulty breakdown, a few hard or mis-annotated chains can dominate. Please report variance (bootstrap CIs or per-case accuracy distributions), expand nested coverage if possible, and quantify how often dependency detection is trivialized by residual textual cues after name/score scrubbing.
§3.2 Benchmark Creation: Multi-calculator cases partly merge same-patient MedCalc-Bench entries (1,066 candidates) and add 92 PMC cases; multi/nested fuzzy queries are generated by GPT-5.1, with student review and 20% clinician audit to >95% accuracy but no inter-annotator agreement, disagreement rates, or leakage audit protocol. This construction is central to the claim that MedCalc-Pro is closer to real clinical multi-tool workflows. Please report IAA, the fraction of cases revised after clinician audit, and an explicit leakage check (e.g., whether models can recover tools from case text alone without the query, or residual calculator-name fragments).
§4.2 / Table 2–3: MedRaC collapses to near-zero or zero on multi- and nested-calculator tasks because RAG fails when queries are goal-driven rather than formula-named. That failure mode is informative, but the comparison then largely contrasts your full multi-tool pipeline against a single-formula RAG+code system outside its design envelope. For the multi/nested claims, either adapt MedRaC with multi-tool retrieval/selection (or a fair multi-tool RAG baseline) or clearly scope MedRaC as a single-calculator baseline only, and strengthen comparison against ReAct/MeNTi with matched tool-access budgets and candidate-set sizes.
§4.1 Metrics and Tables 2–3: Score Accuracy and Parent Overall are reported without clarifying whether they are conditioned on correct tool selection, joint exact-set match, or partial credit when a subset of tools is correct. Multi-calculator R-F1 can be high while joint correctness is low. Please define metrics formally (micro/macro, set-level vs tool-level, conditioning on selection) and add joint multi-tool exact-match and end-to-end case success rates, which are the clinically relevant quantities for multi- and nested settings.

minor comments (6)

Figure 1 and abstract claim three progressively challenging settings; Table 1 is clear, but the main text should state exact case counts per split (single/multi/nested) in one place—2,268 total is given, nested 62 and multi construction numbers appear later, which is easy to miss.
Eq. (1) RRF uses constant k without stating its value; Implementations give k_route=16 and K_cand=32 but not the RRF k. Please specify.
Table 8 error counts (e.g., multi-calculator Retrieval Miss 321, Selection Error 460) appear to be absolute counts over the full multi set; clarify sample size and whether multiple error types can co-occur per case.
Appendix prompts (B.1–B.4) and the execution trace (C) are valuable for reproducibility; consider moving a short dependency-identification example into the main Tool Execution subsection for readers who skip the appendix.
Limitations correctly note single-turn clean text and small nested set; a brief quantitative noise stress test (abbreviations/OCR-style typos) would strengthen the deployment discussion even if left as future work.
Minor consistency: abstract/intro say “structured validation and evidence review”; ablation labels this “Variant-1”—use one name throughout Tables 4–5 and the text.

Circularity Check

0 steps flagged

No circular derivation: empirical agent vs external baselines on a constructed benchmark; success is not defined by construction.

full rationale

MedCalc-Pro and the four-stage agent are evaluated empirically (tool R-F1, extraction accuracy, score accuracy, dependency detection) against MeNTi, MedRaC, and ReAct on multiple LLMs (Tables 2–3). Ground-truth tools and scores are anchored in clinical texts (MedRaC, MedCalc-Bench merges, PMC-Patients regex + filtering) with human QC, not in the agent’s own outputs. Query rewriting, RRF retrieval, tool selection, and structured validation (completeness/type/enum/unit + evidence audit) are engineering modules whose correctness is measured by match to those labels; they do not redefine the target metrics. Ablations (Tables 4–5) and error typology (Table 8) further treat components as falsifiable contributors, not tautologies. GPT-5.1 is used only to generate fuzzy multi/nested queries during data construction, not to define success of the evaluated agent. There is no self-definitional loop, fitted parameter renamed as prediction, load-bearing uniqueness theorem from overlapping authors, or renaming of a known result as a first-principles derivation. Weaknesses (n=62 nested, LLM-assisted query wording, single-turn clean text) are external-validity and statistical-power issues, not circularity of the claimed derivation chain. Score 0 is appropriate.

Axiom & Free-Parameter Ledger

4 free parameters · 5 axioms · 2 invented entities

The paper is an empirical ML systems paper. Load-bearing premises are domain and engineering assumptions (clinical calculators are the right tools; constructed cases/queries proxy real workflows; dense retrieval+RRF+LLM selection is adequate; structured validation reduces error propagation), not free physical constants or invented particles. Free parameters are mainly retrieval/selection hyperparameters chosen on multi-calculator validation.

free parameters (4)

K_cand (final candidate pool size)
Chosen as 32 after grid search on multi-calculator F1 vs cost; directly affects tool-selection context and reported performance.
k_route (per-route retrieval depth)
Set to 16 after grid search; controls recall/noise into RRF fusion.
RRF constant k and four-route fusion
Standard RRF form with four rewritten routes; fusion design is a design choice that shapes candidate sets.
LLM decoding temperature 0.01 (open models)
Fixed for stability; can affect selection/extraction variance.

axioms (5)

domain assumption Real clinical calculation often requires multi-calculator joint evaluation, nested sub-scores, and goal-driven queries without explicit tool names.
Motivates MedCalc-Pro task design in Introduction and §3.1–3.2; not independently measured beyond case construction.
domain assumption Medical calculators can be treated as deterministic callable tools with standardized parameter schemas and authoritative scoring logic.
Toolkit construction reuses MedCalc-Bench logic and adds 31 calculators (§3.2).
ad hoc to paper Multi-dimensional query rewriting plus dense retrieval and RRF yields a candidate set from which an LLM can select the correct multi-tool set.
Core of Stages 1–3; supported by ablations but remains a design hypothesis.
ad hoc to paper Structured Completeness→Type→Enum→Unit checks plus evidence audit suppress parameter error propagation in nested execution.
Stage 4 claim; ablation w/o variant-1 supports contribution especially on nested tasks.
domain assumption Human QC (students + 20% clinician audit to >95% accuracy) makes constructed multi/nested labels and fuzzy queries reliable evaluation targets.
Quality Control paragraph in §3.2; load-bearing for benchmark validity.

invented entities (2)

MedCalc-Pro benchmark (single/multi/nested settings) no independent evidence
purpose: Provide evaluation cases closer to multi-tool and nested clinical calculator use with fuzzy queries.
New dataset construct; independent evidence is the released cases themselves if/when public, not external physics-like prediction.
Four-stage medical calculator agent with validation/evidence review no independent evidence
purpose: Select and execute multiple/nested calculators while reducing parameter error cascade.
System architecture introduced in §3.3; evidence is comparative experiments, not an external natural entity.

pith-pipeline@v1.1.0-grok45 · 22147 in / 3472 out tokens · 26449 ms · 2026-07-12T06:25:07.380109+00:00 · methodology

0 comments

read the original abstract

Current benchmarks for evaluating large language models (LLMs) in medical calculation are largely based on simplified settings, where each patient case corresponds to a single calculator and the required tool is explicitly specified in the query. However, real clinical scenarios often require multiple calculators for joint evaluation, nested-scale calculation, and fuzzy queries that do not directly specify the target calculator. To this end, we propose a new medical calculation benchmark, MedCalc-Pro, which covers three progressively challenging task settings: single-calculator, multi-calculator, and nested-calculator calculation settings. MedCalc-Pro contains 2,268 real-world clinical cases, covering 77 medical calculators across 14 clinical departments. Meanwhile, to address the limited performance of existing frameworks and methods in complex clinical scenarios, we further propose a more generalizable agent framework that supports multi-tool selection and nested-tool calling, while suppressing parameter error propagation through structured validation and evidence review. We conduct systematic comparisons across open-source, closed-source, and medical-specialized LLMs, and the results show that our framework achieves the best performance across all three task settings. This work provides a new benchmark and method for evaluating and applying LLMs in challenging medical calculation scenarios.

Figures

Figures reproduced from arXiv: 2607.02879 by Chennuo Zhang, Ruihui Hou, Siran Zhao, Tong Ruan, Ziyue Huai.

**Figure 2.** Figure 2: Overview of our framework. This agent contains four stages: Query Rewriting, Retrieval and Reranking, [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

discussion (0)

Reference graph

Works this paper leans on

14 extracted references · 4 linked inside Pith

[1]

arXiv preprint arXiv:2508.10925

gpt-oss-120b & gpt-oss-20b model card. arXiv preprint arXiv:2508.10925. Jianlyu Chen, Shitao Xiao, Peitian Zhang, Kun Luo, Defu Lian, and Zheng Liu. 2024. M3- embedding: Multi-linguality, multi-functionality, multi-granularity text embeddings through self- knowledge distillation. InFindings of the associa- tion for computational linguistics: ACL 2024, pag...

Pith/arXiv arXiv 2024
[2]

Dan Hendrycks, Collin Burns, Saurav Kadavath, Akul Arora, Steven Basart, Eric Tang, Dawn Song, and Jacob Steinhardt

Training large language models to rea- son in a continuous latent space.arXiv preprint arXiv:2412.06769. Dan Hendrycks, Collin Burns, Saurav Kadavath, Akul Arora, Steven Basart, Eric Tang, Dawn Song, and Jacob Steinhardt. 2021. Measuring mathematical problem solving with the MATH dataset. InThirty- fifth Conference on Neural Information Processing Systems...

Pith/arXiv arXiv 2021
[3]

Nature Communications, 16(1):9377

Agentmd: Empowering language agents for risk prediction with large-scale clinical tool learning. Nature Communications, 16(1):9377. Nikhil Khandekar, Qiao Jin, Guangzhi Xiong, Soren Dunn, Serina Applebaum, Zain Anwar, Maame Sarfo-Gyamfi, Conrad Safranek, Abid Anwar, An- drew Zhang, et al. 2024. Medcalc-bench: Eval- uating large language models for medical...

2024
[4]

Shervin Minaee, Tomas Mikolov, Narjes Nikzad, Meysam Chenaghlu, Richard Socher, Xavier Am- atriain, and Jianfeng Gao

Deepseek-v3 technical report.arXiv preprint arXiv:2412.19437. Shervin Minaee, Tomas Mikolov, Narjes Nikzad, Meysam Chenaghlu, Richard Socher, Xavier Am- atriain, and Jianfeng Gao. 2024. Large lan- guage models: A survey.arXiv preprint arXiv:2402.06196. Karel GM Moons, Douglas G Altman, Johannes B Re- itsma, John PA Ioannidis, Petra Macaskill, Ewout W Stey...

Pith/arXiv arXiv 2024
[5]

which tool should be used

React: Synergizing reasoning and acting in language models. InThe eleventh international con- ference on learning representations. Ailing Yu, Lan Yao, Jingnan Liu, Zhe Chen, Jiajun Yin, Yuan Wang, Xinhao Liao, Zhiling Ye, Ji Li, Yun Yue, et al. 2025. Medresearcher-r1: Expert- level medical deep researcher via a knowledge- informed trajectory synthesis fra...

Pith/arXiv arXiv 2025
[6]

No scale, score, or rule names in any of the three phrases (e.g., APACHE, Caprini, Wells, PERC, NIHSS, GCS, PHQ are all forbidden)
[7]

Core Function Query here

Phrase 3 (Key Variables) mustNOTsimply list prominent variables from the case; list only variables that are strongly tied to the assessment target and typically used by this class of tool. [Task Type Templates — for guiding Phrase 3 content] • T1 Risk Prediction/Stratification: Phrase 3: risk factors, comorbidities, exposures, surgical/activity status. • ...
[8]

Only output dependencies where parent tool is in Selected Parent Tools
[9]

Child tool does NOT need to be from Candidate Tools — it can be any medical scale/calculator that exists
[10]

Do not add child tools into selected tools; only express them in dependencies
[11]

If any input parameter represents a composite score or scale total , that parameter has a dependency on the corresponding sub-tool

For each selected parent tool, examine its Required Inputs. If any input parameter represents a composite score or scale total , that parameter has a dependency on the corresponding sub-tool
[12]

Raw vitals (temperature, blood pressure, heart rate) are NOT dependencies; scale totals (GCS score, NIHSS score) ARE dependencies

A parameter is a dependency if its value must be COMPUTED via another scoring system, not directly read from the patient record. Raw vitals (temperature, blood pressure, heart rate) are NOT dependencies; scale totals (GCS score, NIHSS score) ARE dependencies
[13]

If no dependency is needed, return {}
[14]

analysis

Keep exact tool IDs and exact parameter names. Output format (strict JSON only): { "analysis": "short reason", "dependencies": { "Parent Tool ID": { "parameter_name_in_parent": "child_tool_id" } } } 15 B.4 Prompt: Fuzzy Query Generation You are a medical benchmark dataset curator. Task: Given a patient case and the ground-truth medical scale(s) that shoul...

[1] [1]

arXiv preprint arXiv:2508.10925

gpt-oss-120b & gpt-oss-20b model card. arXiv preprint arXiv:2508.10925. Jianlyu Chen, Shitao Xiao, Peitian Zhang, Kun Luo, Defu Lian, and Zheng Liu. 2024. M3- embedding: Multi-linguality, multi-functionality, multi-granularity text embeddings through self- knowledge distillation. InFindings of the associa- tion for computational linguistics: ACL 2024, pag...

Pith/arXiv arXiv 2024

[2] [2]

Dan Hendrycks, Collin Burns, Saurav Kadavath, Akul Arora, Steven Basart, Eric Tang, Dawn Song, and Jacob Steinhardt

Training large language models to rea- son in a continuous latent space.arXiv preprint arXiv:2412.06769. Dan Hendrycks, Collin Burns, Saurav Kadavath, Akul Arora, Steven Basart, Eric Tang, Dawn Song, and Jacob Steinhardt. 2021. Measuring mathematical problem solving with the MATH dataset. InThirty- fifth Conference on Neural Information Processing Systems...

Pith/arXiv arXiv 2021

[3] [3]

Nature Communications, 16(1):9377

Agentmd: Empowering language agents for risk prediction with large-scale clinical tool learning. Nature Communications, 16(1):9377. Nikhil Khandekar, Qiao Jin, Guangzhi Xiong, Soren Dunn, Serina Applebaum, Zain Anwar, Maame Sarfo-Gyamfi, Conrad Safranek, Abid Anwar, An- drew Zhang, et al. 2024. Medcalc-bench: Eval- uating large language models for medical...

2024

[4] [4]

Shervin Minaee, Tomas Mikolov, Narjes Nikzad, Meysam Chenaghlu, Richard Socher, Xavier Am- atriain, and Jianfeng Gao

Deepseek-v3 technical report.arXiv preprint arXiv:2412.19437. Shervin Minaee, Tomas Mikolov, Narjes Nikzad, Meysam Chenaghlu, Richard Socher, Xavier Am- atriain, and Jianfeng Gao. 2024. Large lan- guage models: A survey.arXiv preprint arXiv:2402.06196. Karel GM Moons, Douglas G Altman, Johannes B Re- itsma, John PA Ioannidis, Petra Macaskill, Ewout W Stey...

Pith/arXiv arXiv 2024

[5] [5]

which tool should be used

React: Synergizing reasoning and acting in language models. InThe eleventh international con- ference on learning representations. Ailing Yu, Lan Yao, Jingnan Liu, Zhe Chen, Jiajun Yin, Yuan Wang, Xinhao Liao, Zhiling Ye, Ji Li, Yun Yue, et al. 2025. Medresearcher-r1: Expert- level medical deep researcher via a knowledge- informed trajectory synthesis fra...

Pith/arXiv arXiv 2025

[6] [6]

No scale, score, or rule names in any of the three phrases (e.g., APACHE, Caprini, Wells, PERC, NIHSS, GCS, PHQ are all forbidden)

[7] [7]

Core Function Query here

Phrase 3 (Key Variables) mustNOTsimply list prominent variables from the case; list only variables that are strongly tied to the assessment target and typically used by this class of tool. [Task Type Templates — for guiding Phrase 3 content] • T1 Risk Prediction/Stratification: Phrase 3: risk factors, comorbidities, exposures, surgical/activity status. • ...

[8] [8]

Only output dependencies where parent tool is in Selected Parent Tools

[9] [9]

Child tool does NOT need to be from Candidate Tools — it can be any medical scale/calculator that exists

[10] [10]

Do not add child tools into selected tools; only express them in dependencies

[11] [11]

If any input parameter represents a composite score or scale total , that parameter has a dependency on the corresponding sub-tool

For each selected parent tool, examine its Required Inputs. If any input parameter represents a composite score or scale total , that parameter has a dependency on the corresponding sub-tool

[12] [12]

Raw vitals (temperature, blood pressure, heart rate) are NOT dependencies; scale totals (GCS score, NIHSS score) ARE dependencies

A parameter is a dependency if its value must be COMPUTED via another scoring system, not directly read from the patient record. Raw vitals (temperature, blood pressure, heart rate) are NOT dependencies; scale totals (GCS score, NIHSS score) ARE dependencies

[13] [13]

If no dependency is needed, return {}

[14] [14]

analysis

Keep exact tool IDs and exact parameter names. Output format (strict JSON only): { "analysis": "short reason", "dependencies": { "Parent Tool ID": { "parameter_name_in_parent": "child_tool_id" } } } 15 B.4 Prompt: Fuzzy Query Generation You are a medical benchmark dataset curator. Task: Given a patient case and the ground-truth medical scale(s) that shoul...