NICE and PBAC oncology decisions, extracted into structured fields, every value cited to its source passage. Ask how both bodies ruled on the same drug and see each answer in its own framework, in one query.
HTA decisions are public PDFs, hundreds of pages each. What HTA Core adds is the structured record underneath them: field-level facts your team and your agents can query, verify and build on. Cited to the passage, scored for confidence, reproducible as of any date, and served in each body's own framework.
The question "every decision for drug X in indication Y" is a single call across NICE and PBAC, and each verdict arrives in its own framework: NICE's ICER against a willingness-to-pay range, PBAC's structured clinical claim. Same drug, same trial, sometimes opposite calls, shown side by side and never force-normalised into one score.
Document, section, character offsets, returned inline with the value. An analyst can verify any number in seconds, and an audit trail is a copy-paste away: the first thing your regulator and your legal team ask for, attached to every response.
Confidential discounts, redacted ICERs, dates never stated: much of what matters is
deliberately unpublished. Those fields come back as typed absences
(confidential_redacted is not not_stated), never as a fabricated
number. If we can't cite it, we don't assert it.
Every field returns a confidence score built to be calibrated: a 0.95 should mean agreement with a domain expert 95% of the time. The golden-set review that proves it (experts who read these documents professionally scoring the pipeline's extraction field by field) is being set up now, and we're recruiting the reviewers. Until then the scores are labelled for what they are: the pipeline's own estimate.
Every assertion is versioned. Pin any query to a past date and get the answer your team would have gotten on that date: the same number, the same citation, every time. Briefs, models, and submissions become reproducible by default.
NICE and PBAC decisions, extracted at field level with passage-level citations and confidence per field, each body in its own framework. Click a decision, then a field: the real source passage and validation trail open on the right. These are highlight fields from each record; the full record an agent gets runs much deeper (comparators, trials, restrictions, critiques), every value cited and scored exactly like this.
Real extractions from the HTA Core corpus: NICE and PBAC decisions, each field traced to its source passage. A sample of each record's fields; values reflect the published guidance and PSDs as extracted.
HTA Core ships agent-first: a typed MCP server that Claude, Cursor and any MCP-aware client can call today. Citations and confidence ride along on every field, and each body stays in its own framework. Underneath is one canonical decision record, the same structured shape every surface serves; a resource-oriented REST API over that record follows.
You › How did NICE and the PBAC differ on belantamab mafodotin?
Claude › compare_decisions({"assessment_ids":
["uk-nice-ta1149", "au-pbac-2025-11-belantamab-mafodotin-nov2025"]})
Claude › NICE recommended it, restricted to adults with one prior line of
therapy: the committee found the ICERs "within the range NICE considers
a cost-effective use of NHS resources" [TA1149 · final draft guidance
§3.22 p.28] — that range being £25,000–£35,000/QALY [§3.21 p.26].
The PBAC did not recommend it, despite accepting the efficacy claim:
"the primary reason for this outcome was the proposed place in therapy"
[PBAC 5.02 · PSD §7 p.43], and on the ITT population the ICER rose to
$115,000–135,000/QALY [PSD §PBAC outcome p.45].
Every claim above carries its citation; none of it is my recall. // → request: compare the same drug across bodies
{
"method": "tools/call",
"params": {
"name": "compare_decisions",
"arguments": {
"assessment_ids": ["uk-nice-ta1149",
"au-pbac-2025-11-belantamab-mafodotin-nov2025"]
}
}
}
// ← response (truncated): each body in its OWN framework, never normalised
{
"decisions": [
{ "hta_body": "NICE", "decision_outcome": "recommended_with_restrictions",
"framework": "nice_qaly_with_severity" },
{ "hta_body": "PBAC", "decision_outcome": "not_recommended",
"framework": "pbac_clinical_claim",
"clinical_claim": "superior efficacy · inferior safety",
"pbac_view": { "efficacy": "accepted" } }
],
"glossary": { "framework": { "pbac_clinical_claim": "PBAC — clinical claim" } }
} // the canonical decision record: one shape, every surface
{
"assessment_id": "uk-nice-ta1149",
"source_reference": "TA1149", // body-native locator
"hta_body": "NICE",
"decision_date": "2026-04",
"decision_outcome": "recommended_with_restrictions",
"drug": { "inn": "belantamab mafodotin", "brand_names": ["Blenrep"] },
"indication": "Relapsed/refractory multiple myeloma · 2L",
"body_specific_evaluation": {
"framework": "nice_qaly_with_severity",
"wtp_threshold": { "min": 25000, "max": 35000, "currency": "GBP" },
"severity_modifier": { "applied": false, "weight": 1 }
},
"committee_preferred_icer": {
"value": null,
"value_absence": "confidential_redacted", // not zero: typed absence
"price_basis": "confidential_pas_all",
"confidence_score": 0.90,
"citation": "NICE TA1149 — Final draft guidance, §3.22 p.28: \"the deterministic and probabilistic ICERs for Bel-Bor-Dex were within the range NICE considers a cost-effective use of NHS resources\""
},
"glossary": { "value_absence": { "confidential_redacted": "truth withheld (confidential PAS)" } },
"_meta": { "as_of_date": "2026-07-20" }
} // one Assessment: the hub every extraction fills
Assessment
├── drug // regimens first-class (combination therapies)
├── indication // + decomposable patient subpopulation
├── body_specific_evaluation // nice_qaly_with_severity | pbac_clinical_claim
├── comparator[] // kind, role, disputed flag
├── trial[] // NCT-linked · accepted vs disputed
├── endpoint[] // OS, PFS, ORR… as structured rows
├── economic_analysis // ICERs incl. disclosed_values[] + price_basis
├── pricing // list-price packs; confidential PAS stays typed-absent
├── restriction[] // typed · narrows_marketing_authorization flag
├── decision_modifier[] // severity, end-of-life, innovation
├── managed_access_agreement[] // CDF / risk-share terms, bitemporal
├── critique[] // committee-cited uncertainties, typed
└── lifecycle_linkage[] // resubmissions & re-assessments
// every value above ships as {value, citation, confidence, provenance}
// drug / indication / trial resolve to canonical ids, so cross-body
// comparison and resubmission lineage are plain SQL joins, not magic The answer isn't the point — what the answer is made of is. Because every value comes back structured and cited, it composes: into a chart that carries its own denominator, a spreadsheet you can code from, a check against the draft on your desk. Three exchanges below, each reproducible against the corpus as it stands today.
You › Across our NICE oncology set, how often is a committee-preferred
ICER actually disclosed? I don't want a mean over a sparse field.
Claude › get_coverage() → field_coverage.economics.committee_preferred_icer
Of 72 NICE decisions, 16 are terminated appraisals that carry no economic
evaluation — excluded from the denominator, not counted as missing. That
leaves 56 where an ICER could apply:
disclosed 19
withheld_only 19 ← a real number exists; it is confidential
qualitative_only 1 ← a published dominance result, not a gap
no_estimate_recorded 17
So: 19 of 56. I can't give you a mean committee ICER over this field. A
third of it is disclosed, and the average would describe 19 decisions
while looking like it describes 72. You › Every decision either body made in EGFR-mutant first-line NSCLC,
as a CSV I can code from — one row per decision, the committee's own
critique categories, and enough to trace each row back.
Claude › search_decisions({"condition": "EGFR-mutant … NSCLC (first line)",
"facet": "critiques"}) → 5 decisions, 2 bodies
Wrote egfr_1l_nsclc.csv — 5 rows:
body,source_ref,drug,outcome,verdict,lead_critique,severity,n_critiques
NICE,TA1122,amivantamab + lazertinib,recommended,cost_effective,crit:generalisability,major,13
NICE,TA1060,osimertinib + pemetrexed,recommended,cost_effective,crit:survival_extrapolation,major,10
PBAC,7.01 (Sep 2025),osimertinib + chemotherapy,recommended,cost_effective,crit:immature_survival_data,major,6
PBAC,6.04 (May 2025),osimertinib + chemotherapy,not_recommended,acceptable_only_at_lower_price,crit:immature_survival_data,major,11
PBAC,5.01 (Mar 2025),amivantamab + lazertinib,not_recommended,not_cost_effective,crit:immature_survival_data,major,15
Immature overall-survival data leads all three PBAC critiques here; NICE's
lead concerns are generalisability and extrapolation. 55 critiques across
the five, each traceable — get_decision("uk-nice-ta1122",
sections=["critiques"]) returns the passage itself:
"People over 65 years may plausibly get less benefit from amivantamab plus
lazertinib, which may be a generalisability issue."
[TA1122 · final draft guidance §3.5 p.9] You › [attached: draft_submission_v3.docx]
We're proposing a second-line-only listing with DBd as the sole
comparator. Check that against what the committee has actually done.
Claude › search_decisions({"drug": "belantamab mafodotin"}) → 3 decisions
get_decision("au-pbac-2025-11-belantamab-mafodotin-nov2025",
sections=["comparators", "critiques"])
Two flags, both from the November 2025 consideration of this regimen.
1 · Place in therapy — the stated primary reason for that negative outcome:
"The PBAC considered that the primary reason for this outcome was the
proposed place in therapy" [PSD §7 PBAC Outcome p.43]
Your draft proposes the same second-line-only positioning.
2 · Sole comparator — DBd was accepted for a second-line listing, but the
ESC held that "the most appropriate comparator would consist of a
basket of treatments that included DBd" [PSD §5.2 p.8], and the PBAC
advised that for a broader RRMM listing "a mixed comparator that
consisted of daratumumab, carfilzomib, pomalidomide, selinexor and
elotuzumab would be reasonable" [PSD §7 PBAC Outcome p.44]
None of that is your document checked against my own recall. It's your
document checked against the committee's published words. The REVIEW tab's attachment stands in for your document; everything HTA Core contributes to that exchange is real and quoted.
A consultant's slide, a competitor's press release, an internal assumption, another model's confident recall — hand it over and ask what the committees actually said. Grounding is the product; using it to catch fabrications is the sharpest form of that.
Has any committee accepted this comparator in this setting? A curated, counted corpus can answer no. A model reading PDFs cannot tell you the difference between never happened and I didn't find it — and absence of precedent is often the thing you needed to know.
Filter on the shape of the committee's objection — immature survival data, disputed ITC, subgroup validity, a restriction type — not on the drug name. Dashboards filter metadata; the argument is what you're actually looking for.
Pull an asset list from your portfolio system, query HTA Core per asset, write the precedent back. Join a trial's readout date to what committees said about its immaturity. Post new decisions in your indications to a channel. Any MCP-aware agent, any MCP server on the other side.
A scheduled agent watching your indications is a change-alert we never had to build. One agent per asset across a portfolio produces forty precedent sheets in the time one analyst opens one PDF. Typed tools, stable ids, honest scope — designed to be called by software.
Pin the corpus with as_of and the extract behind a paper is reproducible years later — better than a folder of PDFs downloaded one March. Free for academic, student and journalism use, and the corrections you send back become the golden set.
The last three need something on the other end — your MCP servers, your scheduler, your stack. That's the point of being a layer rather than an app: we don't have to have imagined your workflow for you to build it. Bring the one you'd want to try →
Every field has to clear two bars: it has to be right and checkable, and it has to line up with the rest of the corpus well enough to query. Neither comes free from a well-written prompt. The failure modes below were found the ordinary way — building the extractor, running it against real appraisals, and looking hard at where it went confidently wrong — and each one now has a mechanism standing against it.
Grounding proves a quote is in the document.
It does not prove the quote is about the field.
Extract the value first, then go hunting for a citation, and the model finds a plausible nearby sentence and stops looking.
A passage about a ten-year time horizon structurally cannot yield a cost-per-QALY figure, so a mismatch produces a low-confidence null instead of a confident number wearing the wrong citation. A field that fails a check re-runs that joint extraction — there is deliberately no “find a better citation for this value” pass, because that is the same failure walking back in through the repair door.
Right section, wrong sentence. The quote is real, the value is real, and the quote still isn't evidence for it.
A weak score blocks the field or lowers its confidence rather than being quietly dropped — and it applies to corroborating passages too, since an unentailed corroboration would raise confidence, which is the worst direction to be wrong in.
Nothing clean to cite. A redacted ratio has no “the ICER is £X” sentence anywhere in the document — and a field with nothing clean to point at is where mis-citation clustered worst.
Cheaper rules run underneath: a monetary field's quote must carry a currency figure or an explicit confidentiality phrase, a date field's must carry a date. And when two different fields cite the same span, that collision is routed to review rather than silently accepted.
Constrain the model to today's categories and a new finding gets forced into the nearest bucket. Leave it unconstrained and you get forty spellings of one critique — prose, not data.
Where the framework closes it (how a value can be absent, what judgments the PBAC can reach) the vocabulary is closed, enforced from a single source of truth, and served to agents, so a calling model discovers the legal values rather than guessing. Where the world keeps producing new members (critique types, restrictions, drugs, trials) the taxonomy is open and appendable, the raw wording is always kept, and recurring values are promoted to canonical entries under review. A classification that doesn't fit stays null and visible as a gap, never forced into one.
The same drug under different names. Two bodies name regimens differently and decompose combinations differently, so “every decision for this drug” becomes a text search that misses.
Resolution at query time is exact-match only: on a miss you get ranked candidates and their corpus membership, never a silent correction. A product whose whole value is auditability cannot have a query layer that quietly decides what you meant — and the calling agent already normalises intent, so the server's job is to be deterministic.
Three layers that reinforce each other: structural, so value and quote can't diverge; deterministic, so cheap rules catch what they can without a model; semantic, where a judge decides whether the passage really carries the claim. None of it asks you to take the model's word for anything.
Every NICE oncology decision published since January 2025, and every PBAC oncology PSD through the November 2025 meeting, fully extracted, with the whole 2020→ universe crawled and counted behind it. Going wider is deliberate, partner-steered work: early users set the order, not the destination.
HTA Core is built by Jared Brook in Melbourne. The thesis is simple: the analyst labour that made HTA intelligence expensive (reading 200-page appraisals into structured rows) is exactly the work LLMs now do well, and the output should come with citations, confidence scores and honest nulls, served through an API your team and your agents can call. The mission is every HTA decision, every jurisdiction; being PBAC-local is deliberate, because the cross-jurisdiction graph starts on home turf.
Market-access teams, HEOR consultancies and agent builders with a real cross-decision question (a drug, an indication, a resubmission), willing to run it against the corpus and be blunt about where it falls short. Early partners steer what gets extracted next: deeper history, adjacent indications, another body. You get early access and a corpus shaped around your actual questions; we get the questions that matter.
Become a design partner →If you publish on HTA decision-making (precedent studies, cross-jurisdiction comparisons, PSD and FAD mining), HTA Core is free for academic, student and journalism use. You get the corpus as a queryable, cited API instead of a folder of PDFs; we get expert eyes on the extraction: the corrections that become the golden set gating every release.
Ask about research access →The HTA dashboard your team may already use is built for a person browsing a screen, and today it covers more bodies than we do. HTA Core isn't another one of those. Read the table top-to-bottom: the things a dashboard is built for, and the things a cited, callable data layer is built for, barely overlap. You don't swap one for the other; you add the layer the dashboard category was never built to be.
"Why can't my dashboard just do this?" Not because it's behind, but because a human-facing dashboard and a callable, cited data layer are different things. We're built to be the second; often you'll want both. The comparison is with the dashboard category, not any specific product; individual products vary.
Two bodies today, NICE and PBAC, and the schema accepts the next with no migration. The question every market-access team asks ("every decision globally for drug X in indication Y, with comparator and ICER, as of date Z") is already a single call across both, and stays one as more bodies come online.
The decision → drug → decision traversal
across bodies works today on the NICE × PBAC pair. Each subsequent HTA body is a new set of
nodes and edges against the same schema: no migrations, no graph database, no breaking change.
Bring an indication or a drug your team is working on. On the call we answer it live from the corpus: the NICE and PBAC verdicts side by side, each in its own framework, with the citations. And if your question lands outside the extracted window, you'll be told exactly that. Then it goes to the front of the extraction queue.