Intelligence without replacing your imaging stack.

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.

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. 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.

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.

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.