I have updated my proof-of-concept project on pseudonymous consent (see github). To understand the background to this blog post, please see my earlier post.

The design goals were

  • Put patients in control of their information
  • Support explicit opt-in for research and opt-out for clinical services.
  • Avoid leaking confidential information while information is in transit or in storage.

The key to linking information in a safe way is the use of pseudonymous identifiers.

The following schematic shows the updated model:

Openconsent Model Updated

A patient can create an account at any time using their email. Potentially, this account could be validated by some external agency such as the Government Gateway or new Gov.uk VERIFY services.

Opt-in projects

To join a research project, we create an explicit “Registration” for that patient. A research project creates an “Episode” and, given it is an explicit opt-in type of project, data access would only be permitted if explicit consent exists. This is straightforward but the design ensures that the system cannot re-identify the patient. A project needs to obtain patient identifiable information via a different route.

Opt-out projects

But what if I want to write a new “intelligent agent” that will monitor patients, look for patients on methotrexate and then check that they have had their required blood monitoring and that the blood results are within the ranges we expect? Methotrexate can cause blood dyscrasias and so needs regular blood monitoring. I want the care I provide to patients to run on rails so how can I introduce an application that accesses patients’ records in a safe way that is defensible in regard to information governance and the media? I really don’t wish to be on the front page of the newspapers!

The steps are as so:

  1. To access patient data, the project (in this case my methotrexate monitoring application), registers an episode using the known patient identifiers. It is acting on behalf of an NHS organisation.
  2. The “system” permits access to health data as this is an opt-out project, but data access is logged in a verifiable log.
  3. A patient wishes to opt-out. They already have a validated account. It has been endorsed and linked to the authority that oversees the project.
  4. The patient (and only the patient) can then look up all episodes relating to him or herself and explicitly opt-out by recording that information against the episode. This change would be logged in a verifiable log as previously discussed.
  5. For the project, data access is no longer permitted.

The critical features are:

  • the avoidance of information leakage; making inferences about the patient simply as a result of the opt-in and opt-out of projects.
  • providing some degree of proof of trustworthiness in that the above logic could be distributed across multiple systems and we can vouch that patient information cannot be shared inappropriately and without being logged.
  • ensuring that even insiders cannot find out more information about a patient than they should. A project cannot find out what else the patient has consented for and likewise, an attacker of the patient accounts cannot find out to which projects the patient has opted-in or out of.

There is more work to do to make it a usable system, but the test harness demonstrates how it would work in practice.