Extending Epic and Oracle Health With Custom Applications: What Hospital IT Builds When the Record Can’t Hold the Work

Ask a hospital IT director what they turned down last month and you usually get a specific answer, delivered with some regret. A nurse manager in perioperative services wanted a way to track sterile processing trays with photo evidence, instead of a paper log and a spreadsheet she rebuilds every Monday morning. Biomedical engineering wanted their preventive maintenance rounds on a tablet. Infection prevention wanted audit findings captured once on the unit rather than twice, the second time by whoever retypes the clipboard into Excel that afternoon.

None of those got turned down because they were unreasonable. They got turned down because there is nowhere in Epic to put them, the vendor is not going to build any of it, and the honest answer to “can we just build it ourselves” opens a conversation about security review, HIPAA, and who maintains the thing in three years when the person who asked for it has moved on. So the request goes on a list. The list gets long, and everybody quietly agrees not to bring it up.

AI Platform

Enterprise AI

Enterprise AI that's secure enough for the systems you can't risk.

Explore Now

That list usually gets read as a staffing problem. Two more analysts and we would be caught up. But it never gets shorter, and the reason has very little to do with headcount. Epic and Oracle Health are systems of record. They were built to hold the clinical record and they hold it well. They were not built to hold the hundred operational processes that happen around care delivery, and no amount of configuration is going to change that.

Which means the useful question was never how to get those requests into the EHR. It is which work belongs inside the record, which belongs alongside it, and how to govern the second group with the same discipline as the first. That is the question CloudApper exists to answer, and it is what the rest of this is about.

What the FHIR APIs Actually Give You

Start with what is available today, because the interoperability picture in 2026 is far better than the one most IT leaders formed their opinions on.

Epic publishes an extensive FHIR surface across DSTU2, STU3, and R4, covering hundreds of resources: allergies, medications, conditions, observations, encounters, appointments, practitioners, coverage, care plans, care teams. There is a public sandbox, client registration, and documentation. Oracle Health exposes FHIR R4 across Millennium alongside its established HL7 v2 interfaces and CareAware infrastructure. On the regulatory side, ONC’s HTI-1 rule and the USCDI data classes pushed standardized API access from a competitive differentiator into a certification requirement, and the information blocking rules made restricting that access legally hazardous.

AI Platform

Enterprise AI

Build AI-powered apps without exposing your data to anyone.

See How

So getting data out of the record is a solved problem. That is the good news, and it is worth saying plainly because a lot of hospital IT strategy is still built on the assumption that the EHR is a sealed box.

The asymmetry is on the other side. Read and search operations are broadly available across the resource catalog. Create and update operations are much narrower, scoped to specific resource types in specific clinical contexts. You can pull a patient’s active medications with a scoped OAuth token. You cannot invent a new operational object inside the record, give it a status model, attach an approval chain to it, and expect the vendor’s data model to accommodate you. Production access also runs through the health system’s own activation of your client, which is appropriate governance and also a real gate on timelines.

Translated into practical terms: the EHR will tell you almost anything you need to know. It will not hold your workflow. Understanding that distinction is what separates an integration strategy that ships from one that stalls in a design committee.

The Requests That Never Make the Roadmap

Look at what is actually in that spreadsheet and a pattern emerges. Almost none of it is clinical documentation.

It is equipment rounds and preventive maintenance logs for biomedical engineering. Sterile processing tray tracking with photo evidence. Vendor credentialing at the loading dock. Patient transport requests that currently move by phone call. Environmental services turnaround verification. Departmental competency and skills attestations that live in a binder. Capital request intake. Infection prevention audit rounds where a nurse walks a unit with a paper checklist and someone retypes it into Excel that afternoon. Cross-system processes that touch the EHR, the HCM, the ERP, and the supply chain system in a single business flow.

AI Platform

Enterprise AI

AI for the enterprise — built on security, not around it.

Get Started

Every one of these is a legitimate operational need. Not one of them justifies a clinical software vendor building a module. They are too specific to your organization, too varied across sites, and too far from the clinical record to earn roadmap space. This is the same structural reality enterprise IT runs into on the workforce side, and the reasoning behind why an HCM system will never do everything an organization needs applies with equal force to the EHR. A system of record earns its position by being authoritative and standardized. Those same properties make it a poor container for work that is neither.

So the work gets done anyway, just not by IT. It gets done in Access databases maintained by one person in perioperative services. In SharePoint lists with no retention policy. In shared Excel workbooks emailed between three managers. In free-tier form builders that someone in a department signed up for with a personal credit card. And increasingly, in applications a technically capable manager generated with an AI coding assistant over a weekend, which now holds patient identifiers and runs on a server nobody inventoried.

Why the Workaround Layer Is a Compliance Problem, Not an Inconvenience

Hospital IT leaders tend to tolerate the workaround layer because each individual instance looks small. In aggregate it is one of the largest uncontrolled PHI surfaces in the organization.

Run the HIPAA Security Rule against an Access database on a departmental share. Access control under 164.312(a): the file is protected by whatever NTFS permissions someone set in 2019. Audit controls under 164.312(b): there is no log of who viewed which record when. Integrity controls: none. Transmission security: the file gets emailed. Minimum necessary: everyone in the department sees everything. If OCR asks for an accounting of disclosures from that system, there is no answer to give, and the absence of an answer is itself the finding.

AI Platform

Enterprise AI

Modernize legacy systems with enterprise-grade AI.

Learn More

The AI-generated version of the same problem is worse in one specific way. An Access database is at least legible; someone can open it and see what it does. Code generated by an assistant and deployed without review is opaque to the organization that owns it, and the questions an auditor asks about it are questions nobody on staff can answer. That dynamic is the subject of what a HIPAA audit will actually ask about AI-generated code, and healthcare is where the gap between what these tools produce and what a covered entity can defend is widest. The broader pattern of departments building applications outside centralized IT is not new, but the speed at which they can now do it has changed the math on how long an organization can look away.

The instinct at this point is usually to clamp down. Prohibit the tools, require a ticket for everything, route all requests through governance review. It fails predictably. The clinical operation has a real problem today, the formal path takes nine months, and people who are responsible for patient throughput will not wait. Prohibition does not remove the workaround layer. It removes IT’s visibility into it.

Read From the Record, Hold the Work Outside It

The architecture that resolves this does not fight the EHR’s boundaries. It respects them and puts the work somewhere governed.

The pattern has four properties. The record stays authoritative: patient identity, clinical data, and orders live in Epic or Oracle Health, and nothing downstream keeps a competing copy of clinical truth. The operational application reads what it needs through scoped FHIR calls with least-privilege OAuth grants, so a transport request app sees demographics and location and nothing else. The workflow state, approvals, attachments, signatures, and audit trail live in a platform that was built to hold them, with a single access control model and a single audit log across every application. And write-back happens only where the record supports it and where a clinician expects to see it, rather than being forced everywhere for the sake of architectural symmetry.

AI Platform

Enterprise AI

Enterprise AI that fits your compliance, not the other way around.

Explore CloudApper

This is where CloudApper functions as the process layer rather than another point tool. Applications built on the platform inherit the same identity model, the same data access policy, the same encryption posture, and the same audit logging, whether the app is tracking sterile processing trays or routing capital requests. When compliance asks who accessed a record in the equipment rounds app in March, the answer comes from the same place it comes from for every other app on the platform. The iPaaS integration layer that connects modern platforms to older systems matters as much as the FHIR connection here, because a hospital’s operational reality includes a scheduling system from 2011 and a supply chain platform that speaks flat files.

Hospital IT teams that have gone through this exercise with their HCM recognize the shape of it. The logic behind extending an enterprise platform with governed applications instead of forcing everything into the core transfers directly to the clinical stack. Different system of record, same architectural question, same answer.

The operational argument matters too. A four-person applications team at a 900-bed system cannot take on runtime patching, framework upgrades, penetration test remediation, and compliance evidence collection for fifteen custom apps, and any plan that assumes they can is a plan that ends with fifteen unmaintained apps. What removing DevOps overhead from internal app development actually buys a hospital is not developer convenience. It is the difference between a portfolio that stays current and one that becomes a risk register entry.

How to Govern a Custom Application Built Around the EHR

For teams that have decided to build alongside the record rather than wait for it, the sequence below is the one that survives a security review and a survey window.

1. Classify the data before you design anything. Determine whether the application will touch PHI, and if so which specific elements. An app that needs a patient name and location is a different review than one that needs diagnoses.
2. Request the narrowest FHIR scopes that make the workflow function. Read-only where reading is enough. Resist requesting broader OAuth scopes on the theory that you might need them later.
3. Decide where the record ends and the workflow begins. Clinical truth stays in Epic or Oracle Health. Status, approvals, attachments, and signatures live in the platform holding the work. Do not keep a second copy of clinical data.
4. Confirm audit logging before go-live, not after. Verify that every read and write is attributable to a named identity and that the log is retained per your retention policy. If you cannot produce an access report on request, you are not ready.
5. Register the application in your inventory and assign a named owner. Unowned applications become unmaintained applications, and unmaintained applications become audit findings.
6. Establish the maintenance path on day one. Document who patches the runtime, who handles framework upgrades, and who remediates penetration test findings. If the answer to all three is “the person who built it,” revisit the architecture.

Where AI Agents Belong in This Picture

Every health system is now being asked what its AI agent strategy is, and the answers tend to arrive at one of two extremes. Either agents are treated as chat interfaces bolted onto documentation, which underuses them, or they are imagined as autonomous actors with broad write access to the record, which no compliance officer will sign.

The useful position is in between and it depends entirely on the layer underneath. An agent that operates on top of a governed application inherits that application’s permissions, its audit trail, and its data boundaries. It can triage an intake queue, pull the relevant context from the record, draft a routing decision, and hand off to a human approver, with every step logged against a named identity. An agent operating without that substrate is making unlogged decisions against production clinical data, and the distinction between the two is not a matter of degree. The reasoning in why enterprise AI agents are not the same as chatbots is the governance frame worth adopting before the first agent goes into a clinical workflow, not after.

CloudApper’s position is that the agent is the easy part. The governed application layer the agent acts through is the part that determines whether the agent is deployable in a hospital at all.

What Changes When Hospital IT Stops Waiting

The organizations that solve this do not end up with a shorter request queue. They end up with a different relationship to their own operations.

At the organizational level, capability stops being gated by a vendor’s release cycle. When infection prevention needs a rounding application before the next survey window, that is a weeks-long project rather than a roadmap conversation with an uncertain outcome. Site-specific variation stops being a problem to suppress and becomes something the platform absorbs. The applications portfolio becomes an asset with a known inventory, a known compliance posture, and a known owner, instead of an archaeology project.

At the team level, the analysts who spent their careers explaining why something cannot be done get to build instead. The nurse manager who maintained the tracking spreadsheet for four years stops being a single point of failure for a process the hospital depends on. That last point is worth dwelling on, because the institutional knowledge that walks out the door when the person who built the system leaves is a specific and underpriced risk in healthcare, where so much operational process was never documented anywhere except in the habits of experienced staff.

And at the end of the chain there are patients. A transport request that routes in ninety seconds instead of four phone calls is a patient who gets to imaging on time. A credentialing check that completes before the vendor reaches the unit is a sterile field that stays sterile. A rounding process that captures findings once instead of twice is an infection prevention team with hours back in the week to act on what they found. None of that shows up in the EHR’s feature list. All of it is care delivery.

The hospitals that will look most capable over the next five years are not the ones with the largest EHR investment. They are the ones that stopped treating the boundary of their system of record as the boundary of what they could build.

Frequently Asked Questions

Can you build custom applications inside Epic?

Only within the boundaries Epic exposes. You can configure, build reports, and develop apps that integrate through the published FHIR and SMART interfaces, but you cannot create new operational data objects with their own status models and approval chains inside the record. Operational workflows of that kind belong in a governed platform alongside the EHR.

Does Epic’s FHIR API allow writing data back to the record?

In specific cases. Read and search operations are broadly available across the resource catalog, while create and update operations are limited to particular resource types in defined clinical contexts. Plan for a read-heavy integration and treat write-back as something you confirm resource by resource rather than assume.

Is it a HIPAA violation to build an internal application that stores PHI?

Building one is not a violation. Building one without access controls, audit logging, encryption, and a retention policy creates exposure under the Security Rule, and the inability to produce an access report during an investigation is itself a finding. The control environment is what determines your position, not who wrote the code.

What is the difference between extending the EHR and integrating with it?

Integrating moves data between systems. Extending adds capability the vendor did not build, using the record as the authoritative source while the new workflow lives outside it. Most hospital requests that get declined are extension requests being evaluated as integration projects.

Can AI coding assistants solve the hospital IT backlog?

They shorten the time to a working prototype and do nothing about the governance obligations that follow. The constraint on internal healthcare app development was never typing speed. It is security review, audit evidence, compliance posture, and long-term maintenance, and code generated without provenance makes each of those harder to answer for.

CloudApper is the process layer that closes the gaps enterprise software cannot, across the clinical record, the HCM, the ERP, and everything in between, on any platform and in weeks rather than quarters. If your team is carrying a backlog of requests the EHR was never going to absorb, talk to us about what it would take to build them properly.