A Healthcare AI Company Handles Dozens of Monthly Partner Access Requests on Files.com Instead of Building SFTP in AWS

A healthcare AI company builds AI agents that handle patient conversations for non-diagnostic care: intake, scheduling, chronic-care follow-up, preparation before a procedure, and check-ins after discharge. Its customers are health systems, payors, and life sciences companies.

Every one of those partnerships is a data relationship as much as a product relationship. An agent cannot reach a patient without data from the partner's systems, and the partner needs the record of every conversation back: call summaries, transcripts, and recordings. Each signed health system or payer means regulated patient data crossing between two organizations, in both directions, for the life of the contract. The company's growth is counted in signed partners, and so was its file transfer problem. Rather than finish its SFTP build in AWS, the company chose Files.com.

Every New Partner Meant Another Hand-Built Pipeline

Before Files.com, the company was building that exchange layer itself. The team was standing up its own SFTP service inside AWS and moving customer data with custom code and manual steps. Every hour spent on transfer infrastructure came out of the product, and every newly signed partner added more code to write, more steps to run by hand, and more surface area holding sensitive patient data.

The partners themselves made the problem harder. Health systems and payers are conservative about integration, and many prefer to push or pull files over plain SFTP, the protocol their teams have known for decades and their security reviews already cover, rather than build a direct integration. And access requests keep arriving: the company fields dozens of new partner access requests in a month.

An exchange layer assembled one partner at a time cannot survive intake at that rate. What the company needed was a repeatable pattern: something that sits between its own S3-based systems and whatever endpoint each partner runs, speaks the plain SFTP those partners expect, keeps every partner's data separate, expires exchange files on a set retention window, keeps US and Canadian client data in their own regions, and operates under a HIPAA Business Associate Agreement, a gating requirement for anything touching this data.

In the CISO's own accounting, Files.com's competition was never another vendor. It was the SFTP service his own team would otherwise be running inside AWS.

A Repeatable Sync Pattern Between S3 and Every Partner

Files.com became the governed middle layer between the company's systems and every partner endpoint. Files.com Remote Server Syncs move data in both directions between the company's Amazon S3 environment and each partner's preferred SFTP server or remote storage. Partners who prefer to connect directly do so over write-only SFTP credentials with SSH-key authentication.

The point of the design is that it repeats. Syncs are created programmatically through the Files.com Python SDK, and platform changes are validated on a child site running UAT syncs before they touch production. When a new health system or payer signs, standing up their exchange is provisioning work on the established pattern: folders, credentials, and API-created sync flows. It is not a data-movement project.

Housekeeping belongs to the platform too. Files.com Automations and Data Governance rules sort incoming files into subfolders by month and by content type, splitting summaries, recordings, and transcripts, and expire partner-exchange files once their retention window passes. Those regulated exchange files no longer have to be organized or purged by hand.

Locked Down for Regulated Patient Data

Instead of building and operating security controls around its own SFTP service, the company used Files.com to enforce Okta single sign-on with SCIM provisioning, two-factor authentication, country-level geo-blocking, and restricted API scopes. US and Canadian client data remains segregated in its respective storage regions, and the platform operates under the HIPAA Business Associate Agreement the deployment required from day one.

Exchange That Scales at the Rate the Business Signs Partners

With the Files.com pattern in production, the company replaced a hand-run SFTP build with an exchange layer that grows by provisioning rather than engineering.

• Onboarding a newly signed partner is folders, a credential, and API-created syncs. The dozens of partner access requests that arrive each month are absorbed on the same pattern without rebuilding the SFTP layer for each one.
• The machinery grew with the business: automations and sync flows climbed steeply over one contract term, and monthly exchange volume now runs at terabyte scale.
• Retention and foldering are enforced by the platform, so partner-exchange files expire on schedule instead of accumulating.

Behind this partner-exchange pattern, the company does not have to run and maintain the file-transfer servers it had been building.

The CIO now sizes the Files.com platform the same way he sizes the business: connections, users, and volume all scale as a straight function of signed partners.

The Infrastructure They Never Had to Finish Building

Today, a health system that wants to push files over the protocol it has trusted for decades gets exactly that, and nobody at the company has to stand up a new SFTP service or hand-build its exchange layer. What used to mean custom code and manual handling for each contract is now a provisioning step, and the company can keep signing healthcare partners knowing the exchange each one requires is already built.

The company never asked its partners to move off SFTP. It moved SFTP onto Files.com, and turned every future partner's data exchange into a pattern instead of a project.