Blockchain as distributed EHR metadata / notary

A nice paper about blockchain being used to store EHR metadata which is much more to my taste than the notion of putting whole health records out there.

The idea of using it as a kind of federation/subscription service to encourage distributed backups of health records is also interesting - as long as you have suitable access controls (which should mean strong crypto with a much more strictly controlled key distribution system).

Hi Adrian, how are you? I am interested in the application of Blockchain to the NHS. I can see the immutability side bringing benefits, but I believe Blockchain was designed for distributed systems (pier to pier network). Now I could be completely wrong about this as my knowledge of Blockchain is limited to the few articles that I have read, but does it mean that as the NHS is a more centralised systems (e.g. Spine etc…) that implementing Blockchain technologies would be more difficult in the NHS, than for example in it’s use in financial transactions? If you could point me to any really good articles on Blockchain I would appreciate. I’m trying to stay ahead of the curve, as in my day job I am so focused on HL7 FHIR messages, that I may not be ready for what might be coming round the corner, if you see what I mean. BTW, it was Rik Smithies from HL7 UK, that recommended to get in touch, he said you had posted some interesting topics on Blockchain forum. All the best @johntq2

Hey John, sorry, not been hanging around here as much.

So, blockchain gets a lot of hype. A lot of the benefits - like immutability - are things you can arrange without the peer to peer network.

The core feature of blockchain as it’s presented in cryptocurrencies like Bitcoin is consensus (peers voting as to whether a given transaction is legit based on the prior record). Which (IMHO) is not largely required in medical records, with one notable exception, and that’s timestamps.

You can engage a digital notary service to provide you with verified timestamps (essentially you provide a hash derived from the record you are generating and they tack a timestamp onto it and sign it), but it seems a good fit for something that a lot of parties need and can form consensus on - that they did see a record submitted to the chain at such and such a time, enabling a concrete real-world timestamp to be established for the record.

It’s not required for things like e.g. non-repudiation of records. You can sign records with a private key you control, and no-one is going to dispute that your key signed those records.