OCI for Healthcare: EHR Hosting and PHI Controls

There is a reason healthcare CIOs talk about Oracle more than their peers in most other sectors. The electronic health record that clinicians touch every few minutes, the laboratory system that releases results, the pharmacy system that checks an order against an allergy list, and the patient accounting platform that bills for all of it very often share one thing underneath: an Oracle Database. So when a health system starts planning a move to Oracle Cloud Infrastructure, it is not moving a website. It is moving systems whose failure modes are measured in clinical risk, under a regulatory regime that treats a misplaced data extract as a reportable event.

This article is part of our series on how different industries run Oracle workloads on OCI, and it deals with the questions healthcare asks that no other industry asks in quite the same way. The cloud mechanics overlap heavily with what banks and insurers face, and we will point to those overlaps as they come up, but the combination of protected health information, life safety availability expectations, and a deeply interfaced application estate gives healthcare its own playbook. We write this as an independent OCI consultancy. We are not Oracle, we do not resell Oracle, and nothing here is Oracle's official guidance; it is what we have learned doing the work.

What healthcare estates actually run on Oracle

Start with the EHR. Since Oracle acquired Cerner in 2022, the Cerner Millennium platform has become the core of Oracle Health, and Oracle has been progressively migrating its remote hosted Millennium base onto OCI infrastructure that Oracle itself operates. If your Millennium environment is remote hosted, that migration is largely Oracle's program rather than yours, and your work is connectivity, integration testing, and assurance. If you host Millennium yourself, or run another clinical platform that supports Oracle Database underneath it, the hosting decision is yours, and OCI is the one cloud where the database tier can land on the same Exadata engineered systems it runs on today without a replatform. Either way, the EHR is rarely the first thing a health system moves. The estate around it is the larger migration surface.

That surrounding estate is bigger than most inventories admit. Around the EHR sits a ring of departmental clinical systems: laboratory information systems, pharmacy, radiology and cardiology information systems, blood bank, anatomic pathology, surgical scheduling, and dozens of specialty applications, a large share of which run on Oracle Database, frequently with WebLogic or Oracle Forms in the middle tier. Then comes the revenue cycle: patient accounting, claims scrubbing, contract management, and the reporting that feeds payers and regulators. Behind that sits enterprise finance and HR, often on PeopleSoft or E Business Suite. These departmental and administrative systems are usually the first wave of an OCI migration, because their risk profile is manageable, their hardware is aging, and their Oracle licensing makes OCI economics work in a way general purpose clouds struggle to match.

What hosting PHI on OCI requires

HIPAA and the Business Associate Agreement

HIPAA has no certification and no certified cloud. What it has is the business associate rule: a cloud provider that creates, receives, maintains, or transmits protected health information on behalf of a covered entity is a business associate and must sign a Business Associate Agreement. Oracle signs a BAA covering OCI, and the critical detail is that the BAA applies to a defined set of services. The first architecture artifact in any healthcare landing zone should therefore be the list of OCI services PHI is permitted to touch, checked against the current BAA coverage and enforced through policy, not memory. PHI sitting in a service outside that list is a compliance gap even if it is encrypted and access controlled. And the BAA makes hosting permissible, not compliant: the Security Rule safeguards, the risk analysis, the access reviews, and the breach response remain the covered entity's responsibility under the shared responsibility model.

PHI handling and encryption

OCI encrypts block volumes, boot volumes, object storage, and file storage at rest by default, and the Oracle Database services include Transparent Data Encryption as standard, which removes a whole category of findings that plague on premises clinical estates. In transit, TLS should be enforced not just at the public edge but between internal tiers, because an interface engine moving lab results across a subnet is still moving PHI. Region selection settles data residency questions early, and compartment design should separate PHI bearing workloads from everything else so that policy, logging, and key controls can be stricter where it matters. We also push teams to run discovery with Oracle Data Safe before declaring scope, because every estate we have assessed had PHI in places the data flow diagrams missed: a forgotten reporting copy, a test schema refreshed from production, an export bucket from a one time project.

Vault, keys, and identity

Default encryption uses Oracle managed keys, which is acceptable for many workloads but not where security teams want provable control over the key lifecycle. For clinical systems the usual standard is customer managed keys in OCI Vault, backed by hardware security modules, so that key rotation is scheduled, key usage is logged, and key destruction is an option the covered entity holds rather than requests. Identity follows the same logic: federate OCI with the hospital identity provider, require MFA for console access, build least privilege through compartments and groups rather than broad tenancy policies, and define a break glass procedure that is documented and audited rather than improvised at 2 a.m. This identity and key layer is where most security questionnaires and OCR audit requests concentrate, and it is the heart of our IAM and security work on OCI.

Audit logging

OCI Audit records control plane activity across the tenancy automatically, and the Logging service adds VCN flow logs and service logs on top. For PHI workloads the baseline is to forward all of it to the security team's SIEM, keep retention aligned with the organization's HIPAA documentation policy, and add database activity auditing through Data Safe so that access to clinical schemas is visible at the level regulators actually ask about: who read which records, when, and from where. Cloud Guard then watches posture continuously, flagging the public bucket or the permissive security list before it becomes an incident report.

Availability: clinical systems do not get a quiet failure

Every hospital has downtime procedures: paper charting packets, read only downtime viewers fed by replicated copies, phone trees for results. They exist because clinicians must keep treating patients when systems stop. But downtime procedures degrade care and create hours of rework per incident, so the real tolerance for EHR class outages is measured in minutes, and the recovery conversation in healthcare starts from clinical operations, not from infrastructure. The useful discipline is to tier the estate by clinical consequence and design each tier deliberately.

OCI gives you three blast radius boundaries to build those tiers with. Fault domains separate hardware within one availability domain, availability domains are isolated data centers within a region, and regions are the geographic boundary. Two cautions from real projects: first, many OCI regions have a single availability domain, in which case fault domains carry the intra region design and a second region carries disaster recovery, so check the map before you promise an architecture. Second, an unrehearsed DR plan is a document, not a capability. Full Stack Disaster Recovery can orchestrate the failover, but clinical systems deserve the same standard hospitals apply to emergency response everywhere else: drill it, time it, and fix what the drill exposes. Joint exercises, where IT fails over while clinical teams run their downtime procedures, are worth more than any architecture diagram.

Interoperability and analytics

Healthcare is the most interfaced industry in computing. A midsize hospital runs hundreds of HL7 v2 interfaces through an integration engine, moving admissions, orders, results, and charges between systems that were never designed to meet. When workloads move to OCI, the integration engine either moves with them or the interface latency budget must be reengineered, and either way the cutover plan for interfaces is usually the hardest part of go live. Private connectivity through FastConnect, with redundant circuits sized for interface traffic plus imaging spikes, is the backbone; clinical interfaces should never depend on the public internet. On top of the v2 estate, FHIR APIs now carry the regulatory weight of patient access requirements, and the API Gateway pattern on OCI, with mutual TLS and strict throttling, is the clean way to expose them without widening the attack surface.

Analytics is where OCI earns its elasticity. Population health marts, quality reporting, and research extracts with identifiers removed run well on Autonomous Database, scaling up for the monthly refresh and back down after, and GPU shapes make imaging and clinical NLP research feasible without buying hardware that idles between grants. The architectural pattern is the same one we describe for risk analytics in OCI for banking and claims modeling in OCI for insurance: keep the regulated transactional core disciplined and stable, and give the analytical edge the elasticity it wants, with governed, logged data movement between the two. The one healthcare specific addition is deidentification as a formal pipeline step with documented method and review, because a research dataset that turns out to be reidentifiable is a breach, not a footnote.

What stays on premises

A sober plan accepts that the hospital building remains a computing site. Bedside device gateways, the integration points for monitors, pumps, and ventilators, belong on the hospital network where they keep working when the WAN does not. Imaging modalities need a local PACS cache for current studies even if the deep archive moves to object storage. Laboratory instruments and their middleware sit on the bench they serve. And the downtime procedures themselves imply local capability: a read only clinical viewer that survives a WAN outage is worth designing in, not bolting on. The honest framing is that healthcare on OCI is a hybrid estate by design, with the cloud carrying the databases, application tiers, DR, and analytics, and the campus keeping what physically belongs to patient care. Anyone who promises a hospital with no machine room is selling something.

A framework for moving clinical workloads to OCI

Bringing it together

Healthcare estates reward the move to OCI precisely because they are so Oracle heavy: the databases under the clinical and revenue cycle systems land on native ground, the licensing arithmetic works, and the DR posture most hospitals could never fund on premises becomes a configuration choice. But the industry's non negotiables are real. The BAA and the permitted services list come before the first byte of PHI, keys and audit trails must be provably under the covered entity's control, availability design starts from the bedside, and a part of the estate rightly never leaves the building. Retail solves a different version of the same separation problem, keeping a stable core behind an elastic edge, and that contrast is worth reading in OCI for retail. If you are weighing a clinical migration, an independent assessment that tiers the estate, prices the target architecture, and tests the compliance posture against the design is the cheapest insurance available, and it is exactly the work we do.