The Cameron government has re-opened the debate on how much of our patient data is accessible to others who are not directly caring for us. Dame Fiona Caldicott has been tasked with the review and was just quoted as having been influenced by the NHS’ Future Forum question “where does the balance between privacy and sharing lie?”.

Whilst many a conference and report on health data sharing has concluded with the same question, it is actually the case that we need not resort to such a desperate last measure. It would be a truly dismal world if for the health economy to grow a patient’s trust in their health data needs to suffer. This is clearly an idea of “last resort”.

The reader will be pleasantly surprised to learn that in fact there is no need to sip from that poisoned chalice.

It turns out such “last resort” thinking is a product of staring at shared database designs (e.g. safe havens, shared warehouse, trusted data linking services etc). Having picked this way to solve the problem one finds oneself marched quickly to the aforementioned iniquitous balance. (“Do patients or the health economy matter more?”)

If instead one asks the question “how can we find potential research subjects whilst preserving patient privacy?” (say) then the floor is opened to more palatable solutions. In this case the patient qualifying criteria are sent to GP computers whose GP’s can then choose whether to contact their matching patients or not. Patients always have rights of refusal.

Now imagine the poor soul who simply copies a system design from Banking and wants to build a database to find research subjects. This now needs to include everyone to ensure all rare characteristics are included (and some would argue to be unbiased). All UK patients! Lickety spit we are right back at the “balance question”.

That projects like the Research Capability Programme (now CPRD?) or Predictive Analytics for Commissioners (calling on new safe havens) hit the same “balance” question is not surprising. It also doesn’t mean the question needs answering either!

What is called for (and I respectfully call out to Dame Caldicott to take note) is focused attention on how individual projects can get just the data they need. Some guiding principles that always help simplify matters:

1) Supply the least information that answers the question (“zero knowledge” techniques included)
2) Ensure the least number of people have access to the data for the smallest period of time
3) Patients always get quibble-free opt outs
4) De-identify the data when extracting from its “home” base (part of 1. above)
5) Attempt to measure the illicit re-identification risk to patients of each project

This kind of scheme makes it easy to seek patient or physician consent that is meaningful because the purpose for collecting is singular and well understood (As are the names of staff accessing the data). Sometimes it also justifies opt-out if the re-identification risks are measurably low enough.

The future is bright, let’s not get bogged down in questions of “balance” when better paths exist that protect patients AND help grow the health economy.

Historical product information. This read-only website does not operate the pseudonymisation service, accept uploads, process data or take payments. The instructions and offers below describe the former service.

March 2012 – Sapior has launched a self service way to de-identify or pseudonymise sensitive data via its cloud servers.

Responding to requests to keep costs low, Sapior has launched a new service for users with sensitive data to initiate the de-identification process themselves. Once the CSV file has been selected, it is encrypted and then uploaded to Sapior. Once the file has been pseudonymised and the fields formatted back into a usable form, the user is emailed and able to download. Costs are dependent on job complexity with 2 free jobs to help assess suitability. Java is required to use this service (see java.com).

The self-service pseudo is built upon the Sapior zero-breach-risk eTTP platform. As such Sapior manages all the user salts/keys and is never able to view a single byte of unencrypted data and is therefore unable to breach the privacy of that data. This means there is no need to enter into a data sharing agreement (under the DPA’98) prior to using the service.

Unlike competitive offerings Sapior’s cloud service manages all secret salts and keys. The user is never expected to manage keys in order to get secure or linkable data. Data de-identified with the same account will be linkable across different data sets. Take comfort that Sapior’s research and development prevents you from falling into the most serious security traps and improve your productivity with our unparalleled ease of use.

Your search for a secure data de-identification and linking service is over! Try it today by clicking here.