Oracle Health EHR Integration for a Multi-EHR Medical SaaS Platform

The platform was widening its EHR support, and a share of the incoming healthcare organizations ran Oracle Health. Adding a vendor is where this kind of product quietly becomes two: a second architecture, a second set of assumptions, a second thing to maintain — each one a copy of work already done, and diverging from the original the moment either changes.

Underneath that, the per-connection work was manual. For every new organization the engineering team checked by hand which resources were actually available, how search behaved on each one, what access rights had been granted, and which API quirks applied this time. None of it is visible to a customer, and all of it sits between signing an organization and its data being usable — so the waiting lands on the people who need the data, not on the team doing the checking.

The requirement was to add Oracle Health as another supported EHR without building a wholly separate architecture for it, and without that per-connection investigation starting over every time.

Application and Access Type

We fixed the application type and access type before registering, because those choices cannot be changed afterwards, and granted resource access per resource, where each read or write checkbox becomes exactly one scope — which is why a valid token reached Patient and Observation while a request to Condition returned 403, that right never having been granted.

Session Design

We designed the session around an access token valid for roughly 9.5 minutes rather than a long-lived one, reading the expiry from the token response and refreshing or re-launching on that basis instead of hardcoding a lifetime. We also matched Oracle Health’s request-format requirements exactly, since an incorrect Accept header is enough to produce a 406 on an otherwise valid request.

Management Scenarios

We designed and verified the key scenarios for managing EHR connections — connected systems and their state, resource access rights, authentication, audit trail and synchronization status — and built them into a working demo platform showing Oracle Health and Epic side by side under one administrative view.

No real patient data in any vendor sandbox, at any point

A shared sandbox tenant carries no consent and no business associate agreement.

Sandbox and production credentials held separately

Sandbox and production configuration held separately — separate service addresses, separate credentials, no shared configuration file, no production callback on a sandbox application.

Logs carry identifiers and shapes, never content

Resource type, resource ID, status code, duration. No response bodies, patient names, clinical values, tokens or authorization codes.

Patient identity handled correctly at the data layer

A FHIR resource ID is valid only for the server that issued it and is never a permanent key for a person; business identifiers such as an MRN are matched on assigning system and value together, because two organizations can issue the same MRN to different people.

BAA scope is established before the architecture is fixed,

since whether one applies depends on the role each party plays and how data moves. This is typically confirmed with the healthcare organization’s legal and compliance team before any design decision depends on the answer.

Security review on the organization’s terms and timetable

A sandbox result is not a HIPAA assessment, a penetration test or a clinical safety case.

6–10 weeks from kickoff with a committed healthcare organization to production connection (scenario)

Sandbox verification, access alignment, security review and production preparation. The variable is how fast approvals move on the organization’s side, which is why those conversations start in week one rather than at handover.

Four failure modes caught in testing, not in production (verified)

A rejected date filter, a filter silently ignored behind a 200, an ignored _count returning far more than requested, and a 406 from a wrong Accept header. All surfaced in the first days of integration testing, early enough to shape the design.

Two EHR vendors, one architecture (scenario)

Oracle Health added without a separate stack beside the existing one. Connecting a new organization becomes configuration and verification rather than a fresh technical project: standard authentication, access-rights verification, response validation, filter control, large-dataset handling, and one consistent set of error-handling rules.