A Medical Transportation Software Vendor Runs a Branded Multi-Tenant Client Portal on One Files.com Site

A North American software vendor builds the platform that runs non-emergency medical transportation. Its software handles scheduling, dispatch, billing, and compliance for the organizations that move patients to medical care when an ambulance is too much and an ordinary ride is not enough: Medicaid and Medicare Advantage plans, managed care organizations, brokers, PACE programs, and large-scale transportation providers.

Every step of that journey is health data. A trip record ties a person to a place and a medical appointment. A claims file prices it. Both are protected health information under HIPAA, and both flow constantly between the vendor and its client organizations: clients send trip and claims files to the vendor's customer care and support teams, and those teams send files back. File exchange is not incidental to this business. It is how the business runs.

The vendor needed one branded, multi-tenant portal that could act as a separate, controlled exchange for every client without becoming a product its engineers had to build.

One Governed Exchange for Every Client

The vendor wanted one governed path for that exchange: every client's data kept apart from every other's, every user authenticated in a known way, a business associate agreement behind it, and a record the company controls of what happened and when.

One Secure Drop Point Was Not Enough

The obvious fix, a single secure drop point, did not match the shape of the problem. The vendor exchanges files with many independent client organizations at once, and its VP of Security and Compliance set out what the exchange had to do. Each client's technical staff, one person or several, had to reach their own folder and nothing else. The vendor's staff had to see every client folder. Internal staff had to authenticate through the company's Azure Active Directory, with single sign-on and two-factor authentication; client users, who have no place in that directory, needed two-factor authentication of their own. The whole thing had to run under the vendor's name, not a third party's. And there was a jurisdictional axis on top: most clients' data had to stay in the United States, while a small number had to be restricted to Canada, in separate folders.

That was not a transfer tool. That was a multi-tenant client portal, with tenancy, two authentication regimes, a folder-level permission model, the protocols clients already use, residency controls, and logging. Built in-house, it would have been a product in itself, competing for engineering time with the software the vendor actually sells, and it would still have needed a HIPAA business associate agreement behind whatever it ran on.

The vendor selected Files.com to be that exchange: one multi-tenant site under its own brand, covered by an executed Files.com HIPAA BAA.

One Site That Acts as a Separate Exchange for Every Client

Files.com became the vendor's branded client file exchange. To the vendor it is one site with one set of controls. To each client organization it looks like a private exchange of their own.

Each client gets a folder and its own logins, and Files.com folder-level permissions make the isolation structural. A client's technical staff see their folder and nothing beyond it, while the vendor's customer care and support staff see every client folder and move trip and claims files in both directions.

Internal staff sign in through Azure Active Directory single sign-on with two-factor authentication. Client users authenticate outside that directory, with two-factor authentication enforced by Files.com, and can connect using SFTP, FTPS, WebDAV, or the web interface.

The site answers on the vendor's own domain, so the exchange a client sees carries the vendor's name end to end. It also means the endpoint lives inside the vendor's own security posture: the security team tracks it through SecurityScorecard, the third-party rating service it uses across its estate, and holds it to the same expectations as everything else it operates.

Within the same site, regional restrictions keep US and Canadian client data in the required regions and separate folders. Files.com retention rules expire files after a set period, and every login and file action lands in the site's audit log.

A Record the Vendor Can Produce

With the exchange in production, onboarding a client became a repeatable pattern: each client is given a folder and a login on the company's own address.

• Every client's trip and claims files move through its own folder under a HIPAA BAA.
• The record exists before anyone asks for it. Every login and file action is logged, so the account of what happened and when comes from the platform.
• Onboarding the next NEMT client is a folder and a login inside controls that already exist: no development and no new channel for the security team to review.

The Client Portal the Vendor Never Had to Build

Today a client's technical staff drop a claims file into their own folder, on an address that carries the vendor's name, using the transfer client they already run, and the vendor's care team picks it up from the other side. Nobody at a client decides how to send a file, because the folder is the only path a client is given.

What the vendor's requirement described was a product: multi-tenant, branded, dual-authentication, region-aware, auditable. What it stood up instead was a configuration of Files.com, and its engineering stayed on the transportation software it sells.