In this article
Ask most software vendors about HIPAA or GDPR and you get a list: encryption at rest, encryption in transit, access controls, audit logs. All of it is necessary. But the list skips the question that comes one step earlier, which is whether the product needs the sensitive data at all.
Protected health information your system never collects cannot leak, cannot be breached, cannot be subpoenaed and does not need an audit trail. Several health products in our case studies were designed to work without any of it. This article describes the method we use to get there, and what to do when the sensitive data really is the product.
What counts as PHI
Under HIPAA, protected health information is health data that can be linked to an individual. The link is the deciding factor. A blood pressure reading on its own is not PHI. The same reading attached to a name, a date of birth, a device serial number or an IP address is. GDPR treats health data as a special category on similar grounds. So the design question is not "do we handle health data" but "can the health data we handle be tied to a person", and architecture can answer that question.
We are engineers, not compliance counsel. The method below makes your lawyer's checklist much easier to satisfy, but the final determination belongs to them.
Make every field justify itself
During discovery we list every piece of data the product wants to store and ask three questions about each one.
- Which feature needs this data? If nobody can name one, it goes.
- Would a less identifying version do? A region instead of an address, an age band instead of a birth date, a pseudonym instead of a name.
- Where does the computation have to happen? If the phone can produce the answer, the server never needs the inputs.
Done properly, this removes most identifying data from most health products before any code is written. Four examples from our own work follow.
Four products, four ways to leave PHI out
A clinical calculator that never learns who the patient is
The clinical device sizing app helps medical professionals choose device sizes from anatomical measurements. The obvious design stores a patient record so the clinician can come back to it. Instead, the app takes anonymous measurements, runs the sizing logic on the device and shows the result. Nothing identifying is entered, so nothing identifying can be stored. The calculation logic lives in pure functions tested against the specification, because a sizing error in a clinical tool is a serious matter.
A wellness community on pseudonyms
A community wellness platform needs progress tracking, groups and leaderboards, which sounds like it needs real identities. It does not. Members choose a display name, activity totals are stored against an internal identifier, and the only link to a real person is the login credential, which lives in a separate authentication service. Diagnoses and medical history were never in the data model because no feature needed them. A breach of the activity database would expose step counts attached to nicknames.
A price comparison tool that needs a location, not an identity
The medication price comparison app answers one question: where nearby is this drug cheapest? To answer it the app needs a location and a drug name. It does not need to know who is asking, what they were prescribed or who insures them, so it collects none of that. Searches are not tied to accounts. Coupons work the same way: the coupon is a code the pharmacy redeems, not a record linked to a person.
Document intelligence that masks before it reasons
AI in healthcare workflows raises a sharper version of the same problem, because whatever you send to a language model leaves your control. Our rule is that identifying fields are masked or removed before any document reaches a model, retrieval is limited to what the current user may see, and a person reviews the output by default. The model gets the structure of the document and never the identity of the patient.
When sensitive data is the product
Sometimes the sensitive data is the product itself: member records in a medical association platform, health logs in a monitoring tool, documents in a clinical system. Then there is no architectural shortcut, and the standard controls have to be done properly.
- Encryption in transit and at rest, with keys managed outside the application.
- Role-based access enforced at the database layer, not only in the interface, so a bug in a screen cannot widen access.
- Audit logging of every access, with enough context to answer who saw a record and when.
- Explicit retention periods, so data has a defined end of life instead of accumulating forever.
- Payment handling offloaded to a PCI-compliant gateway, so financial data never enters application memory.
- Data minimisation even here. A member directory needs a verified professional identity. It does not need anyone's patient data, and the schema should make that impossible rather than merely unlikely.
Three habits that keep the surface small
Separate identity from activity. Keep the table that knows who a person is apart from the tables that know what they did, joined only by an opaque identifier. Most features never need the join.
Prefer computation on the device. Phones are powerful. If the result can be computed locally, the server never sees the inputs, and the privacy story becomes "we do not have it".
Let the schema be the policy. A field that does not exist cannot be collected by a well-meaning future feature. Policies written in documents drift. Schemas do not.
What this means for your project
If you are planning a health product, the most valuable hour of discovery is the one spent deciding what not to collect. It lowers compliance cost, reduces breach risk and often simplifies the product. Our healthcare software development page describes the work in more detail. If you already have a data model and want a second opinion, send it over and we will tell you what we would remove.