Patient Hashes for Compression and Security

Question

Are there any front-running approaches to using server-generated hashes to encapsulate patient condition in a concise manner while maximizing security?

For example, a system to represent current med profile in a hash that can be used to check for contraindications without revealing the specific component prescriptions?

Answer 1

There is a fundamental flaw in the kind of setup you suggest, which is that it is intrinsically vulnerable to informed guesswork. By sending targeted requests, it would be possible to narrow down the number of possible conditions quite quickly; this is the very same process that lies behind medical diagnosis itself.

There is an active research area about working with encrypted databases, such that you can obtain some partial information on the data without being able to decrypt it. However, partial information can be very revealing. For instance, if you have an encrypted number x and can ask questions such as "is x greater than 1000 ?" then a dichotomic search will reveal x with a high precision within a few dozen requests.

This means that the security model which is envisioned here (the physician is the potential attacker) is a rather hopeless setup. (Also, it makes relatively little practical sense: physicians need to know all of the medical history of their patients in order to do their work properly.)

A distinct model is what homomorphic encryption is about: the ability to compute things over encrypted data, such that you get an encrypted result. This is useful to offload the most of the computation work to a powerful but untrusted system. But whoever can obtain the decrypted result has the power to decrypt all the stored data, by construction; so this is not the same model.

Answer 2

Hashing would not be very practical in this case. Not because of collisions, since a good cryptographically secure hash (e.g. SHA-2) won't have any collisions that can occur in the wild with any reasonable probability. The problem is that hashes are one-way, so in order to deduce your conditions all possible combinations must be hashed and compared to your hash.

A more interesting approach would be to use homomorphic crypto. Homomorphic crypto allows you to make some classes of computations on encrypted data, e.g. computing averages and similar. Microsoft Research has developed a very promising approach in this paper by .

Answer 3

None that I know of. And I believe this is because.. I don't think the solution (implied by the question) is a good solution/proposal.

Not only because hashing function may have collisions (even if it has a very low probability, the impact would be major, so why should we add such a risk ?) but also because you have another problem prior to hashing: unless you solve something that has not yet been fully solved (i.e. semantic interoperability), in a med profile you can -for instance- find/formulate the very same medical concept in several different ways (i.e. different text sequences may mean the same thing/medical concept) so in those cases you would get different hashes referring to the same concept (!) . How would you manage that ? Will you be able to map all those different hashes to the same medical concept ? (type of allergy or whatever). How would you say that two hashes really mean two different things.. and which things should they be ?. I believe you won't be able to predict all the possible different ways in our language we could express the same concept and the resulting hashing values will be severely flowed in semantic terms.

Even if you choose to use the best terminologies and controlled vocabularies or coded information to be used in the med profile, they will still need continued maintenance and revision over time (because of versioning etc. e.g. aliases, new concept in, deprecated concepts out etc.) all things that will impact severly on the effectiveness and reliability of your "decision support system" based on concepts hided by hashes values. So I don't think it is a good idea to hide a medical concept behind hashes and taking decisions based only on the hashes values.

Besides, if I authorize my Doctor to access my medical record, I want him to see it very clearly what my allergy is in terms he can understand. Can you imagine your Doctor watching hashing values supposed to be mapped vs. some medical coded information having absolutely no way to really verify the real concept that may be behind ? Not a good idea. You want compression ? Use compression algorythms. You want security ? User encryption with two ways functions and authentication infrastructure etc. (keep in mind that hashing is a "one-way" function). Just keep using hashing for those things we use them today (to index, retrieve items more efficiently, for digital signatures etc.) NOT to hide/store medical concepts. I would not innovate this way. But may be I am wrong. Is there a better answer to this?