The RadVector API, answered plainly.

The RadVector API is a vendor-neutral clinical inference service for radiology, from iTech Clinical Intelligence (iTECH LLC). You send a de-identified finding and the study it was seen on — for example a 7 mm solid pulmonary nodule on a non-screening chest CT in a 62-year-old — and it returns the category a validated criteria pack reached, the recommendation that follows from it, the pack and version that reached it, the exact text the engine read, and a trace id. It is a REST API over HTTPS with JSON bodies, authenticated by a bearer key.

A language model recalls a guideline; RadVector applies one. Every decision here is reached by a deterministic criteria pack a physician validated, not generated token by token, so the same input always returns the same category, and the answer names the pack and the rule version that produced it. A pack still in draft answers as advisory and is marked not usable for primary output, and a case the pack does not cover comes back as an explicit deferral with a reason rather than a plausible guess. That is the part a model cannot give you: an answer you can audit and defend afterwards.

Yes — that is a first-class use, not a workaround. Point an agent built on Claude, GPT or Gemini at the API and it can stop guessing at follow-up intervals: it sends the structured finding, gets back a validated category with provenance, and quotes that. Every endpoint is documented in OpenAPI at /v1/docs, which is what most tool-calling frameworks read to generate a tool definition. See Integrations.

Validated packs currently include Fleischner Society follow-up for incidental pulmonary nodules, BI-RADS for breast imaging, DEXA bone-density criteria, ACR TI-RADS, LI-RADS, O-RADS US and PI-RADS v2.1. Draft packs for Lung-RADS v2022 and Bosniak 2019 are evaluated by the same engine and answer as advisory, marked not usable for primary output, until they are validated. Each pack carries its own version, its validator and its validation date, and the API reports all three on every verdict it produces. Plain-language guides to each standard are at itecclinical.com/standards. /v1/guidelines lists what is live on the instance you are calling, so you never have to infer coverage from documentation.

Yes, and it keeps the two kinds of source separate on purpose. Published guidance and emerging peer-reviewed evidence are returned as two distinct citation streams, so a paper published last month can inform a clinician's decision without ever being mistaken for the standard of care. A new study is surfaced as new evidence; it never silently changes what a validated pack returns.

It is metered per clinical decision: you pay for decisions the engine actually reaches, with no seat license and no minimum commitment. Drafting an IMPRESSION around those decisions is metered separately. The live per-unit rates are read directly from our billing provider and shown on Pricing, so the page and your invoice cannot disagree.

It is built not to need it. The request shape has no field for a patient identifier at all: age and sex are carried because they change the clinical answer, and any free text you send is bounded and passed through an identifier mask before the engine reads it — refused outright if that mask is unavailable — and is never logged or stored. Self-serve keys are for de-identified input. If your deployment will carry protected health information, for example a clinical system or an AI platform calling RadVector on behalf of a hospital, talk to us: we sign a Business Associate Agreement before it goes live, and the one model-backed route only uses providers we hold a BAA with.

No. Requests are not used as training data. The deterministic endpoints do not involve a language model at all, and the one endpoint that drafts prose runs on a RadVector-held platform credential, constrained to the verdicts the engine already reached and checked mechanically before it is returned.

No. RadVector is clinical decision support. It must not be used as a standalone diagnostic device, a triage engine or an unsupervised reporting workflow, and it does not replace clinical judgment. A qualified clinician remains responsible for the decision.

Yes, deliberately. RadVector Reporting — the radiology reporting platform at radcloud.net — calls the same core in process, and a contract test pins the in-process verdict and the /v1 verdict identical. So the API is not a cut-down export of the product: it is the product's decision layer, sold directly.

Yes. Ask for application/fhir+json, or add ?format=fhir, on an evaluate call and the same decision comes back as a FHIR R4 Bundle: one preliminary DiagnosticReport, an Observation per finding and per verdict, the criteria pack and version on each verdict, and a deferral rendered as an Observation with a data-absent reason rather than dropped. The default JSON answer is unchanged. The developers page has the details.

Yes. /v1/results/normalize accepts another system's findings as FHIR R4 Observations or a DICOM SR TID 1500 measurement report, turns each measurement group into a finding that keeps its source algorithm and version, and grades it with the same validated criteria packs as every other call. The answer names both the AI source and the RadVector pack on every verdict, so a reviewing radiologist sees who found it and which standard graded it. It reads no patient fields and detects nothing itself.

Yes. An account with no card gets a small free monthly allowance on the two metered routes and unlimited use of the deterministic ones under the rate limit. Where sandbox keys are switched on, a sandbox key returns the same engine answers, is never billed and never counts against the allowance. A published fixtures file of invented request bodies covers every route with the answer to expect, so nothing you send during testing needs to come from a patient.

Create an account on the portal, subscribe by card, and mint a key from the dashboard — no sales call and no contract negotiation. The dashboard shows a ready-to-run request for your own key, and the full reference is at /v1/docs.