Straight answers.

iTech Clinical Intelligence is a physician-founded, radiologist-led company that builds the intelligence layer for medical imaging: deterministic radiology criteria engines with provenance, clinician-controlled reporting, and an API that software and AI agents can call. Its products are RadVector Reporting, RadVector API and QLumis. The legal entity is iTECH LLC.

It means clinical reasoning that sits between imaging systems and the people and software that act on images: normalizing findings, applying versioned criteria such as Fleischner or BI-RADS, checking reports, and attaching provenance to every answer. The layer is delivered today through RadVector Reporting and RadVector API. It is designed to work alongside existing PACS, RIS, EHR and AI systems rather than replace them.

iTech Clinical Intelligence was founded by a practicing, board-certified radiologist with graduate training in computer science, data science and artificial intelligence. The company began with problems encountered in daily radiology work and grew into a broader architecture for reporting, clinical inference, model orchestration and human-AI interaction: a physician's view of what the tools must do, built by someone trained to build them.

RadVector API is a clinical inference API for radiology from iTech Clinical Intelligence. You send a de-identified finding and its study; it returns the category a validated criteria pack reached, the pack and version that reached it, the exact text the engine read, a trace id, and optional references. Its deterministic routes never call a language model. Documentation is public at https://api.radvector.ai/v1/docs.

A language model recalls a guideline; RadVector applies one. RadVector API evaluates structured findings against a versioned criteria pack and returns the same answer for the same input, with the pack version, validation status and trace id attached. When the criteria do not apply, for example because a nodule has no stated composition or the patient is below the pack's minimum age, it returns a deferral that says why instead of guessing.

Three criteria packs are validated and may drive output today: Fleischner 2017 for incidental pulmonary nodules, ACR BI-RADS 5th edition, and DEXA bone-density classification (WHO 1994 with ISCD 2019). Draft packs for Lung-RADS v2022, TI-RADS, PI-RADS v2.1, O-RADS US, LI-RADS, Bosniak 2019, C-RADS and NI-RADS answer as advisory and are marked not usable for output while they are validated. Each standard has a plain-language guide at itecclinical.com/standards.

Yes. Agents calling RadVector API as a tool is a first-class use. The API takes structured input, returns structured verdicts with provenance, and says explicitly when it defers, which lets a general-purpose model hand radiology criteria to a maintained, versioned engine instead of reciting them from memory. The one language-model route, /v1/impression, drafts an impression constrained to the verdicts and mechanically checks that the prose stayed inside them.

Yes. Every POST /v1/inference/evaluate answer is available as a FHIR R4 Bundle (send Accept: application/fhir+json or add ?format=fhir): one preliminary DiagnosticReport, one Observation per finding and one per verdict, with the criteria pack, version and validation status on each verdict. A deferral is an Observation with dataAbsentReason, so an undecided finding stays visible. Findings carry verified RadElement codes where a verified code exists.

Yes. POST /v1/results/normalize accepts another AI system's output as FHIR R4 Observations or as a DICOM SR TID 1500 measurement report in the DICOM JSON model. Each finding keeps its source algorithm and version, is graded by the same engine against Lung-RADS, BI-RADS, TI-RADS, Fleischner and the other packs, and every verdict names both the AI source and the criteria pack. Patient fields are never read. RadVector grades findings another system reported; it detects nothing itself.

With a sandbox key and synthetic fixtures. A sandbox key returns the same engine answers as a live key, is never billed, and marks every answer X-RadVector-Sandbox: true; a published file of synthetic request bodies covers each route. Integrations can also pin criteria-pack versions (a stale pin answers 409 instead of silently changing recommendations), branch on closed-set deferral codes, send up to 25 evaluations in one batch, and retry safely with an Idempotency-Key. The developer guide is at https://radvector.ai/portal/developers.

POST /v1/context/prepare assembles what a radiologist needs before reading: from the current order and prior report texts it returns the comparable priors ranked same-type first with their intervals, prior measurements bound to their lesions, the reporting standards that apply with their required elements, recommendations from earlier reports that are still open, and missing-information warnings. It calls no language model.

Read the public reference at https://api.radvector.ai/v1/docs without an account, then create an account at https://radvector.ai/portal to mint a key. Every account includes a free monthly allowance of decisions with no card required. Pricing is metered per clinical decision; a call that reaches no decision is not billed.

Yes. RadVector Reporting writes a governance record for each report: every standard applied, the category reached, whether it was authoritative, advisory or deferred, and the criteria-pack version, validation status, validator and date behind it, plus the knowledge release used. The record holds no report text. Group administrators see it in the Governance section of Analytics and can export it as CSV, beside a workflow value panel built only from measured data.

RadVector Reporting is a radiologist-facing reporting and decision-support platform at https://radcloud.net. The radiologist dictates, types or pastes findings; RadVector builds the report through FINDINGS from the radiologist's own words, then drafts the impression, recommendations and references, runs deterministic and AI quality checks, and cites the guidance applied. The radiologist reviews, edits and signs every report. RadVector Reporting was formerly called RadCloudAI.

MIPS-aware radiology reporting is about what the report says; MIPS submission is about sending measure data to CMS. RadVector Reporting supports clinical documentation relevant to selected MIPS radiology quality measures, for example Fleischner follow-up for incidental pulmonary nodules, ACR guidance for incidental thyroid nodules on CT, MRI and PET, per-artery coronary calcium scores and incidental coronary calcification on chest CT, and runs QA that flags missing documentation before the radiologist signs. RadVector does not submit quality measures to CMS, is not a CMS-qualified registry or certified submission vendor, and does not guarantee measure performance, MIPS scores or reimbursement. Measure selection and submission remain with the practice and its registry or reporting vendor.

No. The design principle is to keep the viewer, archive and workflow an organization already runs and add intelligence across them. Today RadVector reads RIS worklists over REST or FHIR R4, accepts HL7 v2 orders through an interface engine, links RIS worklists through a browser connector, and answers other systems through RadVector API, which returns every evaluation as FHIR R4 and accepts other AI systems' results as FHIR R4 or DICOM SR. Reports leave RadVector Reporting when the radiologist copies them into the reporting or RIS system. PACS and DICOMweb connectivity is in development and not yet available.

Yes, through the open standards Epic implements rather than a custom interface. RadVector Reporting from iTech Clinical Intelligence opens from Epic as a SMART on FHIR app (SMART App Launch, FHIR R4): the clinician launches it in patient context, and the order, prior radiology reports and technologist documents are read over FHIR R4 into the same report workflow a radiologist uses by hand. A CDS Hooks 2.0 service can return imaging follow-up advice on patient-view and is kept silent until it is validated. RadVector Clinical Intelligence is registered as a SMART on FHIR app in Epic's developer program for non-production use; each hospital connection is then enabled as its own tenant after sandbox validation. iTech is not affiliated with or endorsed by Epic, and nothing is written back into the EHR.

Yes, by design. The same EHR gateway serves any EHR that implements SMART App Launch on FHIR R4, with a data profile per vendor rather than vendor-specific code: Epic, Oracle Health (formerly Cerner Millennium), and other SMART-enabled EHRs. Vendors differ in how a confidential app proves its identity, so the gateway supports both asymmetric keys (private_key_jwt, the Epic method) and a registered client secret (the Oracle Health method), chosen per connection. Oracle Health and other non-Epic connections are exercised in the vendor sandbox before any pilot. iTech is not affiliated with or endorsed by Epic or Oracle.

SMART on FHIR is the HL7 standard for launching a third-party app from inside an electronic health record with the patient and user already selected, and for reading that patient's record over the FHIR R4 API with the clinician's own permissions. RadVector uses it as a confidential client with PKCE: the EHR launches RadVector Reporting, the gateway verifies the EHR and the clinician's identity from the EHR's signed id token, reads the order, prior reports and documents with read-only scopes, and hands them to the report page as a sealed, single-use, five-minute launch. The gateway keeps no database and no copy of the record.

Not today. The EHR connection is read-only: RadVector reads the order, prior reports and documents over FHIR R4 and returns advice only as CDS Hooks cards, which stay silent until validated. The signed report leaves RadVector Reporting the way it does today, by the radiologist copying it into the reporting or RIS system. Writing results back over FHIR is an architectural direction, not a current capability, and will not be enabled without separate authorization from the deploying organization.

Four steps, none of which require new software on the EHR side: the hospital or vendor registers RadVector as a SMART on FHIR app in its EHR (Epic: the developer program app with the redirect https://ehr.radvector.ai/smart/callback and RadVector's published key sets; Oracle Health: a confidential client in the code console), iTech adds the connection as a tenant with its own kill switch, the launch and the CDS Hooks service are validated in the vendor sandbox with synthetic patients, and a pilot follows with the advisory cards still silent. Each tenant is separate from every other and from the RadVector API.

No. RadVector Reporting and RadVector API are clinical decision support for qualified professionals. They have not received FDA clearance or approval as a medical device, are not a diagnostic device, and must not be used for autonomous diagnosis, triage or unsupervised reporting. The radiologist remains the final clinical authority.

RadVector API is built to need as little protected health information as possible. The contract has no field for a name, MRN, accession number or date of birth; age and sex are accepted because they change the clinical answer. Free text is passed through an identifier mask before the engine reads it, the call is refused if masking is unavailable, request text is never logged or stored, and customer data is never used for training. Self-serve keys are for de-identified input. For clinical deployments, including AI and clinical platforms that call RadVector on behalf of hospitals, iTech signs a Business Associate Agreement before PHI-bearing calls begin.

Not currently. iTech Clinical Intelligence does not hold SOC 2, HITRUST or ISO 27001 certification and has not completed an independent penetration test. Instead it publishes specifics: a PHI-free API contract, encryption at rest, passkeys and TOTP, tenant isolation, an append-only PHI-free audit log, a first-party security review of RadVector API written for hospital security teams, and a Business Associate Agreement for RadVector Reporting plans that permit PHI and for clinical RadVector API deployments.

QLumis is a private, multimodal AI companion from iTech Clinical Intelligence with persistent encrypted memory, real-time voice, and consent-gated voice and likeness. It explores how AI systems remember, recognize and stay continuous over time. QLumis is not a medical device and is not part of the RadVector clinical products.