schoutbynacht

It´s not too late, even if Google has discontinued its offering and the status of MS Healthvault is a bit hazy, especially in Norway.

It´s not too early, either. Patience is running out.

The health record (pasientjournal) is a document which serves the needs of the health care professional (HCP). That´s how it came to be, and that´s how it is described in law. When you provide health care, you have to keep a record. It serves both to document your actions and deliberations, and to communicate with the next HCP. It is to a far lesser degree intended for the eyes of the patient. Let´s fast forward to today. While you´re sitting in the waiting room you´re googling the latest info, and most of the time, you are up to speed on the disease and your outlook. The world has changed.

But the health record (including lab results, images etc) are still kept and controlled by the health service. In Norway, where the public purse pays for most, but not all health care, the public sector creates solutions that serve to move records between HCPs, without involving the patient. The newish “kjernejournal” does little to change this. If a major piece of information is missing, you cannot add it without involving your GP.

What´s more, or worse, if you get treated by a private HCP, or abroad, you cannot add information. If you then observe, as most will, that the right hand (AHUS) has no idea what the left hand (OUS) is doing, you have to bridge the gap yourself by acting as a kind of paper-based records service: you carry with you a bunch of print-outs to make sure the different actors are coordinated. You are your own best doctor, patient-coordinator, etc etc. If you have kids: repeat.

The solution is to create a personal health record which is controlled by the patient. Sounds like MS Healthvault, really, and I must find out what the snag is with that.

More likely than not, the rub lies with the law:  you cannot collect information about a person´s health just like that. You need a legal grounding; for instance that you are offering health services as an authorised HCP; in short, you´re a doctor.

So how can someone who´s not offering health services (not-a-doctor) collect health information legally? I do not know yet, but I suspect the key lies with encrypting the data at rest. I will argue that a collection of random 1s and 0s are not health information.
Let´s put the burden of proof on our opponents: give them a few megabytes of encrypted data and make them prove that it is health data. If they can´t, how can they argue that is IS health data?

So here´s the proposal. The architecture comprises three parts:

• Client
• Security Provider
• Health Record Provider

The Client is any application, web or “app” or otherwise. The Security Provider controls who and what gets access to information; this in turn is determined by the user, who may delegate access to others. Further, the Security Provider manages encryption keys. These are used to unlock the information stored by the Health Record Provider. The latter entity is legally separate from the Security Provider, and stores encrypted data that happen to be about a person´s health. The Health Record Provider does not have access to the encryption keys until these are provided by the Security Provider. The Health Record Provider has logic to store incoming information and to transform information for display and export. This means that any information being treated must be decrypted on-the-fly, and exist in-memory in clear-text. As soon as the session ends, the memory is purged and no personal information is available to the Health Record Provider or any of its staff. A sine-qua-non requirement in this context is the requirement that the Health Record Provider never persists the keys it receives from the Security Provider. The key will most likely be symmetric. We could envisage using a number of keys, of course.

Another sticky detail is the fine-grained authorisation of access. This function entails storing information about information, which is in itself information. In order to solve this, the metadata about a given role´s access must in itself be encrypted. One way to solve this would be to associate a given role with a specific key. The couple (role, key)  must be managed by the security provider and stored by it. When a given role is authenticated and routed to the Health Record Provider, the key will unlock metadata such as “Physio record”, and this will in turn be used to filter the information that is stored. In order to avoid having to decrypt the entire record, an index will be stored as part of the metadata, pointing to the relevant parts of the record. An important detail to solve is how to update the index when new information is added to the record, since this might require access to the “Physio”-key and all other keys.

In order to avoid “tapping” of data from the Health Record Provider, the code that this entity runs must be audited and signed, and only the signed code must be possible to run. The auditing must be carried out by a trusted third party, like DNV-GL or similar.

On might argue that this introduces a fourth element in the architecture, namely the software provider. The role of this entity is to provide software that is guaranteed to be “leak-proof”. Beyond this, it must be possible to guard against scanning of the memory of the application.

A lot of tech is required. At the end of the day, the importance of this system lies in its ability to treat information of many kinds, index it (one patient at a time; index must be encrypted also) and make it available in a very granular form to clients. As an example I may want to share my data about my foot with my physio, but not the rest of my record, and to allow the physio to upload relevant information about the treatment. I may also decide that I want to store some biological parameters in the solution and make these, but only these, available to researchers or to a commercial party.

Why go to all this trouble? Chiefly because today´s health service can only scale if we make the patient autonomous, and replace service by self-service, like the banks have done.