A Pharmacy Benefit Manager Onboards Each New Health Plan Onto One Automated Files.com Exchange

A specialty pharmacy benefit manager administers Medicare Part D prescription benefits for health plans across the United States, covering Part D from bid to close-out. The big national benefit managers are diversified across commercial, employer, and Medicare books. This one does one thing, inside one of the most tightly regulated corners of Medicare.

A benefit manager's product is largely other organizations' data, moved correctly. Eligibility files come in from every health plan the company administers. Claims flow to its claims processing partner. Prescription Drug Event records go out to CMS, and summary reports come back and have to reach each plan. The benefit manager sits in the middle of all of it, and every file in the chain carries protected health information.

A Hand Relay for Every Plan, Every Cycle

Each client health plan generated its eligibility files and sent them to the benefit manager its own way. Its staff took each file and uploaded it by hand to the claims processor's SFTP site. At month end, the processor posted CMS summary files back, and someone at the company circulated them out to each plan, again by hand.

The cost showed up on both sides of the desk. The company's team spent part of every cycle moving other people's files instead of running a benefit. And the company wanted one path for all of it: a single hosted exchange under its own name, where every plan's files land in that plan's own space and move on without a hand relay.

The arrangement also grew heavier with every win. A new health plan meant one more sharing arrangement to accommodate and one more set of hand relays each cycle. As the company's business grew, the manual exchange was becoming the limit on how many plans the team could take on.

Neither End of the Exchange Was the Benefit Manager's to Change

The obvious fix, picking one system and making everyone adopt it, was not available. On one side sat the claims processor, whose SFTP site generates the Prescription Drug Event (PDE) files CMS requires every two weeks: Part D claims, corrections, and resubmissions. That endpoint was fixed, and a live claims cycle could not be paused while something new was built. On the other side sat the health plans, each expecting a hosted, secure location where their own people could send eligibility files and receive claims data.

What the company needed was a layer of its own in the middle: hosted under its own name, keeping each plan's files strictly separated, speaking SFTP to the processor exactly as it already worked, and able to take on the next health plan without a bespoke project. The benefit manager selected Files.com to be that exchange layer. The Files.com exchange ultimately grew from its first health plans in production to many more, with each new plan brought on through the same scripted process.

Building the Exchange Around a Processor That Couldn't Move

Files.com became the governed layer between every health plan, the claims processor, and the CMS reporting cycle, while the processor's existing SFTP endpoint stayed in place.

Each health plan got its own folder structure, security groups, and permissions on the company's own branded transfer domain, so a plan's users see that plan's files and nothing else. Most of the site's users work for the health plans rather than for the benefit manager. They sign in with a password and multi-factor authentication, while the company's own staff sign in through SAML single sign-on against Microsoft Entra ID.

The claims processor's SFTP site was mounted into Files.com as a remote server, so its folders appeared inside the exchange without the processor changing anything. Files.com Remote Server Syncs carried eligibility files to the processor and PDE and report files back, while Files.com Automations distributed month-end summary reports to each plan.

Then the company wrote the onboarding itself as code. Using the Files.com .NET SDK, the folders, security groups, permissions, syncs, and automations for a new health plan are created programmatically, with error checking built in. Bringing on the next plan means running a program, not designing another integration.

The rollout ran alongside live operations. The first plans came into production in early 2024, entering files manually while the syncs and automations were layered in behind them, so the Part D cycle never paused.

From the First Health Plans to Many More

With the Files.com exchange in production, the benefit manager replaced a per-client hand relay with a repeatable, automated pattern.

• Client health plans on the platform have grown many times over since early 2024, alongside the growth of the company's own business, with each new plan brought on by the same scripted process.
• Eligibility, PDE, and report files now move through the exchange, routed and delivered with no one at the company touching them.
• Every plan exchanges protected health information on one platform under the benefit manager's name, with separation between plans enforced by folder permissions and security groups.
• The month-end CMS reporting that used to be circulated by hand reaches every plan automatically, every cycle.

Because standing up a new health plan is a program run rather than a project, the exchange scales at the pace the company signs clients, not at the pace its staff can build integrations.