RadVector API clinical inference for radiology

Integrations

Radiology expertise your platform can call.

Nobody building a general model, a PACS, or an EMR wants to also become a radiology guidelines organization — and the parts that matter most are precisely the parts that are hardest to get right from the outside. This is that layer, maintained by radiologists, versioned, and answerable over one HTTPS call.

What every integration gets

Deterministic

The decision path runs no model. Same input, same verdict — this year and in next year's audit.

Attributable

Pack, version, validator, validation date, the exact text the engine read, a trace id, and the knowledge release the citations came from.

Minimum necessary, BAA available

Identifiers have no field in the contract. Free text is bounded and masked before the engine reads it; a call is refused rather than processed if the mask is unavailable. We sign a Business Associate Agreement for clinical deployments.

Honest about uncertainty

A deferral says why it deferred. A draft pack answers advisory and is marked not usable for output. Silence is never dressed up as a decision.


Model and agent developers

A general-purpose model asked for a pulmonary nodule follow-up interval will produce a fluent, specific answer with no way for the user to tell whether it came from the current criteria, a superseded version, or the model's sense of what such an answer looks like. Users cannot audit it, and you cannot version it.

Give the model a tool instead. The response is small, strictly typed, and carries the pack and version it followed, so your product can show the citation rather than assert the number — and when the criteria change, the answer changes with them without a retrain and without a prompt edit.

  • Function/tool calling: one JSON schema in, a verdict list out, every field documented.
  • Deferrals are explicit, so your model has a defined thing to say when the criteria do not apply.
  • /v1/impression returns a drafted impression whose every measurement, category, diagnosis and interval is proven to come from a verdict — a constrained-generation target rather than another free-text surface to police.

PACS, RIS and enterprise imaging

The reading workstation is where a follow-up recommendation is worth the most, because it is the one moment the finding, the prior and the person who can act on it are all in the same place. What has kept decision support out of it is usually integration weight: another server, another data feed, another PHI boundary, another thing to validate.

  • No PHI leaves your boundary — the contract has no field for an identifier.
  • The deterministic path is a rules evaluation, not an inference queue, so it fits inside the time a radiologist will actually wait.
  • You keep your own viewer, worklist and report. The API returns a decision, not a user interface.

EMR and order entry

Two problems in the record system are really the same problem: is this the right study to order, and what happened to the incidental finding the last study described? Both need the criteria, versioned, with an applicability boundary — which is the thing an EMR has no reason to maintain in-house.

  • Appropriateness at the point of ordering, cited rather than asserted.
  • Closing the loop on incidental findings: what the criteria ask for and by when, from the report text you already store.
  • A pre-read before the next study: /v1/context/prepare ranks the comparable priors, binds prior measurements to their lesions and lists the recommendations still open.
  • Answers stable enough to store next to the order, with the version that produced them.

Imaging AI vendors

A detection model tells a clinician that something is there. It rarely tells them what to do about it, and bolting on a recommendation means taking on guideline maintenance, versioning and clinical validation — for a layer that is not your product.

  • Send your output as it is: FHIR R4 Observations or a DICOM SR TID 1500 measurement report to /v1/results/normalize, and every verdict names your algorithm beside the criteria pack.
  • You get a recommendation that cites its criteria, which is the form a reviewing radiologist and a regulator both expect.
  • When guidance moves, your recommendation moves with it — no model change on your side.

What a call looks like

curl -X POST "$API/v1/inference/evaluate" \
  -H "Authorization: Bearer rvk_…" -H "Content-Type: application/json" \
  -d '{"study":{"modality":"ct","region":"thorax","age_years":64,"sex":"M","attributes":{"risk":"high"}},
       "findings":[{"label":"nodule","region":"thorax","laterality":"right","composition":"solid",
                    "measurement":{"value_mm":7},"attributes":{"multiplicity":"single"}}],
       "include_references": true}'

Every route is documented in the API reference: structure findings from report text, evaluate, compare two studies, run report QA, fetch guidance and emerging evidence, and draft a constrained impression. FHIR R4 output, DICOM SR and FHIR result intake, the pre-read service, sandbox keys, version pinning and batch are on the developers page.

Evaluating this for a platform?

Create an account and call it today — no conversation required. For volume, dedicated deployment or a commercial agreement, get in touch and a radiologist will be on the call.