Lumexa Unified Seven Companies on Oracle ERP and HCM—and Now Runs Nine Partner Connections Through Files.com

Lumexa Imaging, formerly US Radiology Specialists, is a United States outpatient diagnostic imaging and radiology group built by acquisition. Regional radiology practices and outpatient imaging brands joined the group one at a time, and by 2025 that growth had produced a business of 5,000 employees that still ran as roughly seven operating companies, each with its own financial and HR systems. That year, Lumexa 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. Lumexa 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.

Lumexa'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.

“We really wanted to keep this segmented as much as possible.”

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 5,000 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.

Nine Connections in Production, Built to Run Untouched

With the Oracle program live, Lumexa replaced what would have been a bespoke integration build per counterparty with one repeatable exchange pattern. Seven operating companies now run 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:

• Nine 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 Lumexa's employees leave Oracle, get encrypted with the bank's key, land on the bank's server, and come back, with nobody at Lumexa 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. Lumexa 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 seven companies' data into one system now carries that system's files to the outside world.