Concepts and core ideas in Axelium

Questions and frameworks (PICO & PEO)

PICO and PEO are structured frameworks for defining answerable review questions. Use PICO for intervention questions where you compare interventions against a comparator and assess outcomes. Use PEO for prevalence and risk-factor questions focused on exposure and outcomes in a population.

Axelium supports both frameworks in the same project library so intervention and prevalence workflows can be managed consistently.

app.axelium.io · Configure

Additional sources and the additive-search model

The built-in Literature Search runs against PubMed and ClinicalTrials.gov. Additional sources extend that without modifying the main flow: five free providers are available today (OpenAlex, Europe PMC, MAUDE, ERIC, CENTRAL approximation), each implemented as a sibling route that writes through a shared persist-additional-results helper. Every provider result is deduplicated against studies already in the analysis by DOI, PMID, NCT ID, or title + year, so enabling a second database never double-counts papers.

Each study carries a foundInProviders tag listing every database that surfaced it — the data PRISMA reporting uses to say “records identified through database X”.

app.axelium.io · Search

Citation chasing (the Discover page)

Citation chasing means walking paper references (backward) and citers (forward) from a set of known-relevant seed papers, to surface related work that text-based search would miss — e.g. because of terminology drift (“heart attack” vs. “myocardial infarction”) or because a paper isn't yet indexed in MEDLINE.

Cochrane explicitly recommends the technique in Handbook §4.3.3. Axelium's Discover page (sidebar link) automates it via Semantic Scholar's citation graph (~220M papers). Candidates are ranked by how many of your seeds they connect to, and adding selections flows through the same cross-provider dedupe as every database.

This is a second discovery surface — complementary to text search, not a replacement. It's most useful after you have an initial included-paper set (2+ included studies) to seed from.

app.axelium.io · Discover

Refinement suggestions: PICO decomposition + pearl growing

The Suggestions drawer on the Search Query card runs read-only diagnostics on your current query and produces copy-to-clipboard refinement chips. Two techniques are available today:

• PICO decomposition — executes each PICO clause (Population, Intervention, Outcomes) as a separate PubMed count, identifies the most-restrictive (bottleneck) clause, and suggests broadening techniques.
• Pearl growing — given 1–10 PMIDs of known-relevant papers, fetches their MeSH headings and author keywords and scores each term by how many pearls share it. The Cochrane-sanctioned technique for improving recall without hand-crafting synonym lists.

The drawer never modifies your query automatically — every change is a deliberate copy-paste, preserving the existing locked-queries + planHash flow as the authoritative source of what gets searched.

app.axelium.io · Search

Pearls vs. seed PMIDs

Two separate knobs on the Search page attach known-relevant PubMed IDs to a run. They look similar but serve different purposes:

• Pearls (up to 5 PMIDs, editable from the "Seed studies (pearls)" card on the Search page) drive enrichment. Their MeSH headings and author keywords are fetched from Europe PMC and folded into the plan so the agent sees vocabulary you couldn't pre-specify. They're also wrapped into the final PubMed term as an OR (PMID[UID]) clause so they're guaranteed to be surfaced.
• Seed PMIDs (up to 20, configured via the admin-level config.search.settings.seed_pmids) drive guaranteed recall. They're unioned with pearls at runtime, wrapped into the same OR (PMID[UID]) clause, and — if the search still misses any of them — each one is directly ESummary-fetched and upserted in a post-fetch step. Use this list for papers you absolutely cannot lose, even when PubMed indexing is incomplete.

Both lists are PMIDs only (numeric). DOIs and NCT IDs are not supported here — the runtime wrap only understands the PubMed [UID] tag.

RIS, BibTeX, and reference-manager handoff

RIS (Research Information Systems) and BibTeX are the two standard text formats for moving citations between tools. Every major reference manager (EndNote, Zotero, Mendeley, JabRef) reads and writes them, as do the article databases (PubMed, Embase, Web of Science, Ovid).

Axelium accepts both on import (Literature Search → Import RIS / BibTeX) and emits both on export (Export RIS / Export BibTeX). Imports are deduplicated against studies already in the analysis by DOI, PMID, NCT ID, and normalised title + year. Exports preserve volume, issue, pages, keywords, publisher, ISSN/ISBN, language, and all identifiers so a round trip through an external tool is lossless.

RevMan 5 (.rm5) and the Cochrane authoring handoff

RevMan (Review Manager) is Cochrane's official authoring tool for systematic reviews. The .rm5 file format is its XML export and is accepted by both RevMan 5 Desktop and RevMan Web.

Axelium's Export RevMan action bundles the included studies, excluded studies (with screening reasons), and every extracted outcome into a single .rm5 file. Outcomes are sorted into RevMan's three comparison element types by effect measure — DICH_OUTCOME for RR/OR/RD, CONT_OUTCOME for MD/SMD, IV_OUTCOME for HR/IRR/Rate — and HR/IRR are log-transformed to match RevMan's inverse-variance convention. Single-arm and qualitative measures (Proportion, Mean, Count, Themes) do not map into RevMan and are listed in PUBLISHED_NOTES so nothing silently disappears.

Risk-of-bias judgements are not yet captured in Axelium, so the QUALITY_ITEMS block is emitted empty — authors complete their RoB 2.0 assessments inside RevMan after import.

Endpoints and effect measures

Endpoints are the specific quantities you plan to analyze, such as risk of event, mean change, hazard ratio, or prevalence. Effect measures describe how results are represented and pooled across studies.

Axelium supports common measures including RR, OR, HR, MD, SMD, and proportions. Default measures are suggested from endpoint type, and you can override them when your protocol requires a different choice.

Screening, confidence, and unsure resolution

Screening is where PICO/PEO criteria are applied to each study's abstract to decide inclusion. The AI screener returns a confidence score (0–1) alongside its decision. Three mechanisms help reduce ambiguous “unsure” outcomes:

• Confidence bands — Two thresholds define three zones: auto‑include (high confidence + PICO match), unsure (mid‑range), and auto‑exclude (low confidence + unconfirmed criteria). This prevents very‑low‑confidence matches from inflating the unsure bucket.
• Custom screening instructions — Free‑text guidance appended to the AI prompt to resolve recurring domain ambiguities (e.g., “treat community‑based delivery as a valid intervention”). Updated at any time from the screening configuration panel.
• Escalation (two‑pass screening) — A second AI pass for remaining unsure studies that includes the first‑pass reasoning and forces a definitive decision. Configurable tie‑breaker bias (include or exclude) and lower confidence threshold.
• Unsure diagnostics — Automated analysis of why studies were marked unsure, with categorized reasons and suggested PICO edits. Helps identify whether the research question itself needs refinement.

Review modes: single, AI + me, two humans

Every analysis runs in one of three review modes, chosen in the configuration sidebar. The mode controls how many reviewers each study needs before its inclusion decision is considered final, and whether the AI screener counts as one of those reviewers.

• Single reviewer — one human screens each study. The AI still provides its own confidence-scored decision but there is no conflict gate; this is the fastest workflow and the default for new analyses.
• Dual: AI + me — the AI screener fills Reviewer A for every study and you act as Reviewer B. Both decisions are recorded independently, the blinding rule hides the AI's verdict until you submit your own, and disagreements flow to the conflict queue for adjudication.
• Dual: two humans — two human reviewers blind-screen each study with no AI participation. Recommended for Cochrane-style reviews or HTA assessments where methodological guidance requires two independent human judgements.

Switching between modes is always reversible. Existing dual-review analyses default to AI + me so nothing changes unless you explicitly opt into the two-humans variant.

app.axelium.io · Configure

Teams and collaboration

An analysis in Axelium lives inside a workspace. A workspace is either your personal library (you are the only reviewer) or a team (multiple reviewers with distinct roles). You choose when you create a new project, and you can move a personal project into a team at any time — but a team project is not moved back out, since the decisions and comments the team has accumulated belong to the team.

Four roles govern who can do what inside a team:

• Admin — full control, including inviting members, changing roles, deleting analyses, and approving protocol sign-offs. Every team has at least one admin; the member who creates the team is the first admin.
• Lead reviewer — can edit the protocol, assign workload, adjudicate conflicts, and invite collaborators, but cannot delete analyses or remove members. The practical day-to-day owner of a review.
• Reviewer — submits screening decisions and extraction reviews. Cannot change protocol or team membership.
• Viewer — read-only access to everything in the team. Useful for stakeholders, methodologists, or auditors who need to follow progress without influencing decisions.

Admins can change any teammate's role from the team detail page (reviewers can be promoted to lead reviewer, lead reviewers to admin, and so on). You cannot change your own role, which prevents the last admin from accidentally locking themselves out.

app.axelium.io · Team

Inviting members

Invitations are sent by email address at either reviewer or lead reviewer level (admin and viewer roles are conferred after joining, not at invite time). Each invitation produces a unique accept link that expires after seven days and can only be used once. Case does not matter for the invitee email, and you can invite someone who does not yet have an Axelium account — they will create one through the accept link.

app.axelium.io · Team

Splitting screening work with assignments

In a team analysis, you can choose to split screening work across reviewers instead of having everyone see everything. Turn on workload assignments in the configuration and use the Assignments page to allocate studies per phase (abstract / full text) and per slot (reviewer A / reviewer B). The “Split evenly” button round-robins unassigned studies across the team deterministically, so a refresh always produces the same preview before you commit. Each reviewer's screening queue then shows only their own assigned studies with a banner indicating how many of the total are theirs.

Workload assignments are opt-in per analysis. When they are off, every reviewer sees the full study list — which is still the right choice for small reviews or when two reviewers deliberately want full overlap for calibration.

app.axelium.io · Assignments

Protocol sign-off and milestone locking

Team analyses can advance through five optional milestones that freeze parts of the review as it progresses: protocol locked, screening complete, extraction complete, analysis frozen, and manuscript locked. A lead reviewer requests a sign-off at a given milestone; an admin approves or rejects. Approval advances the lock and snapshots the protocol into an immutable version, so the state of the review at that milestone is reproducible later. Once locked, the corresponding edits are refused until the milestone is unlocked — you cannot accidentally edit a frozen protocol or re-screen a closed phase.

Notifications and @mentions

Team coordination is push, not poll. Comments and @mentions on a study, extraction field, or analysis run, plus assignment hand-offs and sign-off requests, all flow into a unified inbox accessible from the bell icon in the dashboard sidebar. Each row deep-links back to the comment thread or page that triggered it, so context never gets lost and reviewers can act in one click.

app.axelium.io · Notifications

Companion documents and study bundles

A single trial often produces multiple publications — a primary results paper, secondary analyses, long‑term follow‑ups, and supplementary materials. Axelium treats these as a study bundle so the extraction pipeline can see the full trial narrative.

• Companion discovery — the system automatically discovers sibling publications from study links and includes their parsed text in the extraction context.
• Supplements — PDF appendices, Excel tables, and Word documents are fetched from PubMed Central, publisher sites, and ClinicalTrials.gov. Non‑PDF formats are automatically parsed and processed.
• Primary document selection — when a trial has multiple candidate documents, the pipeline selects the best primary source (typically the main results publication) while keeping companions available as supplementary context.

Full-text recovery and manual upload

Once a study has been matched to a record, Axelium still has to retrieve the actual full-text PDF or XML before the extraction pipeline can run. Many publishers gate this fetch behind bot-detection middleware, so the recovery layer is split into a detection step, an open-access backfill, and a manual escape hatch for documents that remain unreachable.

• Captcha and bot-gate detection — on auto-fetch, the system inspects the response for Cloudflare, reCAPTCHA, hCaptcha, and Incapsula gates and stamps the document fetch_blocked rather than retrying blindly. Blocked documents skip downstream parsing and surface in the missing-fulltext queue with the gate type recorded for diagnostics.
• OA recovery (Layer-2 backfill) — blocked or missing documents are retried via the open-access mirror network: the PMC OA service, NCBI E-utilities efetch.fcgi, and EuropePMC ptpmcrender.fcgi. The recovery layer is paced (per-doc and inter-candidate delays) to dodge PMC's own bot-gate, and recovered documents supersede the original via an audit trail (superseded_by_oa_recovery) so lineage back to the originally fetched record is preserved.
• JATS markdown tables — when PMC returns JATS XML, tables are rendered as GFM markdown blocks before being fed to the extraction agent, so numeric values inside tables are preserved instead of being flattened during XML-to-text conversion.
• Manual upload escape hatch — documents that remain blocked after OA recovery are listed on the Bulk Upload page (/analysis/[id]/fulltext/missing) with publisher, PubMed, and EuropePMC deep-links. Users drag-drop a folder of PDFs and a fuzzy filename-to-study matcher pairs each upload with the right record. The same escape hatch is offered inline on every blocked document via the BlockedFulltextNotice component, so reviewers can resolve a single hold-out without leaving the screening or extraction view.

app.axelium.io · Full text

app.axelium.io · Full text

Together these layers convert the unavoidable reality of publisher paywalls and bot-gates into a small, finite manual queue rather than silently missing studies during extraction.

Extraction schemas

Schemas are structured templates that define exactly which fields are needed for each endpoint type — such as events and totals for dichotomous outcomes, or means and standard deviations for continuous outcomes.

These schemas drive both extraction and validation, keeping data capture consistent across studies and endpoints. The extraction UI computes a five‑level status for each outcome (empty, partial, AI‑extracted, complete, suspicious) based on how many schema fields are filled and whether the derived effect passes plausibility checks.

Extraction pipeline

Axelium uses a multi‑stage extraction workflow to orchestrate batch extraction across all eligible studies. Rather than extracting one study at a time, the pipeline processes studies in parallel through a series of steps:

• Document acquisition — ensures each study has its main PDF, supplements, and companion papers.
• Document mapping — identifies which sections, tables, and pages in the document bundle are relevant to each endpoint.
• Multi‑agent extraction — specialist agents independently scan narrative text and tables, then their findings are merged into structured data.
• Quality scoring — each extraction on evidence adequacy, arm alignment, schema completeness, and provenance quality. Low‑scoring results are routed to the human review queue.
• Conflict adjudication — when sources disagree, the system resolves straightforward conflicts automatically and escalates ambiguous cases for human review.

Data lineage and provenance

Every extracted value is tied to a location in the source PDF or text field. A unified provenance layer tracks per‑field origin — whether a value came from AI extraction, manual editing, or a saved database record — and detects conflicts when a new AI proposal differs from the current value.

From the statistics results, the Trace Lineage panel opens that trail for any pooled estimate: it lists the contributing studies, shows the effect size and variance for each one, and links every number back to the extracted value — and from there to the originating snippet in the source document.

Trace Lineage is available for every completed analysis run. If a run did not persist its per-study dataset, Axelium re-derives it deterministically from the saved model — the same studies and the same effect-size maths used to fit it — so the provenance trail is never missing.

app.axelium.io · Analysis

Living reviews

A living review is a continuously updated evidence synthesis rather than a one-time snapshot. Once you finish a review, Axelium can keep it current for you: on a schedule it re-runs the whole pipeline — search, screen, retrieve, extract, risk-of-bias, re-pool — surfaces any newly-found studies in an Inbox, re-pools the meta-analysis against the now-fuller evidence base, and emails you when the pooled result changes enough to warrant a re-look. The PRISMA flow diagram and the project overview update automatically as studies move through the pipeline.

This section is a how-to for setting one up and living with it. The statistical detail behind the change-detection step is covered under Statistical analysis · living-review pooling.

Enabling a living review

Living-review automation is configured in the Living-Review Automation dialog, opened from the Configure sidebar. Two things must be true before automation will run:

• The search must be locked. Scheduled runs need deterministic, locked queries — an in-flux PICO or a draft query would have every cycle searching for something different. While the search is still in Draft mode the dialog shows a warning and the enable toggle stays disabled; lock the queries from the Configure sidebar first.
• The protocol must be locked. The scheduler only picks up analyses whose protocol has been locked at a milestone, so an unattended cycle never spends tokens against criteria you are still editing.

With those in place, turn on Enable Automation and pick a cadence — daily, weekly, or monthly. You can also cap Max Studies / Run, set the minimum AI confidence below which a newly-found study is parked as “unsure”, and toggle auto-extraction and auto risk-of-bias for the cycle. Enabling automation for the first time stamps the run clock to now, so the next cycle honours your chosen cadence rather than firing immediately. Save & Run Now kicks off a cycle straight away if you do not want to wait for the scheduler.

app.axelium.io · Configure

The update cycle

Each scheduled cycle runs the same pipeline you ran by hand, end to end and unattended:

A cost and permission check runs at every stage, so a quota-exhausted or past-due account is stopped before it spends search or screening tokens. If a cycle fails — a cost cap, a blocked quota, an upstream outage — the analysis owner is notified rather than left guessing, and a stuck cycle is automatically reaped after two hours so a single crash never permanently blocks future runs.

The Inbox of newly-found studies

Every study a cycle discovers surfaces in the Review Inbox, opened from the analysis overview. The Inbox is a work-queue: each row shows the study, the AI screener's verdict, and — when auto-extraction is on — a preview of the draft extracted data. From here you:

• Accept a study to confirm it for inclusion, or Reject it to exclude it.
• Import Data to promote a draft extraction to validated data when every selected study has one.
• Mark visible as read to clear the new-study badge without committing to an accept or reject decision — useful for skimming a large batch.

By default the Inbox shows only studies the AI auto-included; flip Include excluded to also review the ones it auto-excluded. Inbox actions are gated by screening permissions, so viewers cannot mutate screening status from the drawer.

app.axelium.io · Overview

Watching a cycle: the Pipeline Monitor

While a cycle is in flight, a Pipeline Monitor banner on the analysis overview shows live per-stage progress — search, screen, retrieve, extract — with running counts (studies found, screened, PDFs retrieved, outcomes extracted). The banner stops polling once the run resolves, then stays visible for about a day afterwards so you can see how the last cycle did. If a cycle fails it turns red and names the reason; an in-flight run can be cancelled from the banner.

Detecting when the evidence has changed

After the pipeline finishes, the cycle re-runs the pooled meta-analysis on the now-fuller set of validated outcomes, snapshots the pooled estimates, and diffs them against the previous snapshot. When the diff trips your configured alert thresholds, an “Evidence change detected” card appears on the analysis overview with a before/after table, and a significant-change notification is sent. The working alert rules are:

• Effect-size change — the pooled estimate moved by at least a configured percentage. For ratio measures (RR, OR, HR) this delta is measured on the log scale, so an equivalent doubling and halving count as the same-size move.
• CI-crossing-the-null flip — the confidence interval brackets the null value in one cycle but not the other, i.e. the effect just became (or stopped being) statistically distinguishable from no effect.
• I² jump — the between-study heterogeneity I² rose by at least a configured number of percentage points.

Two refinements make the detection both sensitive and noise-resistant:

• Anchored slow-drift detection. A change that arrives in small weekly increments — each one under the threshold — could otherwise accumulate into a large shift and never alert, because each cycle was only ever compared with the one before it. The magnitude rules (effect-size delta, I² jump, new-trial count) instead compare against the last cycle that alerted on that outcome — a fixed anchor — so a gradual drift accumulates against it and trips once the cumulative move crosses the threshold. The alert email names the anchor date (“since the last alert on …”).
• Triggers that do not need a new trial. A magnitude alert normally also requires that the evidence base changed — at least one trial added since the prior cycle. But evidence can move without a new trial: a study is retracted, excluded on re-screening, or re-extracted with corrected numbers. So an outcome also flags when a trial is removed, and — independently of trial count — whenever its CI flips across the null or its effect moves by at least twice the configured threshold. These k-independent escape hatches catch a sharp move that a flat trial count would otherwise hide.

The threshold-tripping itself is fully deterministic and auditable in code; a small judge agent only writes the human-readable narrative in the alert email and cannot change the alert decision. Thresholds are tuned per analysis in the Automation dialog's Alert thresholds panel, with deliberately conservative defaults — a 10% effect delta, a 20-point I² jump, CI-flip on, and a minimum of one new trial — so first-cycle and empty-cycle runs never raise a false alert.

Locking the analysis method: recipes

A cycle re-pools your outcomes automatically, so it needs to know how each outcome should be analysed. An analysis recipe freezes that decision. From a completed server-run forest analysis you can “Lock as living-review recipe”, which captures that outcome's exact analytic method — model (fixed or random effects), effect measure, timepoint, and study exclusions — so every future cycle replays it rather than re-deriving a plan from a heuristic default. Study exclusions are hardened to stable study IDs at lock time, locking is always a deliberate human action, and re-locking supersedes the previous recipe (recipes are versioned, not mutated).

The Recipes page on the analysis sidebar (/analysis/[id]/recipes) lists every monitored outcome with its locked recipe — model, effect measure, timepoint, validated-only flag, and excluded-study count — and lets you unlock one (the outcome then falls back to its configured model on the next cycle, with recipe history preserved). For outcomes without a recipe you can set the per-outcome fallback pooling model directly on the page. Recipes whose outcome was renamed or removed are flagged in a Stale recipes panel so recipe drift stays visible. The page is read-only for viewers.

app.axelium.io · Recipes

Notifications

Living reviews talk to you through the same unified notifications system as the rest of Axelium. Three notification kinds are living-review-specific:

• Evidence change (living_review_significant_change) — ships immediately when a cycle's re-pool trips the alert thresholds.
• Cycle digest (living_review_digest) — a routine summary of what a successful cycle found, batched into your daily digest by default.
• Cycle failed (living_review_failed) — ships immediately as a separate kind, so opting out of the digest still leaves urgent failure alerts on.

All three route through your preferences at /settings/notifications, where you can send each kind to immediate email, the digest, or in-app only, and set the digest cadence to daily, weekly, or off.

app.axelium.io · Project overview