Trust
Trust should come from specifics you can check, not from badges. Here is how each product handles clinical authority, data, provenance, models and security, and what we do not yet hold.
RadVector products are clinical decision support for qualified professionals. The radiologist reviews, edits and signs every report. The interpretive half of a report cannot rewrite the findings the radiologist dictated. Nothing is intended for autonomous diagnosis, triage or unsupervised reporting.
Every RadVector API verdict carries the criteria pack, pack version, validation status, who validated it and when, the engine, and a trace id that also appears on the response header and the usage record. Only validated packs can produce output marked usable.
RadVector Reporting records which model actually produced each report, with tokens and cost. Deterministic criteria decisions never depend on a language model. Data sent to RadVector API is never used for training.
Argon2 password hashing, passkeys (WebAuthn) and TOTP, encryption at rest for sensitive fields and keys, secrets in a managed secret store, strict Content Security Policy, tenant isolation between groups, and an append-only audit log that contains no PHI. RadVector API runs as a separate service with its own store, credentials and encryption key, and fails closed when unconfigured.
Data governance
PHI handling differs by product because the contracts and uses differ. We describe each one separately rather than blending them.
Plans that permit PHI require a signed Business Associate Agreement and safeguards; lower tiers do not accept PHI. An OCR-based PHI gate screens images before they leave the tenant.
Built to need as little PHI as possible: there is no field for a name, MRN, accession number or date of birth. Free text is masked before the engine reads it, or the call is refused, and request text is never logged or stored. For clinical deployments, including AI and clinical platforms that call RadVector on behalf of hospitals, we sign a Business Associate Agreement, and the one model-backed route only uses providers we hold a BAA with. Self-serve keys are for de-identified input.
A consumer product, not a medical device and not a HIPAA covered entity or business associate. Memory content is encrypted; voice and likeness beyond your own are consent-gated; no ads and no selling data.
Regulatory posture
RadVector Reporting and RadVector API are clinical decision support for qualified professionals. They are not a diagnostic device, do not replace clinical judgment, and have not received FDA clearance or approval as a medical device. QLumis is not a medical device.
We use "HIPAA-aligned" to describe RadVector Reporting's safeguards. We do not describe any product as HIPAA-certified, because no such certification exists.
Not currently held
If one of these is a requirement for your organization, tell us. We would rather say so plainly than imply it.
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.
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.
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.
RadVector API has a first-party security review written for hospital security teams. Ask for it, or send us your questionnaire.