An Addiction Treatment Provider Automates Claims EDI Exchange Into Azure With Files.com

A US addiction treatment provider delivers outpatient care for substance-use disorders, exchanging clinical and claims/EDI data with healthcare vendors and payers.

The provider used Files.com to automate those exchanges into Azure without forcing vendors to change their existing SFTP and FTP workflows or moving its Microsoft systems of record. The same layer also gave third-party sharing a common audit trail.

That work means a constant flow of claims, eligibility, and clinical data between the provider and its healthcare vendors, including clearinghouses, labs, and payer systems. The provider wanted one governed path for all of it, automated wherever a person did not need to be in the loop, with every transfer logged.

Vendor Feeds That Ran Through People

Until 2023, that exchange ran on people. Recurring vendor transfers meant someone pulling files from a vendor’s SFTP server and pushing them where they needed to go. Moving data onward between systems ran through manual Azure Data Factory processes. The provider’s systems of record, Azure, SharePoint, and OneDrive, connected only when a person carried files between them.

Ad-hoc sharing with third parties ran through three separate tools: Dropbox, Egnyte, and ShareFile. The provider wanted one tool for it, with every share landing in the same audit trail as every vendor transfer.

The requirement was simple: The provider wanted vendor exchange to run as infrastructure rather than as a series of manual tasks. Every recurring vendor feed consumed someone’s time, and nothing landed in the warehouse without a person in the loop.

The Vendor Workflows and the Microsoft Estate Both Had to Stay

The obvious fix was unavailable. The provider could not ask its healthcare counterparties to change how they worked. Their systems deliver files over SFTP and FTP, some of them through manual WinSCP uploads to an endpoint the provider offers. Whatever the provider built had to accept every vendor workflow exactly as it arrived.

The other side of the exchange was equally fixed. SharePoint, Azure Blob Storage, and OneDrive were the systems of record and were staying that way. A platform that required migrating data out of the Microsoft estate was a non-starter.

So the requirements wrote themselves: an SFTP and FTP endpoint that vendors could use unchanged, a direct connection into Azure and SharePoint without migrating those systems or creating a separate Files.com-hosted copy, automation to replace the manual pulls, and third-party sharing that left a record. The provider selected Files.com to be that exchange layer.

One Exchange Layer Between Vendor SFTP and the Data Lake

What the provider built made Files.com the middle of the exchange while preserving vendor workflows on one side and the provider’s Microsoft systems on the other.

On the vendor side, counterparties connected to a Files.com SFTP and FTP endpoint the same way they had always connected to anything. The rollout ran in parallel: vendors kept making manual WinSCP uploads while the provider stood up automated pulls behind the endpoint, so no counterparty had to change its client or habits.

On the provider’s side, Files.com Remote Server Mounts connected that endpoint directly into the Microsoft estate, with Azure Blob Storage and SharePoint mounted alongside it. A file a vendor dropped over SFTP was, in the same motion, a file in the data lake.

Between the two, the provider’s own developers built the movement. Files.com Automations copied each vendor’s SFTP drops on schedule, taking over the work that manual Azure Data Factory processes used to do by hand. Remote Server Sync kept the warehouse fed.

For the human side of exchange, staff shared files with third parties through Files.com share links instead of Dropbox, Egnyte, or ShareFile. All three tools were retired, and every share landed in the same audit trail as every vendor transfer.

What Runs Without a Person Now

With the Files.com workflows in production, recurring healthcare vendor transfers now run as scheduled automations. SFTP drops reach Azure Blob Storage and sync onward into the data warehouse without someone pulling or pushing each file, while third-party sharing runs through audited links.

Adding the next vendor counterparty is a credential, a folder, and an automation on a pattern that already exists, not another bespoke integration.

Modernizing the Exchange Without Touching Either Side

Today, file exchange at the provider is infrastructure rather than a task on someone’s list. The data team works in the warehouse instead of carrying files toward it, and every movement of patient data, whether an automated clearinghouse feed or a one-off share with an outside party, carries a record.

The vendors never noticed. Same protocol, same clients, same habits on their end, while everything behind the Files.com endpoint changed. The provider did not ask its counterparties to change, and it did not move its systems of record. It put Files.com between the two, and modernized the exchange itself.