Home/Offers/Healthcare & Life Sciences/Medical Literature Intelligence API

Healthcare & Life Sciences

Medical Literature Intelligence API

The literature your users need is public, indexed and free to search. What is missing is a way to get from a question to the three papers that answer it with the claims still attached to their sources.

Medical education platforms
Clinical decision support vendors
Pharmaceutical medical affairs teams
Research software providers

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Keyword search over abstracts was adequate when the volume was smaller. A query on a common intervention now returns thousands of records, sorted by relevance rules nobody can inspect, with no indication of which are randomised trials, which are case series and which have been superseded. The user's actual question — what does the evidence say, and how strong is it — is answered by reading, which is why most of it goes unread.

Summarisation is the obvious response and also where most attempts fail. A language model asked to summarise a literature search will produce fluent text containing claims that are not in any of the retrieved papers. In a medical context that is not a quality issue, it is a safety issue. The fix is architectural rather than a matter of better prompting: retrieve first, generate only from retrieved spans, and reject any sentence that cannot be traced to one.

There is also a quality-weighting problem nobody can fully solve. Study design, sample size, retraction status and publication venue are all available and all partial proxies. A system can report them honestly and let the reader weigh them. What it should not do is collapse them into a single authority number that implies more than it knows.

Who buys this

Medical education platforms, Clinical decision support vendors, Pharmaceutical medical affairs teams, Research software providers

Category: Healthcare & Life Sciences

What the API returns

What comes back

Semantic and keyword search across indexed literature with structured filters
Evidence summaries where every sentence carries the citation and span it came from
Study design classification: randomised trial, cohort, case-control, case series, review
Sample size, population and intervention extracted into structured fields
Retraction, correction and expression-of-concern status on every record
Claim-level citation links so a statement can be opened at its source sentence
Contradiction detection where retrieved papers reach opposing conclusions
Publication-date and superseding-review flags so stale findings are visible

Endpoints

Method	Path	Returns
POST	/v1/search	Semantic and filtered search across the index
POST	/v1/evidence/summarise	Citation-linked summary over a retrieved set
GET	/v1/papers/{id}	Structured record with design, population and status
GET	/v1/papers/{id}/citations	Citing and cited works with context
POST	/v1/claims/verify	Check a claim against the retrieved literature
GET	/v1/alerts	New publications matching a saved query

Request and response

illustrative

Request

{
  "question": "Does early mobilisation after hip replacement reduce length of stay?",
  "filters": {
    "design": ["randomised_trial", "systematic_review"],
    "published_after": "2018-01-01",
    "exclude_retracted": true
  },
  "summarise": true,
  "max_sources": 8
}

Response

{
  "query_id": "q_80114",
  "sources_retrieved": 8,
  "summary": [
    {
      "sentence": "Early mobilisation within 24 hours was associated with shorter length of stay in both pooled analyses.",
      "citations": [
        { "paper_id": "pmid_example_31204471", "span": [1842, 1961], "design": "systematic_review" },
        { "paper_id": "pmid_example_29887120", "span": [612, 744], "design": "randomised_trial" }
      ]
    },
    {
      "sentence": "Effect sizes varied with the mobilisation protocol used and were smaller in trials with fewer than 100 participants.",
      "citations": [
        { "paper_id": "pmid_example_33120994", "span": [2210, 2388], "design": "randomised_trial" }
      ]
    }
  ],
  "contradictions": [
    { "topic": "readmission_rate", "papers": ["pmid_example_29887120", "pmid_example_34421100"],
      "note": "Opposing directions reported; populations differ in age distribution" }
  ],
  "excluded": [ { "paper_id": "pmid_example_28110022", "reason": "retracted_2021" } ],
  "unsupported_claims_withheld": 2
}

Where the data comes from

Public bibliographic databases	Indexed records and abstracts from the open biomedical literature, which is the backbone of coverage
Open access full text	Where the licence permits, full text makes extraction and span-level citation substantially better than abstract-only
Publisher licences for paywalled full text	Needed for broad full-text coverage; the cost and the terms differ per publisher and get identified during discovery
Retraction and correction notices	Published retraction records, which must be checked on every retrieval rather than at index time
Trial registries	Registered protocols and results, which expose outcome switching and unpublished trials
Clinical terminologies	For query expansion, so a search on a brand name finds papers written about the ingredient

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Retrieval-augmented generation with hard grounding: generated sentences are rejected unless every clause maps to a retrieved span
A verification pass that re-checks each summary sentence against its cited spans and withholds the sentence on failure, reporting the count withheld
Hybrid retrieval combining dense embeddings with lexical search, because exact drug and gene names defeat embeddings alone
Study design classification from methods sections, with confidence and abstention rather than a forced label
Retraction status resolved at query time, since a paper indexed as sound may have been retracted since
Contradiction detection by comparing extracted effect directions across retrieved papers on the same outcome
Deliberate refusal to emit a single evidence-quality score; design, size, venue and recency are returned separately for the reader to weigh
Continuous evaluation against question sets with known answers, measuring both unsupported-claim rate and missed-source rate

What it changes for the business

Questions answered in the product

Users get from a question to sourced findings without leaving your tool for a general search engine.

Citations that survive scrutiny

Every claim opens at its source sentence, which is what makes the output usable in teaching and medical affairs work.

Retraction hygiene

Withdrawn papers are excluded at query time rather than quietly persisting in saved searches and slide decks.

Monitoring without manual sweeps

Saved queries surface new publications as they appear instead of relying on somebody remembering to re-run a search.

How it fits into your product

How it embeds

REST search and summarisation endpoints your existing interface can call directly
Embeddable search and evidence-panel components where you would rather not build the front end
Webhooks and digest delivery for saved-query alerts
Entitlement controls so full-text access matches the licences you actually hold
Per-tenant query logging for audit, and optional deployment in your own environment
Localisation of interface strings, with summaries generated in the language of the source text by default

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Will the summaries ever state something the papers do not say?

The architecture is built to make that fail closed rather than fail quietly: sentences that cannot be traced to a retrieved span are withheld, and the response reports how many were withheld. That reduces unsupported claims substantially, and it does not reduce them to zero. Anything presented to a clinical audience needs the citation links visible and a human in the loop, and we would build the interface to make checking the source the easy action.

Does this give clinical recommendations?

No. It reports what published studies found, with their design and population attached. It does not advise on a patient, suggest a treatment, or tell a clinician what to do. Whether your product then crosses into decision support is a regulatory question for you, and the answer changes what has to be built around this layer.

Why is there no single evidence quality score?

Because it would imply a precision that does not exist. Design, sample size, venue, recency and replication all matter and trade off against each other differently per question. Collapsing them into one number hides the trade-off and gets cited as though it were measured. We return the components.

How much full text can you actually index?

Open access full text is straightforward. Paywalled content requires publisher licences, priced per publisher and sometimes restricted in ways that forbid redistribution of extracted spans inside a commercial product. Abstract-only coverage is broad but weakens span-level citation. We map the licence position in discovery so you know what coverage you are buying.

How current is the index?

New records are ingested on a daily cycle and retraction status is checked at query time. Note that indexing lag in the upstream databases themselves is outside our control, so very recent preprints and just-published papers may not appear immediately.

All Healthcare & Life Sciences offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers