EvidenceHub — Check a claim. See the evidence.

What it does

Two checks, one evidence pipeline.

The same evidence engine that powers the TLG Claims Validation Platform, exposed as an API your team can call from a reviewer tool, an internal workflow, or an AI agent.

Check a claim

Submit a single marketing or medical claim about a drug. Receive a verdict (Supported, Partial, Unsupported), a four-dimension evidence score on Population, Endpoint, Magnitude, and Context, and the source quotes that produced the score.

Verify a reference

Submit a citation or DOI. Confirm whether it is current, retracted, the subject of an erratum or expression of concern, or beyond your freshness threshold — sourced from PubMed, Europe PMC, and Crossref.

Repeat checks cost less

When the same claim has been checked before and the evidence has not changed, the AI scoring step — the slowest, most expensive part — is skipped. You get a fully attributable verdict at a fraction of the per-call cost, with the original source timestamps intact.

FAQ

Frequently asked questions.

What it does, where the evidence comes from, and how it fits your security and identity stack. Workflow integration patterns are in the next section.

What does EvidenceHub actually do for our team?

It answers one question: "is there evidence to support this claim?" Your reviewer (or your reviewer tool, or your AI agent) submits a claim about a drug; we return a verdict plus the source quotes from authoritative databases that produced it. It removes the manual step of opening five tabs to DailyMed, PubMed, openFDA, and ClinicalTrials.gov and reading them yourself.

How do we know the verdict is not the AI hallucinating an answer?

Every verdict cites the source quote that produced it — DailyMed section, Europe PMC abstract, ClinicalTrials.gov record, openFDA adverse-event report. If the AI cannot find supporting evidence, it returns Unsupported with the absence noted, not a guessed answer. The grounding gate is hard: no quote, no claim. The reviewer can click through to the original source for verification.

Where does the evidence come from?

DailyMed (FDA-approved drug labels), openFDA (FAERS adverse events and Drugs@FDA approvals), Europe PMC (peer-reviewed biomedical literature), PubMed, ClinicalTrials.gov, Crossref (publication metadata and retraction notices), and Health Canada DPD. All authoritative, all federally maintained or peer-reviewed. No scraped sources, no third-party aggregators.

Is this regulated-industry ready?

EvidenceHub is decision support for human reviewers, not a regulatory determination. Every verdict carries the source provenance your MLR, PRC, or compliance team needs to defend a decision in audit. The system is designed for pharma and medical-device review workflows; it is not an FDA-cleared device and does not replace your sign-off process.

Who controls our API keys?

You do. Your team uploads a public key in the admin UI; the matching private key never leaves your infrastructure. We never see, store, or transmit the private key. Key rotation, revocation, and restoration are handled by your designated SECURITY_GROUP role — a separate role from your billing or membership admin, gated by step-up authentication and 2FA. If a key is compromised, your team revokes it without involving us.

Can our identity team manage admin access through Microsoft Entra ID?

Yes. Sign-on via Microsoft Entra ID (work/school accounts) is built in — OAuth 2.1 with PKCE, refresh-token rotation, and exact-match redirect URIs. The Liggett Group is a registered Microsoft Partner (Microsoft AI Partner), which is what enables the verified-publisher checkmark you will see in your Entra admin center when you grant consent. We also support Google Workspace SSO and FIDO2 passkeys. Your existing IdP controls who can sign in; sessions are revalidated against your IdP every 60 minutes, so disabling a user in your tenant revokes their EvidenceHub access without involving us.

How does pricing work?

Per-call billing with cache discounts: a fresh check costs the full per-call price; a cache hit on the same claim costs a fraction of that. Volumes, term, and discounts are negotiated per organization — tell us about your expected volume and we will quote it.

How do we get started?

Three steps: (1) request access using the button at the top of this page; (2) once provisioned, your SECURITY_GROUP designee uploads an RSA or EC public key in the admin UI and proves possession by signing a one-time nonce with the matching private key; (3) you receive your API key plus two deterministic test payloads — one per endpoint — that let your developers exercise the production endpoints without consuming credits.

Integration FAQ

Integrating it into your workflow.

Three common patterns for weaving EvidenceHub into a review process — what each one looks like and where it fits. The protocol details (canonical signing format, polling cadence, error code catalog, OpenAPI spec) live at the integration reference linked at the end of this section.

How do teams typically integrate this into a review workflow?

There are three common patterns. REST submit + MCP monitor: your reviewer tool kicks off a check, an MCP-aware agent in the reviewer's workspace picks up the verdict when it lands. Interactive UI + MCP: a writer or reviewer iterates on draft claims in their authoring tool while the agent re-checks evidence on the fly. Batch via REST: a pre-launch or end-of-day sweep over a queue of claims. None requires platform-side changes; pick what fits your team's habits.

Pattern: REST to submit, MCP to deliver the verdict — when does that fit?

When your reviewers live in an existing dashboard, queue, or chat tool and you do not want them parked on a polling screen. The REST submit is a one-line call from your back-end; the MCP-aware agent — Claude Code, Cursor, an internal Slack bot, or a custom agent — listens for the completed verdict and delivers it into whichever surface your reviewer is already watching. Decouples the kickoff step from the result step, so verdicts arrive where work is happening.

Pattern: Live UI + MCP for iterative claim authoring — when does that fit?

When the human in the loop is a copywriter, medical writer, or medical reviewer drafting language and wants the evidence check available as they write. The MCP-aware agent in their authoring tool runs a check on each new claim, paragraph break, or save, then surfaces "this phrasing is Unsupported by DailyMed" alongside the draft with the source quote inline. Tightens the feedback loop from "send to MLR and wait days" to "fix it before you send it."

Pattern: Batch via REST for pre-launch or weekly sweeps — when does that fit?

When you already have a queue of approved or pending claims — a campaign workspace, a label comparison run, a regulatory filing prep — and you want every claim checked at once. POST the queue, poll for completions, write verdicts and source quotes into your audit trail. Cache hits make the second sweep over a stable claim set inexpensive, which is what makes weekly or pre-meeting re-checks affordable.

What does cache behavior mean for our user experience?

A cache hit returns inline in milliseconds with the verdict and source quotes — your UI shows the answer immediately. A cache miss takes roughly 20-30 seconds because the AI scoring step runs end-to-end; your UI should show a progress indicator while the MCP or polling path picks up the result when it is ready. Identical claims with unchanged underlying evidence stay cached, so the first reviewer pays the full per-call price and everyone after pays the cache rate.

Is there a sandbox or test mode for development?

Yes. Every API key includes two deterministic test payloads — one per endpoint — that exercise the production endpoints without consuming credits and return canned verdicts. Use them in CI to verify your signing logic, your retry logic, and your MCP wiring before charging a credit on a real claim.

How should we handle retries and avoid duplicate charges?

Send an Idempotency-Key header (UUID v7) with every submit. Same key + same body returns the original job's result. Same key + different body returns 409. Keys expire after 24 hours, so retries within that window are safe; retries after it create a new job. Full reference at /hub/docs/#idempotency.

Open the full integration reference →

Identity and access

Manage access from your Entra tenant.

EvidenceHub federates with Microsoft Entra ID for sign-in, role assignment, and audit. Once your organization is provisioned, your identity admin manages who has access and what they can do — directly from Entra, without a separate admin console.

Sign-in via your tenant

Your users sign into EvidenceHub through your Entra tenant's SSO flow. No separate password to remember; conditional access policies you have already configured apply unchanged.

Roles from group claims

EvidenceHub roles resolve from Entra security groups. Adding a user to an EvidenceHub admin group grants admin access; removing them revokes it. No separate user management surface in EvidenceHub.

Audit trail to your IdP

Sign-in events, role changes, and key-management actions emit through your Entra audit feed alongside the rest of your tenant's activity. Your security team's existing dashboards cover EvidenceHub without new tooling.

API calls continue to use RSA-signed canonical-string authentication, independent of Entra. Billing and credit balance are managed in the EvidenceHub admin UI, outside Entra scope.

Open the Entra setup reference →

Check a claim. See the evidence.