OpenLoop Health Replaces Per-Client AWS S3 Buckets With a Files.com Portal for PHI Intake

OpenLoop Health runs the machinery behind other organizations' telehealth. Clients bring the brand; OpenLoop supplies the clinicians, the compliance operations, and the technology to deliver virtual care programs. Its employer clients use those programs to offer telehealth to their workforces.

The employer side of that business has a fixed opening move. An employer signs on to offer telehealth to its workforce, and the first thing it sends OpenLoop is an employee roster: names and email addresses, personal data carrying HIPAA obligations, so OpenLoop can reach those employees with health program outreach. Every new employer relationship begins with sensitive data crossing into OpenLoop's hands. And OpenLoop had no purpose-built place to receive it.

A Hand-Built S3 Bucket for Every Sensitive Exchange

OpenLoop is cloud-native and AWS-first, and before Files.com it had no managed file transfer capability at all. When an outside party needed to exchange files, IT built the exchange by hand: a fresh AWS S3 bucket for that one counterparty, with its own credentials and access setup, assembled per case and maintained per case.

“We've been doing very manual AWS S3 bucket setups for having external users, and end users don't really like it because it's not graphical and pretty.”

The heavier cost landed on the client side of the exchange. The person sending a roster is an HR contact at an employer, not a cloud engineer. Raw S3 gave that person no page to log into and nothing that looked like OpenLoop. Reaching a single file meant clicking through several different AWS services.

The gap was structural, not a matter of better bucket hygiene. Raw object storage is not a client-facing exchange surface. It has no web experience an outsider can use and no simple external-account model. Nothing in it naturally fences one client's data from another's, and building all of that on top of AWS would have meant standing up and maintaining a portal layer, with HIPAA controls, for a workflow that repeats with every new client. The identity problem split in two on top of it: OpenLoop's staff live in Okta, and a client's HR contact never will.

While external exchange stayed rare, the workaround was survivable. Then the files it carried became the most sensitive kind the business touches, and the situations stopped being rare.

“I've been here since January, and I think it's come up twice now where we have a potential client or a current client that needs to exchange sensitive information with us, whether it's an employee roster or other data that's riddled with PII and PHI.”

Employer Onboarding Starts With a File Full of PHI

As OpenLoop added employer clients, each new relationship created another secure exchange relationship. A per-case infrastructure build could not be the way each of those relationships opened.

What the fix had to do was clear before any product entered the picture. Each client needed its own space to drop files into and retrieve files from, sealed off from every other client's data. The experience had to be a simple web page an outsider could use, under OpenLoop's own name rather than a cloud vendor's console. Internal users had to come from Okta automatically, while external client accounts had to be creatable on demand without touching the directory. All of it had to hold PII and PHI under HIPAA.

OpenLoop selected Files.com to be that exchange layer.

One Fenced Folder per Client, Under OpenLoop's Own Domain

Files.com became OpenLoop's standing front door for client data: one governed surface where every employer client has a walled space of its own.

Isolation is the foundation. Each client gets a dedicated folder to drop company-specific files into, and Files.com permission fences keep every client's data apart from every other's. A client sees its own folder and nothing else. That per-client isolation is the control that let OpenLoop accept PHI-laden rosters at all, and the exchange runs both ways: a client drops a file in, or OpenLoop places a file there for the client to retrieve.

The surface belongs to OpenLoop. The portal runs on a custom domain with OpenLoop's branding, so the page a client contact opens carries the name of the company they signed a contract with. Sending a roster means logging into a web page and dropping a file. No AWS account, no console, no cloud knowledge required.

Identity splits cleanly down the middle. Internal users are provisioned automatically from Okta through SAML single sign-on and Files.com's SCIM provisioning: accounts are created from the directory, group memberships are pushed from Okta, and the folder permissions mapped to those groups follow along. External client contacts get local Files.com accounts with two-factor authentication instead, activated for a transfer and disabled within 30 days.

The whole pattern is written down. Creating either account type is a documented runbook the help desk executes on request, which is what turns a security architecture into an onboarding process.

A New Client's First File No Longer Waits on IT

With the portal in production, OpenLoop replaced a per-client infrastructure project with a repeatable intake pattern. Onboarding the next employer client is a folder, a group, and a credential. The help desk works it from a runbook, and IT no longer builds infrastructure to receive a file.

A new client's first file no longer waits on IT. Every future client lands on a pattern that already exists, so the exchange layer absorbs OpenLoop's client growth without adding engineering work per relationship.

The Job Raw Storage Was Never Built to Do

Today, the opening move of a new employer relationship looks different at the doorstep. It used to begin with an engineer hand-assembling an S3 bucket and an HR contact clicking through unfamiliar AWS services to find one file. Now it begins with a login page carrying OpenLoop's name and a folder that belongs to that client alone, with the isolation and the account lifecycle decided before the first byte arrives.

OpenLoop is still a cloud-native, AWS-first company. What it stopped doing is asking a raw storage bucket to be a client-facing product. Files.com took that job: the governed front door where regulated data enters the business, built once and reused for every client that follows.