A Healthcare Program Administrator Connects Specialty Pharmacies With No IT Staff to SharePoint With Files.com

A US healthcare program administrator manages a federal drug-pricing program for eligible providers, which lets them buy outpatient medication at reduced prices and use the savings to fund care for uninsured and low-income patients. The company serves hospitals, health systems, and federally qualified health centers nationwide, and its work is data in motion: pharmacy claims, drug pricing, and patient records moving between covered entities and the national wholesalers and payers that serve them, all of it regulated under HIPAA.

Its newest service line helps health care providers stand up and operate their own specialty pharmacies. The clients that line serves are nothing like the hospital systems the rest of the business exchanges files with. They are small pharmacy operations handling expensive therapies, and most of them have no one in charge of technology at all. The company was entering a market where its customers, by the nature of that market, could not operate a file transfer tool.

The company used Files.com browser links for pharmacies and automatically handed files to and from isolated client areas in SharePoint, without exposing SharePoint itself.

Regulated Files, Clients With No IT Staff

Launching a pharmacy meant moving HIPAA-regulated client and patient data back and forth between the client and the company's implementation team, and the company wanted one governed path for it from the first client. The files are large, and the industry-standard tool for moving them, an SFTP client on the pharmacy's own desktop, assumed a kind of staff these clients simply did not have.

The cost landed on the launch itself. A file the client couldn't send is a pharmacy launch waiting on a technician the pharmacy doesn't employ, and data this sensitive has to travel one governed path from the start.

And the company controlled neither end it needed to change. It could not push software or training into its clients. Its own side was SharePoint, the internal system of record holding every client's data for the new line, which no external party could be allowed to see and where one client's data can never be visible to another. Every external touchpoint also had to survive the HIPAA and SOC 2 scrutiny the rest of the business answers to.

What the New Line's File Exchange Had to Do

The line was going live, and clients would arrive one at a time. Prospective pharmacies were already asking to send files during exploratory conversations. The exchange could not wait for the clients to change, and it had to be easy to extend to every client after the first.

That set the specification. A sender needed nothing but a browser: no account, no login, no software. Each client had to see its own folder and nothing else. SharePoint had to stay internal and be fed automatically. Prospective access had to be temporary. The company built the client-facing layer of the new line on Files.com.

Files.com in Front, SharePoint Behind

The design put Files.com in front and kept SharePoint behind. Everything a pharmacy client touched was a Files.com page under the company's branding. Everything internal stayed in SharePoint, which no client could see or reach.

The company built the line on a dedicated Files.com child site: a fully separate site under the company's account, walled off from the rest of the company's file estate, where each pharmacy client was limited to exactly one thing, its own folder. That folder was joined to the client's area in SharePoint through a Files.com Remote Server Mount. When a client dropped a file, a Files.com Automation moved it into SharePoint for the implementation team. When the team placed an outbound file in SharePoint, a scheduled job carried it back out to the client's Files.com folder. Nobody had to re-upload anything by hand, and no external credential ever touched SharePoint.

For the pharmacy, all of this amounted to a link. A Files.com Inbox link opened an upload page in the browser, with no account to create, no software to install, and no file-size ceiling to work around. Going the other direction, the implementation team pasted Files.com share links into the Monday.com project boards its clients already worked from, so delivery happened inside the project plan.

Because an Inbox required no account, the company could give prospective pharmacies temporary access to exchange files during exploratory conversations, then disconnect the link when it was no longer needed.

The First Clients Were Live Within About a Month

With the child site in production, the company put a browser link in front of every pharmacy client, with no desktop SFTP client to install, and stood the whole line up as clients arrived.

The first specialty-pharmacy clients were live within about a month of the build-out.

• A pharmacy with no technical staff now sends and receives HIPAA-regulated files through a browser page, with no SFTP client, no login, no waiting for a technician, and no size ceiling on the files.
• The SharePoint system of record is invisible to every external party, and each client sees only its own folder.
• Onboarding the next client means cloning the pattern: a folder, a mount, a link.

The Exchange Now Matches the Client

The line was built to serve clients that are, in the company's own description, too small to manage their own technology. Before the build-out, that fact set the pace of every exchange: a file waited until the pharmacy could find a technician to run the transfer. Today the client's side of the exchange is a link that works in any browser, and the company's side is the SharePoint estate its team already works in, fed automatically and never exposed.

What the company established reaches past the initial clients. With Files.com as the client-facing layer, the company can put a governed, HIPAA-grade exchange in front of any customer who has nothing but a browser, without exposing the system of record behind it. The clients never had to become technical. The exchange became something they could use instead.