Documents are only immutable as a matter of policy

Nov 6, 2013

One of the issues that kept coming up when we were discussing documents in FHIR last week is that notion that documents are immutable, and can’t change. Take, for instance, this, from the comments:

Document should be immutable

Only, documents aren’t immutable. That’ll be a shock for CDA centric readers, where the immutability of documents is a fundamental notion that is hammered into implementers by the specification and the community around it, but it’s true.

First, you have to build the document. Clearly, it’s not immutable while you’re doing that - it needs to be edited, changed, assembled, and this can be a piece meal process. So the technical artifacts that underly building a document aren’t immutable. Even after you have it, you can break it down, change things, reassemble them. It’s still the same technical constructs - so even then, it’s not immutable.

The immutability is affixed as a matter of policy - once a document is “done”, then it’s treated as immutable by choice, to establish clinical traceability. This is important, and necessary.

In CDA, the existence of a CDA document is evidence that the document is done, and so they are treated as unchangeable. If you, privately, choose to keep partially formed CDA documents that you don’t treat as immutable, well, that’s your private business, and there’s no need to let anyone else see your private business. So even with CDA, it turns out, immutability is a matter of policy.

FHIR is different to CDA, because the FHIR spec defines a whole lot of functionality that’s relevant and important during the building and processing phases. So it would be a mistake to restrict that functionality at the technical level to ensure that documents are immutable - because they actually aren’t at that level. What FHIR needs to do is ensure that the control points to enforce and audit immutability exist so that the policy imperative of clinical traceability can be delivered. That’s something that we’re keeping in mind as we work on the document design.

This same dichotomy exists, btw, in the v3 data types, where the abstract specification describes the data types as “immutable”, because they are, in concept. But the ISO 21090 concrete version implicitly caters for non-immutable definitions, and there’s discussion in the spec around the difference between immutable in technical terms, and immutable in policy terms.