EHR and EMR integration
Open RadVector from the EHR. Keep the EHR as the record.
RadVector connects to Epic, Oracle Health and other FHIR-enabled EHRs through SMART on FHIR R4 and CDS Hooks 2.0: one vendor-neutral gateway that launches reporting in patient context and reads orders, results and documents, without a custom interface per site.
Built on the standards every major EHR implements. Read-only. Advisory cards stay silent until validated.
How a launch works
Four steps, all of them standards.
SMART App Launch opens the app, FHIR R4 supplies the context, RadVector Reporting does the reporting, and CDS Hooks carries advice back. Nothing on the EHR side is custom.
Launch
SMART App LaunchThe clinician opens RadVector from the EHR with the patient already selected. The gateway verifies that the launch came from a registered EHR, exchanges the code with PKCE as a confidential client, and takes the clinician's identity only from the EHR's signed id token, checked against the EHR's published keys.
Context
FHIR R4, read-onlyThe patient, the imaging order, prior radiology reports and the technologist's documents are read with read-only scopes. Nothing is created or updated in the record, and the gateway keeps no database and no copy.
Reporting
RadVector ReportingThe order text, priors and worksheets arrive in the same report workflow a radiologist uses by hand, as a sealed, single-use launch that expires in five minutes. The radiologist dictates, reviews and signs exactly as before; the EHR remains the record.
Advice
CDS Hooks 2.0On patient-view the EHR can ask RadVector for imaging follow-up advice. De-identified findings go to the RadVector criteria engine; the answer is a card with the standard, version and trace id. Cards are kept silent until validated for that site, and no result is written back.
EHR vendors
Epic, Oracle Health and any SMART-enabled EHR.
The code is written against the standards, not against a vendor. Each vendor is a data profile: scopes, how the app proves its identity, which hooks are offered.
Epic
Integration-ready: Built and available for integration projects.SMART App Launch with asymmetric client authentication (private_key_jwt against RadVector's published key sets), FHIR R4 reads, CDS Hooks on patient-view.
RadVector Clinical Intelligence is registered as a SMART on FHIR app in Epic's developer program for non-production use. A hospital connection is enabled as its own tenant after sandbox validation.
Oracle Health (formerly Cerner)
Integration-ready: Built and available for integration projects.The same gateway with an Oracle Health profile: SMART App Launch with a registered client secret, read-only FHIR R4 scopes, the same CDS Hooks service.
Built and configurable per connection. Exercised in the Oracle Health sandbox before any pilot.
Other SMART-enabled EHRs
Integration-ready: Built and available for integration projects.Any EHR that implements SMART App Launch on FHIR R4 (MEDITECH, athenahealth, NextGen, Veradigm and others) is onboarded as a tenant with a vendor profile, not with new code.
Vendor-specific behavior is verified in that vendor's sandbox before go-live.
RIS and interface engines
Integration-ready: Built and available for integration projects.Where the order comes from a RIS rather than the EHR: HL7 v2 orders through an interface engine, RIS worklists over REST or FHIR R4, and a browser connector that links a RIS worklist to RadVector Reporting.
Available today alongside the EHR launch; the two paths can run side by side.
Epic is a trademark of Epic Systems Corporation. Oracle and Cerner are trademarks of Oracle Corporation. Other names are trademarks of their owners. iTech Clinical Intelligence is not affiliated with, endorsed by or certified by any EHR vendor; the integration uses the open SMART on FHIR, FHIR R4 and CDS Hooks standards those vendors implement.
Integration paths
What connects today, and what is direction.
- Integration-ready: Built and available for integration projects.
EHR launch
SMART App Launch from the EHR activity or menu, as a confidential client with PKCE; one gateway, a profile per vendor.
- Integration-ready: Built and available for integration projects.
Patient context over FHIR R4
Patient, ServiceRequest, DiagnosticReport, DocumentReference and Binary, read with read-only scopes into the report workflow.
- Integration-ready: Built and available for integration projects.
Sign-in from the launch
A clinician who has linked their EHR identity once lands in RadVector Reporting without a password, under the account's own second-factor rule.
- Integration-ready: Built and available for integration projects.
CDS Hooks 2.0 advice
Imaging follow-up advice on patient-view from de-identified findings, with standard, version and trace id on each card. Silent until validated.
- Integration-ready: Built and available for integration projects.
HL7 v2 orders
An HMAC-signed listener for ORM orders through the interface engine, for sites whose orders originate in the RIS.
- Direction: Architectural direction. Not a current product capability.
Results back to the EHR
Writing a result or report into the EHR over FHIR. A direction, not a current capability; never enabled without separate authorization.
The PHI boundary
What the EHR connection does with patient data.
The connection is designed so that a security review can answer each question from the architecture, not from a promise.
- No database in the gateway
- The EHR gateway holds no patient data at rest. A launch is a sealed, single-use token that expires in five minutes; what it carries is read again from the EHR, never stored by the gateway.
- Identity from the EHR, not from a form
- The clinician is whoever the EHR's signed id token says, verified against the EHR's published keys. Linking to a RadVector account happens once, by that clinician signing in.
- De-identified before the engine
- CDS Hooks advice is computed by the RadVector criteria engine from findings with identifiers removed; the engine never sees a name or record number.
- One tenant per connection
- Each EHR connection is its own tenant with its own keys, allowed hosts and kill switch. No tenant can reach another, and none is mapped onto a RadVector Reporting group.
- Read-only scopes
- Only read and search scopes are requested. No create, update or write scope exists in any profile.
- Audit without identifiers
- Every launch and hook is logged by tenant, stage and outcome, with the patient reference hashed; nothing in the audit identifies a patient.
EHR and EMR integration questions
Does RadVector integrate with Epic?
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.
Does RadVector work with Oracle Health (Cerner) and other EHRs?
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.
What is SMART on FHIR, and how does RadVector use it?
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.
Does RadVector write reports or results back into the EHR?
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.
What does an EHR integration project with RadVector involve?
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.
Connect your EHR.
Tell us which EHR you run and whether the order originates in the EHR or the RIS. A project starts in the vendor sandbox with synthetic patients.