Grane PBM Replaced Box, Dropbox, and SharePoint With Files.com as It Grew From Two Health Plans to Thirteen

Grane PBM is a pharmacy benefit manager built for a single market: PACE, the Program of All-Inclusive Care for the Elderly. From Pittsburgh, it administers Medicare Part D prescription benefits for PACE organizations across the United States, covering Part D from bid to close-out. The big national PBMs are diversified across commercial, employer, and Medicare books. Grane PBM 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 Grane 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. Grane PBM sits in the middle of all of it, and every file in the chain carries protected health information.

A PHI Exchange Running on Box, Dropbox, and Hand Relays

Each client health plan generated its eligibility files and got them to Grane however that plan already shared files. One used Box, another Dropbox, another SharePoint, others ad-hoc SFTP. Grane 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 Grane circulated them out to each plan, again by hand.

The cost showed up on both sides of the desk. Grane's team spent part of every cycle moving other people's files instead of running a benefit. And every one of those files was protected health information governed by HIPAA, traveling through sharing tools chosen client by client, with no consistent security model and no enforced separation between one plan's data and another's.

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 Grane'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 Grane'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 system was not going to change how it worked for Grane, 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 Grane needed was a layer of its own in the middle: hosted under Grane's 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. Grane PBM selected Files.com to be that exchange layer. The Files.com exchange ultimately grew from two health plans in production to thirteen, 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 Grane'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 Grane. They sign in with a password and multi-factor authentication, while Grane'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 Grane 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 two 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 Two Health Plans to Thirteen

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

• Client health plans on the platform grew from two in early 2024 to thirteen, alongside the growth of Grane'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 Grane touching them.
• Protected health information no longer travels through Box, Dropbox, or SharePoint. Every plan exchanges files on one platform, where separation between plans is enforced by permissions rather than by care.
• 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 Grane signs clients, not at the pace its staff can build integrations.