A Medicaid Transportation Benefits Manager Feeds Claims From Hundreds of Providers Through Files.com—Without Hundreds of Integrations

A Medicaid transportation benefits manager handles non-emergency medical transportation (NEMT) benefits for state Medicaid programs and managed care organizations. It doesn't drive anyone anywhere. It administers the benefit: verifying member eligibility, scheduling trips, adjudicating claims, and credentialing and monitoring the contracted transportation companies that perform the rides. That network includes hundreds of independent providers and supports millions of trips a year.

Those operations generate claim and encounter data that providers submit to the company. That puts the company at the receiving end of claim files from hundreds of transportation companies, and every one of those files carries protected health information. The company used Files.com as both a branded, BAA-backed front door for that network and the event layer feeding its EDI claims system.

Every Claim Arrives as a PHI File From a Transportation Provider

The senders are independent transportation operators, not one centrally managed organization. The company could not ask hundreds of them to build a custom integration each, and it could not let regulated health data travel over whatever channel each operator happened to reach for. At this scale, an intake path is HIPAA-compliant for the whole network or it is not compliant at all.

The other half of the constraint sat downstream. Claims processing is the workflow the business runs on, and the data arriving from providers had to reach the company's EDI claims system without a person carrying it there. A compliant dropbox that someone empties by hand fails at the scale of this network: any step that depends on an operator noticing a file and moving it puts a core workflow at the mercy of manual handling.

So the intake layer had a specification before it had a name. It had to sit under an executed Business Associate Agreement. It had to carry the company's own name, so providers submitted to the company rather than to a vendor they had never heard of. It had to offer widely used transfer options—SFTP, FTP, or REST API—without requiring a custom integration for each provider. It had to keep every provider walled off from every other. And it had to be programmable, so that when a file arrived, the company's own systems would know and act.

A BAA-Backed Front Door With a Webhook on Every Folder

The company selected Files.com to be that intake layer: a HIPAA-enabled site under an executed BAA, running on the company's own branded domain.

Each provider received its own folder, reachable over SFTP, FTP, or the REST API. Folder controls kept the structure fixed for the company's automation, while permissions scoped every account to its own files. User lifecycle automation set accounts inactive after a period without activity, so dormant credentials across the external network shut off automatically.

Files.com watched the intake folders and used webhooks to notify the company when claim files arrived. The company's own C# service downloaded each file through the Files.com REST API, passed it into the EDI claims workflow, and uploaded the response to the same provider folder. The exchange ran in both directions, and no one at the company touched a file to make it happen.

Files Land, Notify, and Flow to Claims Without an Operator

With the pipeline in production, provider claim intake does not depend on a person at the company moving files.

• Claim files from the provider network land, fire a notification, and flow into EDI claims processing with nobody moving them. The response makes the return trip into the provider's folder the same way.
• Adding a provider to the network adds a folder and a credential, not an integration project. The webhook-and-API pattern applies to the new folder exactly as it applies to every folder already there.
• PHI stays inside one BAA-backed perimeter carrying the company's name, with access scoped per provider and dormant accounts deactivated automatically.

One Pattern for the Whole Network

A network of hundreds of small, low-tech partners did not need hundreds of integrations. It needed one governed file layer that speaks the protocols the partners already use, holds PHI behind a BAA, and fires an event when a file arrives. Files.com gave the company that layer, and the entire provider network now feeds claims processing through it.