Integration
FHIR-native. Integration-ready for Epic and Oracle Health.
Echo Pathways is designed to work with the patient-record systems you already have, rather than replace them — preserving provenance and operating inside current workflows. FHIR context is read-only. We do not write back to your record system.
One seam
A new EHR is an adapter — not a rebuild.
Every data source enters through a single integration seam. Connecting a new FHIR system means a new adapter endpoint plus that vendor's auth and profile mapping. Everything downstream — normalisation, protocol execution, provenance, the worklist — is unchanged. That is what makes a second hospital cheaper than the first.
Read-only by design
We consume context; we don't mutate the record. Write-back is a separate, later, explicitly-scoped decision — not something we'll quietly enable.
Your tenancy
Deployed into the customer's own cloud tenancy, in-region. Data residency is a term of the agreement, not a configuration flag we hold.
Provenance preserved
Every value carries where it came from: source system, version, retrieval time, mapping version, and a hash of exactly what we read.
Source systems
We show you what is connected — and what is not verified.
Integrations fail quietly, and a surveillance system that silently stops receiving results is worse than no surveillance at all. So the connection state is a first-class screen: what is connected, when it last succeeded, and what has not been conformance-verified.
What we take, and what we keep
Your record system stays the record of truth.
Where a result already lives in Epic or Oracle Health, we do not become a second custodian of it. We evaluate it, then keep a hash, the source reference, and the rule's inputs — enough to replay the decision and prove what we saw, without warehousing your patients' results. Two narrow exceptions apply, and we set them out plainly.
Ready to scope an integration?
Tell us which record system you run and which pathway you want watched.