A Radiology Group Unified Its Operating Companies on Oracle ERP and HCM—and Now Runs Its Partner Connections Through Files.com

A US radiology group runs outpatient diagnostic imaging built by acquisition. Regional radiology practices and outpatient imaging brands joined the group one at a time, and that growth produced a business of thousands of employees that still ran as several operating companies, each with its own financial and HR systems. The group set out to unify all of them onto a single Oracle ERP and HCM instance.

The job was not only to stage each company’s conversion data. The group also needed a repeatable way to exchange files between Oracle and outside partners without turning every bank and vendor connection into a custom integration project.

A Consolidation Is a File-Movement Problem First

Before Oracle could run anything, the data had to get there. Every operating company's conversion data had to be staged on its way into the new system, and that data was as sensitive as corporate data gets: financial records, Social Security numbers, and human resources files for the entire workforce.

The group's revenue cycle arm already ran its billing file operations on Files.com in an environment built around patient data. That gave corporate IT an established approach to file operations, while a dedicated Files.com site could keep the ERP program's data entirely apart from the billing environment.

The second problem was the outside world. Oracle Integration Cloud has an SFTP endpoint, but it is an internal one. It is where Oracle drops files and picks them up, not a service a bank connects to. Every file bound for a counterparty had to be pulled out of OIC, sorted, encrypted with that partner's public key, and delivered to the partner's own server, and everything the partner sent back had to make the return trip into Oracle.

Multiply that by every counterparty, and again by development, test, and production environments, and each vendor connection threatened to become its own integration project inside a program that already had a go-live date. These were the flows that would let the new system pay thousands of employees and settle accounts with the company's bank. The go-live depended on them working.

The Layer the Program Needed

What the program needed was a layer in the middle. It had to hold conversion data behind its own access boundary, connect to OIC on one side and each partner's server on the other, apply each vendor's encryption before delivery, bring returns back in, keep archives, and move from development to test to production without being rebuilt each time.

Corporate IT stood up a dedicated Files.com site to be that layer, deliberately separated from the billing environment.

Out of Oracle, Encrypted, Delivered, and Back

In production, Files.com sits in the middle of every exchange between Oracle and an outside partner. Nothing custom runs inside Oracle, and nothing is installed at the partner.

Files.com pulls outbound files from Oracle, sorts them into per-vendor staging folders, applies GPG encryption using each vendor's public key, and delivers them to the partner's remote server. Inbound files travel the same road in reverse: Files.com pulls them from the partner, decrypts them, and returns them into Oracle.

One design choice made the whole thing repeatable. The team unified the OIC folder schema so a single automation pattern matches any vendor generically, instead of requiring one hand-built automation per flow. The first flows, built for the bank and a revenue recognition vendor, moved from development to test without being rebuilt, and the pattern passed system integration testing on the financial environment in June 2025.

The same site carried the human side of the consolidation. Members of the conversions team moved each company's data in and out over SFTP, behind folder-level permissions, with none of it ever touching the patient-data environment.

Partner Connections in Production, Built to Run Untouched

With the Oracle program live, the group replaced what would have been a bespoke integration build per counterparty with one repeatable exchange pattern. Every operating company now runs on a single Oracle ERP and HCM instance, and every piece of conversion data that carried them there was staged through Files.com. In production:

• Outbound connections run between Oracle and external partners, including the banking flows the go-live depended on.
• The banking integrations run without day-to-day attention. The team built them once and intends to run them indefinitely.
• Adding the next counterparty is configuration rather than a project: a Remote Server connection, the vendor's public key, and folder paths the existing automation pattern already matches.
• Financial records, Social Security numbers, and HR data stayed segmented from the patient-data environment through the entire program.

One Business, One System, One Exchange Layer

Today, the files that pay the group's employees leave Oracle, get encrypted with the bank's key, land on the bank's server, and come back, with nobody at the group touching any of them. Before the cutover, every one of those movements was a build waiting to happen inside the ERP program.

The consolidation points at something larger. The group never built partner exchange into Oracle at all. The exchange lives beside the ERP, in Files.com, where connecting the financial system to a counterparty is a folder pattern and a key rather than a development effort. The same site that staged every company's data into one system now carries that system's files to the outside world.