Consent and access logs in a health platform

Health data platforms get privacy wrong in a predictable way. The team builds the product, writes a privacy policy to describe it, and then discovers that the policy promises things the code cannot do. On CardioMood and in our work with Corsano Health we did it the other way around: consent, roles, logging and deletion were built in the first week, and the policy was written afterwards to describe what the code already did. This is what each of those pieces looks like in practice.

What the law asks of the code

Under GDPR, data about a person’s health is special-category data. Processing it needs a lawful basis, and in a consumer product that basis is almost always explicit consent, which has to be specific, informed, freely given and as easy to withdraw as it was to give. The person also has rights to see what is held about them, to get a copy, to have it corrected and to have it erased.

Under HIPAA, the same data is protected health information when it is held by or on behalf of a covered entity such as a clinic. The rules are about safeguards, access controls, audit logs and the business associate agreement that binds a software vendor to the same standard. A platform that serves a coaching company in Europe and a clinic in the United States has to satisfy both, and the engineering overlap is large: know what you hold, know who touched it, let the person see both, and be able to delete it.

The way to satisfy both is to make each of those a function the code can execute rather than a sentence in a policy.

Consent as a versioned record

Consent is a table. Each row records the person, the version of the consent text they saw, the purposes they agreed to, the timestamp and the channel. When the text changes, the version changes, and users who agreed to an older version are asked again before the new purpose is used.

The app then behaves differently depending on the rows. A person who has agreed to share data with a coach has a coach who can see it. A person who has not, or who has withdrawn, has a coach who sees nothing from that moment. A person who has declined optional analytics has their records excluded from the analytics pipeline at the source, by a flag the pipeline checks, rather than by a filter someone remembers to apply. Consent that does not reach the code paths is a promise the product cannot keep.

Withdrawal is a row too, with its own timestamp, and nothing is deleted when it happens. The record of what was agreed and when is itself something the person and a regulator may ask to see.

Roles and what each can see

The role model is the part that gets rebuilt late if it is not built early. In a coaching platform there are at least four roles. The client owns their data and sees all of it. The coach sees the clients who have granted access, and only the views the product has defined for a coach, which are summaries, baselines and alerts rather than raw signals. A clinic is a group of professionals with an administrator, where access follows a care relationship and a patient may be seen by several people. The platform admin can operate the system and should see as little personal data as the job allows, with a break-glass path that is logged loudly.

Every read goes through one authorisation layer that answers the question “may this role see this field of this person right now”. A coach whom the client revoked yesterday gets nothing today, including from cached views and exports. Reports and exports are the common leak, because they are built later by someone who forgot the rule.

An access log the user can read

Every read of a person’s data by anyone other than the person is logged with who, what, when and from where. Auditors want that log, and so does the user. We show it in the app, in plain language: your coach viewed your sleep summary on Tuesday, a support engineer opened your account on Friday under a named ticket.

A readable access log changes behaviour on both sides. Staff who know that a person can see their name next to a read are careful about what they open. Users who can see exactly who looked trust the platform more than any policy would make them. And when the question “who saw my data” arrives, the answer is a screen rather than a week of database archaeology.

Data minimisation

The platform keeps what the product needs and nothing else. Raw optical signals are large and are rarely needed once beat intervals have been extracted. If no feature uses them, the pipeline does not store them, and the question never arises of who may see them. Location is a common example in the other direction: the app may hold it because of Bluetooth permissions, the product has no use for it, so it is never sent.

Minimisation also applies to copies. Each place data is duplicated, from a search index to a data warehouse to a vendor’s analytics tool, is a place that deletion and access control have to reach. Fewer copies make every other obligation smaller.

Deletion that reaches everything

Erasure is a function, and it is tested. When a person asks for deletion, the function removes their records from the primary store, from every derived store, from the analytics warehouse and from the search index, and it records that it did so. Third-party processors receive a deletion request through their API, and the function waits for confirmation.

Backups are the hard part. A backup that can be restored will restore the deleted person. The usual answer is to keep backups for a short, documented retention period and to keep a deletion ledger that is replayed after any restore, so a restored copy is cleaned before it serves traffic. The other option, encrypting each person’s data under a per-person key and destroying the key on erasure, works well for new systems and is harder to retrofit.

A deletion that does not reach backups is a deletion the company cannot truthfully describe in its policy.

Audit trails for a regulated device’s software

Software that runs around a CE-MDR or FDA cleared device lives inside the manufacturer’s quality system. That means a documented record of what changed in the software, why, who reviewed it, how it was tested and when it was released. Each change ties to a requirement, and each release ties to a set of verification results. The access log and the consent table above are part of the same discipline: they are evidence that the system behaves as its documentation says it does.

This is a habit as much as a toolset. Pull requests reference the requirement they serve. Test results are kept rather than regenerated. A release has a signed-off list of what went into it. None of it is heavy once it is routine, and all of it is painful when a notified body asks for it and it has to be reconstructed.

Why this is a first-week decision

Each of these pieces is a few days of work at the start of a project. The consent table is a schema and two screens. The authorisation layer is one module that every query passes through. The access log is a write on every read path. Deletion is one function and a test.

Added later, each one is a rewrite. Data has been copied to places nobody listed. Reads happen through a dozen paths that each need the check added. Consent was a checkbox with no version, so nobody knows which users agreed to which text. The product has to be taken apart to find out what it holds.

If you are starting a health product and want consent, roles and deletion designed before the first user signs up, the wearables and health tech page covers what we build, and you can write to us about your platform.