If your organization asks people to send in medical documents, and you collect them through a web form, a shared folder link, or email, you have a compliance problem. Probably a serious one.
This comes up constantly with clinics, nonprofits, and any practice that reviews records as part of its work. The intent is never careless. The tooling is just wrong for the job, and the risk is invisible until it is not.
What counts as protected health information
Protected health information is broader than most people assume. It is not only a diagnosis. It is any health information that can be tied to an individual, which in practice includes treatment records, test results, and often the simple fact that a named person contacted a healthcare provider at all.
So a contact form that says “describe your symptoms” and emails the response to a staff inbox is already handling PHI, whether or not anyone thought of it that way.
Three things that are not compliant, no matter how careful you are
A public file-share link. Anyone with the URL can reach it. There is no access control, no reliable encryption guarantee, and no record of who opened what. If the link leaks, you cannot tell whether anything was taken.
Email attachments. Standard email is not encrypted end to end, copies persist on servers you do not control, and a mistyped address is unrecoverable. Email is a fine way to tell someone a document arrived. It is not a way to move the document.
An ordinary form that uploads to your web server. This is the one that catches good developers. The files land on the same machine that serves your public website. Now every vulnerability in your public site is also a vulnerability in your medical records.
The pattern that works: receive without reading
The design rule we use is that the website can receive documents but can never read them.
In practice, the browser asks your server for permission to upload. Your server validates the request and returns a short-lived, tightly scoped permit, without ever seeing file content. The browser then sends the file directly into encrypted storage, bypassing your web server entirely.
The security property this buys is unusually strong. Because the document bytes never pass through the public website, a total compromise of that website still exposes zero records. There is nothing there to steal. You are not relying on your web application being free of bugs, which is not a promise anyone can honestly make.
Details that decide whether it actually holds
Bind the limits into the permit, not the browser. A permit that carries a maximum file size means storage itself rejects oversized uploads. If you only check size in the browser, you are trusting a number that an attacker controls. Test this by declaring a small size and then deliberately sending something much larger. Storage should refuse it.
Generate identifiers on the server. If the browser supplies the submission ID, and IDs appear in upload permits, then anyone who observes one can request permission to write into someone else’s folder. Server-generated identifiers close that path.
Keep PHI out of notifications. Staff should be alerted that a submission arrived. The alert should not contain the contents, the diagnosis, or a direct download link. Notification systems get forwarded, archived, and indexed in ways you will not anticipate.
Get a Business Associate Agreement. A cloud provider being capable of HIPAA compliance is not the same as you being covered. Specific services are eligible, and a signed BAA has to be in place. Using an ineligible service inside your PHI path voids the arrangement no matter how well built the rest is.
Log access and keep the logs. When something goes wrong, the question is who accessed what and when. That answer has to exist months later, which means retention has to be deliberate.
Keep the dependency list short
On a recent build of exactly this kind, the production dependency count was eight. No CMS, no ORM, no UI component framework. Everything touching PHI was either an official cloud SDK or a focused cryptography library.
That is not minimalism for its own sake. Every dependency in the PHI path is code you are responsible for and cannot fully audit. A small surface is a security property when the data is medical records.
What this costs
More than a normal website and less than people fear. The architecture is not exotic. It is a specific set of decisions applied consistently, plus the discipline to keep the sensitive path narrow.
What it is not is something to retrofit casually. Compliance is a property of the design, not a feature bolted on afterward, which is why this kind of work gets scoped and quoted rather than sold from a menu.
If you are collecting medical documents today through a form, a folder link, or an inbox, treat it as urgent. The exposure is real and it grows with every submission.