Files.com Turns Partner-Specific 834 Intake Into Repeatable Configuration for HRI Dental & Vision

HRI Dental & Vision is the dental and vision benefits arm of ProMedica Health System, providing coverage for roughly 250,000 members. It receives, validates, and processes enrollment data from employer groups, agents, producers, and EDI vendors.

A payer does not generate its own enrollment data. It arrives from outside, delivered as ANSI X12 834 enrollment files. Every member on HRI's books got there through a file that somebody else's system sent. Files.com turned those partner-specific connections into a repeatable configuration model that has absorbed roughly 30 new partner accounts a year.

Enrollment Arrives on the Partner's Terms

On a typical day, about 50 vendor groups, agents, and producers send 834 files to HRI, most through their own automation on a weekly schedule. The population behind those files never stops changing, and each new partner arrives with a security posture HRI does not get to choose. One EDI vendor's policy requires encrypted files. Another prohibits password authentication and requires SSH keys. Others restrict which IP addresses may connect. The files carry protected health information, so every one of those arrangements has to hold up under HIPAA.

Then there is the fourth quarter. Open enrollment is when new accounts get set up and enrollment files surge, at the same time.

This exchange used to run on an internal PGP-encryption file server, where every partner connection was hand-built: an account, a folder, credentials, a notification, and often a one-off accommodation for whatever that partner's security policy demanded. A small team did all of it. That held while the electronic book was smaller. As more groups moved to electronic transfer every year, the pace at which HRI could take on partners became the pace at which people could hand-build connections, and the season when the most partners arrive is the same season the files themselves peak.

What the Intake Layer Had to Do

As the electronic book grew, HRI needed a repeatable alternative to one-off partner setup. The requirements were the old approach's gaps, written out. An intake point that speaks the SFTP that partner automation already uses. A separate account and folder for every group, so each partner's data stays its own. The ability to meet any partner's mandate, whether PGP encryption, SSH keys, or IP restrictions, without standing up new infrastructure. An API, so provisioning could be code instead of clicks. And handling fit for PHI, under a business associate agreement.

HRI also wanted the partner-facing layer off internal infrastructure entirely, so the connections its trading partners depend on would not be tied to the fate of any one internal system.

“The server we were using was part of one of our business units that sold, so it was a big migration process.”

HRI selected Files.com as that intake layer, with a HIPAA business associate agreement in place from the start, in 2016.

One Pattern, Applied Once Per Partner

Files.com became HRI's healthcare EDI intake hub: a single front door for enrollment data, with the trading-partner pattern applied once per partner.

Partners connect to a branded SFTP endpoint on HRI's own domain. Their schedulers and scripts upload 834 files the way they would upload to any SFTP server, so no partner installs anything or changes how its automation works.

Provisioning is code. HRI built its onboarding process against the Files.com REST API and the .NET SDK, and it has run that way for years: a new vendor group's user account and folder are created programmatically, then HRI applies whatever the partner's policy requires, including an SSH key, an IP whitelist, or GPG keys.

Security mandates are met by linking capability already on the platform. When one EDI vendor's policy required encrypted files, HRI enabled GPG on that partner's folder in Files.com. Files the vendor encrypts are decrypted automatically as they arrive, so the downstream enrollment pipeline never handles encryption itself. When another vendor required SSH key authentication instead of passwords, that was a setting on the account, not a build.

Each partner's folder sends upload notifications on its own interval, within minutes of a file landing, so the team knows enrollment data arrived without watching folders.

Fifty Groups a Day, Onboarded as Configuration

With intake running on Files.com, HRI replaced one-off partner setup with a pattern it applies per partner.

• Onboarding a new vendor group is a configuration exercise done by HRI's own team: an API-provisioned account and folder, plus the partner's required keys, whitelist, and notification settings. A partner's security mandate is no longer a project, and roughly 30 new accounts a year are absorbed without added infrastructure.
• About 50 groups a day deliver 834 files through the same pattern, and the open-enrollment surge, when new accounts and peak file volume land together, runs on the same setup that handles the rest of the year.
• Encrypted exchange became a selling point. HRI has presented it as an option in new-business opportunities as its book grows.

The compounding result is the pattern itself. HRI has added roughly 30 partner accounts a year as more groups move to electronic file transfer, and most connections are partners' automated systems rather than people. Each connection was once a hand-built accommodation waiting to be made. Now each is the same configuration exercise.

Intake That Grows With the Book

Since 2016, what has fundamentally changed at HRI is where growth lands. A new vendor group, or a new mandate from an existing one, used to land on a small team as another hand-built setup on an internal server. Now it lands on Files.com as configuration: the platform already speaks the partner's protocol, holds the keys, and carries the BAA. Open enrollment still arrives every fourth quarter, and the same specialists who process the files can onboard the groups sending them. For a benefits payer whose entire membership arrives as 834 files from systems it does not control, that is the difference between growth that queues behind integration work and growth that gets a folder.