Blockchain in Heathcare – are standards needed?
Posted on by Grahame Grieve
Last weekend, in the lead in to HIMSS in Las Vegas, several of the FHIR team met with a number of block chain specialists, most particularly including David Huseby from the Hyperledger project at the Linux Foundation. We discussed various use cases for use of blockchain, with the intent of understanding what – if anything – HL7 should do to support blockchain adoption through the standards process. During an open and wide-ranging discussion, several of us came to the following consensus about the use of blockchain in healthcare (and we thank David greatly for his assistance).Legal Assurance on Audit Trail
The first use case we recognised where blockchain has an obvious and appropriate usage is to provide strong legal assurance that an audit trail has not be tampered with. There’s all sorts of functions that a healthcare provider carries out where they may eventually be asked to provide evidence concerning past actions, and where there is a need to demonstrate that the audit trail has not been tampered with – and that includes against tampering by the system administrators themselves (that’s a very real concern – highly authorised insiders are the most likely attackers on the audit trail). If the audit trail is kept in electronic form, the only IT resource I know of that is proof against this level of attack is a distributed block chain where the system administrators don’t have total control of all the nodes.
There’s any number of compelling use cases for this in healthcare:
- Compliance with GPDR removal-of-data requests
- Keeping records around infection control
- Keeping records involving cases of sexual abuse or other criminal behavior
- etc
In fact, given how compelling this use case, it’s surprising that there isn’t commercial escrow type services simply hosting blockchains as a business service (at least, we didn’t know of any such service). It’s something that should be pretty easy to turn into a commodity using something like hyperledger, and there are strong reasons for healthcare providers to pay attention to storing these kinds of records really well.
Of course, this use of block chain is hardly scratching the surface of what block chain can do.
Need for Legally Established Trust
There’s lots of proposals floating around for using blockchain to create new trust arrangements. But whenever we considered actual use cases, we kept finding that in healthcare, any sharing of information, or delegation of trust or responsibility from one party to another starts in a closed regulated system, loaded with legal liability etc. You can’t begin to share information until you’ve established the legal basis for trust by contract – legal agreements and business agreements. And once you’ve established all those agreements, you don’t actually need a block chain – you can just have a central managed database by some consortium or foundation that acts on behalf of it’s members. This is a classic well established pattern in healthcare (see under Commonwell and Carequality – there are many others).
So, in practice, the need for legally established trust in a closed system turns out to mean that many of the proposed uses for blockchain involve quite a lot of hype.
But not all of them. For a start, while you’re going through the negotiations to set up such a consortium agreement, the fact that all the information associated with the agreements will be provably shared amongst all the participants can make it much easier to set up agreements that involve potential commercial benefit to one advantaged player… and I’ve seen several otherwise very useful initiatives flounder on this point.
And given my first law of interoperability – it’s all about the people – that means that blockchain turns out to be potentially pretty useful for interoperability after all, as a tool for changing how people think.
In fact, even just mentioning blockchain right now gets people’s attention – that’s a clear use case for using it, even when there’s no technical merit to the use of block chain directly.
Clinical Credential Tracking
We did discuss one very specific use of a public blockchain where it appears to be very useful – clinical credential tracking in USA. So it was somewhat ironic to see this headlines in USA Today today:
Prescription for Secrecy! USA Today – Dated - March 7, 2018
Standards Support for Blockchain
The upshot of all this is that it’s not at all clear that there’s any need for HL7 to work on blockchain related standards. We’re mainly going to sit back and watch this space and observe to see whether any compelling use case for standardization emerges – because it hasn’t yet (a compelling use case for standardization needs much more than just a compelling business use case for use of blockchain). But we are going to investigate 2 things:
- Is there anything useful we should do about creating standard ways to create function specific audit trails from FHIR resources/bundles or CDA documents?
- Should HL7 work on data and format standards to support clinical credential tracking (including, is this a real problem – we didn’t have consensus on this). Also, there are already communities working on it, and so we’d need to reach out to them to see whether formal standards support is useful for them
Here is the link:
http://www.healthintersections.com.au/?p=2778
If you have any views please post a comment on Grahame's blog or here.
David.
4 comments:
My Health Record and assorted infrastructure are Federal Government. Government infrastructure must be ASD ISM certified. Anyone know if the adoption of block chain would cause any issues? I am not questioning the technology just interested if it could be used.
It is incorrect to say that Government infrastructure must be ASD ISM certified.
ASD do not certify anything, they provide guidelines and policy. In the case of Information Systems these are the mandatory requirements
https://www.protectivesecurity.gov.au/informationsecurity/Pages/Information-security-core-policy.aspx
The Government never claims that myhr is certified, it only ever talks about risk and policy e.g. "the My Health Record system is maintained and risks managed in accordance with Australian Government security policies defined in the
Information Security Manual (ISM) and Protective Security Policy Framework (PSPF)."
It is the responsibility of the Departmental Secretary to enforce the policies and guidelines - they sign off on the risk and they are responsible and accountable. If they wish to use blockchain technology they need to assess the risk against the nature of the information.
IMHO, it would depend on how the blockchain technology was used, not the technology itself.
Thank you Bernard, another myth busters. I was under the impression because of the nature of the system and the type of information it contains it would have to be subject to pretty strict and enforced controls.
It is a common misconception that government systems (even those in Defence, LEA and security agencies) have to be "certified". The Australian Constitution gives responsibility and accountability to portfolio ministers, not to the government. Government is a convention not a constitutional entity. This means that government cannot insist that IT systems must be certified. Apart from the expense that would be involved if a body such as ASD had to assess every IT system and ensure it meets the ISM/PSM guidelines. So they don't.
Ministers can devolve decisions to their departmental secretaries and in some cases the departmental secretaries can devolve these to computers.
For example this is a quote from the current eHealth legislation
"13A System Operator may arrange for use of computer programs to make decisions
(1) The System Operator may arrange for the use, under the System Operator’s control, of computer programs for any purposes for which the System Operator may make decisions under this Act.
(2) A decision made by the operation of a computer program under an arrangement made under subsection (1) is taken to be a decision made by the System Operator."
If you are wondering who the System Operator is:
"14 Identity of the System Operator
(1) The System Operator is:
(a) the Secretary of the Department; or
(b) if a body established by a law of the Commonwealth is prescribed by the regulations to be the System Operator—that body."
In other words, it was the Secretary of the department of Health it is now ADHA.
BTW, the whole Centrelink Robodebt fiasco was caused by mismatches between ATO and Centrelink data; that data being used by computers to make decisions that were also enabled by this type of legislation.
Post a Comment