Monthly Archives: March 2018

Blockchain in Heathcare – are standards needed?

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

Technically, this is a really unchallenging use of blockchain – the head that creates blocks is completely trusted, so there’s no need for any form of voting/contest creating new blocks (e.g. no energy penalty cost for mining). And the audit trail only needs to contain encrypted copies of the actual records (or, alternatively, hash values for the records, though this introduces uncertainty around keeping hash methods constant over a period potentially spanning decades – though simply encrypting the records just moves the instability of system/version rot around). All the institution needs is one or more partners that can support the blockchain – it can be either private or public.

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:


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

Comments welcome….

Should you use #FHIR resources as your storage format?

In discussions with implementers, one question that has come up quite a lot recently is whether you should store FHIR resources natively in your database or not.

In principle, FHIR resources (like all HL7 specifications) are designed for exchange between systems, rather than as a database storage format. That doesn’t mean that we won’t consider utility or design requests intended to meet storage use cases, just that we will always prioritise design priorities around robust exchange.  One practical consequence of this is that FHIR resources are highly denormalised, so that granular exchanges are fairly stand alone.

To illustrate this, consider using an RxNorm code as a medication code. In a prescription resource (MedicationRequest), that will look like this:

<MedicationRequest xmlns="">
     <system value=""/>
     <value value=""/>

If we were prioritizing storage efficiency, we would normalise this so that the code was just some primary key reference:

<MedicationRequest xmlns="">
  <code key="123431232"/>

..well, we probably would do that. Whether to normalise or not is an engineering design question that has multiple different considerations, and very often product designers change their decision about this for engineering reasons with no associated change in functionality or requirements.

When designing exchange formats, on the other hand, you almost always end up choosing robustness and stability over efficiency. Using a key reference like the second example would require all the participants in an exchange to synchronize the key… often not possible, and rarely stable. Not always, but most of the time, and we choose reference points after considerable discussion about reliability. Performance considerations come a distant second.

Engineering Considerations

So you might immediately assume that it would always be a mistake to store resources natively, but that’s not always the case.

Many implementers assume that a general purpose REST based implementation stack will always be less efficient, reliable and manageable than a purpose built application stack… but there’s some pretty awesome stacks for handling generic resources out there, with deep support for application development – code generation, UI binding, management reporting… so it’s no longer a given that you can do a better engineering job than just storing the resources directly.

I’ve seen implementers storing resources natively in:

  • classic SQL servers with JSON support
  • NoSQL servers like Mongodb / Couch etc (or Hadoop)
  • Google’s Big Query
  • Some RDF based store using the RDF in the turtle format

So if you can consider something like this for your storage, you can consider storing resources natively. If you can’t… then you won’t be asking the question.

But just because you can doesn’t mean you should.


The most important determinate of whether you should store resources natively is about your requirements.

If your information requirements are nailed down: well understood, clearly expressed, and not subject to uncontrolled change – then you can easily design a data storage schema that is completely fit for purpose and magically efficient compared to storing FHIR resources. Classic Enterprise Information Systems tend to behave like this.

If, on the other hand, your information requirements are not at all nailed down, and you have to deal with whatever comes, and you only find out what’s coming on an ongoing basis – then FHIR resources are actually a very sound way to store your data – the extensibility approach makes FHIR a particularly robust choice. In fact, FHIR might already be your best choice outright. Clinical Data Repositories tend to behave like this.

The really interesting thing, though, is that every information system I’ve ever worked with is somewhere between these 2 extremes. And so the choice of whether to store FHIR resources natively or not is not straight forward.

In fact, I’m starting to see a lot of system taking a hybrid approach – storing FHIR resources natively, and storing a well controlled subset of information in some expressly designed scheme. The balance between these is driven by the stability of information requirements for different parts of the system.

Managing Joins

Going back to the question about normalisation and references – most systems that store resources natively find the way references work in FHIR to be a pain point; references can be absolute or relative URLs, they can be version specific or not, they may or many not follow FHIR’s well defined RESTful interface pattern, and they may or may not resolve in the local system (and the kind of systems where you’re storing resources directly are the kind of systems where you can’t always enforce referential integrity). All this flexibility is required in various exchange scenarios, but it’s a real tax if you’re filling a coherent data store with resources.

For that reason, I recommend that if you’re storing resources natively, you consider extending the storage format of your choice with a resolved link in addition to the existing reference/identifier in the Reference data type. The RDF format does this explicitly for references and codings (fhir:reference and fhir:concept) and Google’s protobuf implementation does something similar. (note that if you’re storing JSON, then you’ll have to remove the extension for exchange, unless you use a native FHIR extension – which isn’t the most efficient way to do it)