CommuniCare Health Centers Begins Replacing WinSCP Scheduled Pulls With the Files.com Agent

CommuniCare Health Centers is a Federally Qualified Health Center serving an estimated 140,000 patients across more than 25 clinics in South Texas. Its network provides primary and specialty care from newborns to seniors alongside dental, behavioral health, and pharmacy services.

A health network that size ran on files from outside. Health plans and business partners pushed data files on their own schedules, some daily. Automated feeds moved HL7 and JSON files into the interface engine that supported patient care. And the people who worked those files sat in departments across the network, where the tool they worked from was a Windows file share. Files.com governed the intake; scheduled SFTP pulls still handled the last mile to those shares.

A Governed Front Door, and a Last Mile Someone Had to Maintain

For years, the front door had been Files.com. Each partner and payer pushed files into its own dedicated folder, on its own schedule, through a write-only upload path restricted by IP allowlist, with email notifications firing on arrival, all under a HIPAA business associate agreement in place since 2021. CommuniCare had no interest in changing any of that. Partners sent everything to one governed intermediary, and from there the data was distributed to where the work happened.

The distribution was the problem. The staff who needed those files numbered in the hundreds, and provisioning hundreds of employees with accounts on a file transfer platform made no sense: most needed only the files that concerned their department, delivered inside CommuniCare's own ecosystem. So the bridge between the platform and the file shares was WinSCP and generic SFTP clients, installed on internal Windows file servers, running scheduled pulls under an admin account or a dedicated Windows service account.

That bridge carried a standing cost. The clients were third-party software IT had to maintain, keep track of, and update on its own file servers. The pulls ran under privileged Windows accounts somebody had to own. And delivery ran on the pull schedule, not on arrival: a file a payer pushed sat in the cloud until the next pull came around. Every new departmental flow meant more of the same plumbing, another scripted pull to write and another one to watch.

The arrangement lasted because everything around it worked, and the alternatives were worse: put hundreds of staff on the transfer platform, or build and maintain sync tooling of their own. But as CommuniCare expanded, every added department added to the client layer IT was carrying by hand.

What CommuniCare needed was a last mile that lived inside its own Windows ecosystem. Partners would keep pushing to the same folders. Files would land in departmental directories on servers staff already reached. Nothing would be installed that IT had to patch, and no staff member would need a transfer-platform credential. CommuniCare chose the Files.com Agent, the platform's own on-premises connector, to be that last mile.

“Files.com already has an agent built in to do that, versus using third-party software that we have to maintain, keep track of, and update, and then run on somebody's account, like an admin account or a dedicated Windows account.”

A Native Windows Service Starts Replacing the Client Layer

The initial Agent went onto a Windows file server with a dedicated volume, installed as a native Windows service under a purpose-provisioned service account. It holds an outbound-only encrypted connection to Files.com, so nothing on the network had to be opened inbound, and it keeps itself patched as part of the platform.

On top of the Agent, each departmental flow became a sync mapping: a Files.com folder on one side, a mirrored directory on the Windows file server on the other. When a partner pushed a file into its folder, the Agent synced it down almost in real time, on a short interval. CommuniCare proved the per-department mappings on a single file server carrying multiple departmental directories, with its own IT team owning the server, the service account, and the endpoint. Nothing changed for partners: the same folders, the same write-only permissions, the same IP allowlists, the same schedules.

That single-server deployment was the first stage of the rollout. Scaling the pattern to additional servers and departments remained the next step.

Delivery on Arrival, With No Transfer Client Left to Patch

On that first server, CommuniCare replaced a hand-maintained pull layer with a sync the platform runs itself.

• Partner files land in their departmental directories in near real time instead of waiting for the next scheduled pull.
• There is no third-party transfer client on the file server for IT to patch or track; the Files.com Agent updates itself as part of the platform.
• Staff work partner files from the Windows shares they already use, without holding Files.com credentials.
• Bringing another department onto the pattern requires a folder-to-directory mapping, not another installed client and another scripted pull to babysit.

The Platform That Receives the File Now Delivers It

On the first server, the Agent closed the seam between CommuniCare's transfer platform and its staff. Partners still send everything to Files.com, the same governed intermediary they have pushed to since 2021. What changed is the far end: a staff member opens their department's share and the file a payer sent is already there, and nobody in IT owns a client, a script, or an admin login to make that true. An organization does not have to choose between one governed intake point and the file shares its people actually work in. With Files.com, the platform that receives the file is the same system that delivers it, and the last mile stops being software anyone has to maintain.