Sanitas USA Replaced Google, SharePoint, and Manual Vendor Transfers With One Files.com Front Door for 20 Partner Connections

Sanitas USA is the United States arm of Keralty, a multinational health group with operations in ten countries. In the US, Sanitas operates more than 50 medical centers across Florida, Texas, Tennessee, New Jersey, and Connecticut, delivering primary, urgent, and senior care.

Those care networks depend on clinical, claims, and billing files moving between Sanitas, health plans, and the vendors behind both. Much of that data is protected health information, exchanged under HIPAA.

Sanitas also wanted to keep its bulk storage, archives, and analytics data in Azure Blob Storage. Any exchange layer had to govern how files moved without becoming a second storage estate to pay for and reconcile.

PHI Moved Through Collaboration Tools, or By Hand

For years, that exchange ran on two paths, and neither was built for it.

External sharing went through Google and SharePoint. Both are collaboration tools. Neither was designed as a controlled channel for regulated data leaving a health system, and files went out however the person sharing them decided to send them.

Vendor feeds were handled by hand. Health plans and vendors each hosted their own SFTP servers, and moving a feed meant a staff member logging into the counterparty’s server, downloading the files, and uploading them into the destination system manually. Every feed depended on a person running that routine, and clinical and claims data waited on whoever’s turn it was to move it.

The cost compounded as the group grew. Each new plan or vendor did not repeat a pattern; it added another manual routine and another set of someone else’s credentials to somebody’s day. Sanitas had no exchange layer. It had habits, and every one of them put a person between the data and its destination.

Twenty Counterparties, Each With Their Own SFTP Server

The manual routine survived because replacing it looked like engineering. Every counterparty ran its own endpoint with its own credentials, and onboarding a healthcare data partner included exchanging encryption keys before the first file moved. Traffic ran in both directions. Building a bespoke integration per vendor was never worth it for any single vendor, so the copying continued.

So the fix had a specification before it had a name. It had to speak SFTP to every counterparty on that counterparty’s terms and handle the key exchange onboarding required. It had to move files onward into Azure without becoming the archive itself. It had to take its users from the group’s Microsoft Entra directory, across multiple Azure tenants and two corporate domains. And it had to log everything, because the files contained PHI.

Sanitas selected Files.com to be that layer: the single entry point between its counterparties and its Azure estate.

One Front Door, and a Standard Way to Open It

Files.com became the group’s external SFTP entry point, running under Sanitas’s own domain. When a counterparty sends files in, or Sanitas publishes files out, that branded endpoint is the address.

Connecting a new vendor now follows company policy and one repeatable pattern. Sanitas generates and exchanges access keys, then points a Files.com Remote Server sync at the vendor’s SFTP server. Scheduled pulls collect posted files without anyone logging in, giving roughly twenty outbound vendor connections the same automated onboarding pattern.

The Transfer Layer in Front of Azure Blob

Files.com moves the files. Azure keeps them. Files that land on Files.com sync onward into Azure Blob Storage through the same Remote Server engine, feeding processing and archive, including an analytics data set of roughly 2 TB that flows into a Blob container. The group’s CIO describes Files.com as the transfer and access layer, with mass storage deliberately staying in Azure. Adopting a governed exchange platform never required a storage migration, and Files.com never became a second archive to pay for.

Identity governance runs through the same platform. Sign-in uses SAML single sign-on against Microsoft Entra ID, serving users from multiple Azure tenants and two corporate domains on one site. SCIM provisioning creates and retires accounts from the directory instead of by hand, while per-user share-link restrictions make public sharing a permission an administrator grants rather than a default anyone can exercise.

Files.com forwards automation logs and settings-change logs into Microsoft Sentinel, where the group’s dashboards and alerting live. Folder administrators who hold no platform-admin rights can watch their own workflows and receive an alert when a sync fails. A feed that breaks shows up instead of failing quietly.

Anything Leaving Sanitas Now Leaves One Way

With the Files.com workflows in production, Sanitas replaced tool-by-tool sharing habits and hand-carried vendor feeds with one governed route out of the organization.

• Files.com is the designated path for anything leaving the group publicly. One entry point and one audit trail took the place of files scattered across Google, SharePoint, and manual SFTP sessions.
• Nobody carries vendor files by hand. Scheduled syncs collect from roughly twenty counterparty servers and deliver into Azure Blob, and the people responsible are alerted when a run fails.
• PHI no longer travels through collaboration tools that were never built to govern it.
• A few terabytes moved through the platform in its first year, demonstrating that the pattern could absorb real growth without changing the storage architecture.

The immediate result was the manual work that stopped. The larger one is that the next connection is cheap. A healthcare data partner that once meant a new manual routine and a new set of credentials now means a key exchange and a sync that runs itself.