Everly Health Solutions Configures Dozens of Health Plan SFTP Connections in Files.com, Not Custom Code

Everly Health Solutions (formerly PWN Health) is the enterprise arm of Everly Health, the digital health company behind the Everlywell at-home testing brand. While the consumer side sells test kits through retail, Everly Health Solutions runs the diagnostic programs behind the healthcare system itself: population-scale screening and clinical reporting for health plans, employers, and lab partners, delivered across all 50 states.

Every one of those programs ends in data. A screening program for a health plan's members is only finished when the results and reporting land back in the plan's own systems, and health plans receive files one way: on their own SFTP endpoints, under their own credentials, on their own terms. For Everly Health Solutions, delivering files to payers is not a back-office chore that sits next to the product. It is how the product arrives.

Without a Platform, Every New Health Plan Would Mean Another Script

Each payer connection is bespoke in the ways that matter. A different endpoint. Different credentials. A different level of technical capability on the receiving side, because many payer teams cannot implement file decryption at all, which means a delivery scheme built on partner-side PGP breaks down at exactly the counterparties it is meant to protect. And the stakes are not ordinary: roughly half of the files Everly Health Solutions exchanges with its partners contain protected health information.

The data engineering team's own method for scripted file movement was Bash and Python running on EC2. Built that way, every payer connection is an engineering integration. An engineer writes the script, owns the credentials, and gets pulled in whenever a routine drop has to happen. The senior data engineering manager who owns the environment is blunt about the alternative to a platform: the data engineering team gets involved, and it writes more Bash and Python.

That model had a structural problem, not just an effort problem. Everly Health Solutions controls neither end of the exchange. The payer's endpoint belongs to the payer, and its own reports are generated inside an AWS and Snowflake processing environment. The delivery layer sits between systems it cannot change, and supporting more health plan clients compounds the cost, because each new client is another integration for a team whose job is data pipelines, not file drops.

The delivery layer had to speak SFTP to endpoints owned by dozens of different payers, deliver machine-to-machine the moment a report was generated, connect natively to S3, carry PHI under a HIPAA Business Associate Agreement with encryption at rest even when files arrived in plain text, and be operable by people who do not write code. Everly Health Solutions selected Files.com to be that delivery layer.

A Remote Server Per Payer, an Automation Per Delivery

Everly Health Solutions configured Files.com as one hub between the AWS environment where reports were generated and dozens of partner endpoints where they had to land.

Each health plan's SFTP endpoint was configured as a Files.com Remote Server and mounted into that payer's own folder. Copy File Automations watched those folders and delivered new files to the payer's endpoint machine-to-machine, with outbound connections originating from the account's dedicated IP addresses.

On the AWS side, S3 mounts and bidirectional syncs connected Files.com to the processing environment. For workflows where delivery had to begin the moment a report appeared, a sync pulled generated PDFs into per-payer folders, where a file-creation event triggered automated delivery. Individual payer report folders grew very large; syncs paired with Files.com Folder Organization rules absorbed that volume without custom code.

The compliance layer was built underneath all of it. Files move under an executed HIPAA BAA with encryption at rest on the platform, so a partner whose team cannot implement decryption still receives its files while Files.com encrypts them at rest.

The people layer is the part the engineering team values most. Operations staff, not engineers, run routine outbound drops and pick up inbound client files through the web interface, signing in through Okta, with Slack and email alerts firing as files are created, processed, and delivered.

Dozens of Payer Connections, and No Engineers in the Delivery Path

With the Files.com hub in production, Everly Health Solutions avoided an integration-per-payer model with a delivery pattern it can configure and repeat.

• Adding a health plan is configuration, not code: a Remote Server, a folder, an automation. Dozens of outbound partner connections now run the same way.
• Routine partner file movement runs without the data engineering team. The operations team handles drops and pickups in the browser, and engineers stay on the pipelines they were hired to build.
• PHI moves under an executed BAA with platform encryption at rest, including to payers whose teams cannot handle decryption. A partner with a limited technical team is still a partner Everly Health Solutions can serve.

The Delivery Layer Runs as Configuration

Today, when a new health plan signs on, nobody on the data engineering team opens an editor. What otherwise would mean another engineer-written, engineer-owned script per payer is now the same Files.com pattern applied one more time, and the routine work of getting clinical reporting into a payer's hands belongs to the operations team. For a company whose programs reach some of the largest health plans in the country, that is the difference that scales: Everly Health Solutions built a repeatable way to deliver regulated clinical data to partners it cannot standardize, and made it something you configure rather than something you write.