Integrations
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.
The decision path runs no model. Same input, same verdict — this year and in next year's audit.
Pack, version, validator, validation date, the exact text the engine read, a trace id, and the knowledge release the citations came from.
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.
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.
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.
/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.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.
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.
/v1/context/prepare ranks the comparable priors,
binds prior measurements to their lesions and lists the recommendations still open.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.
/v1/results/normalize, and every verdict names your algorithm beside the criteria pack.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.