Stream: implementers
Topic: Immutable FHIR Document
Shovan Roy (Jun 14 2019 at 03:48):
Hi All,
This is regareing the 'Immutable' part of FHIR document.
As per https://www.hl7.org/fhir/documents.html section 3.3.1 "Once assembled into a bundle, the document is immutable - its content can never be changed" and Section 3.3.3.2 says "When storing/transmitting a document, any method may be used as long as the bundled document can be (re-)assembled with sufficient integrity to validate a digital signature"
as per the guideline, I can see that the document can be persisted as "Bundle" or Binary etc. Sounds like Bundle is a good option from a client side. However, If we persist the document as Bundle, then at a minimum a Bundle.id will be generated by the server which means 'hash' received from the original document will change. does it mean that it's actually breaking the 'immutable' FHIR rule here?
On the other side, if we persist it as Binary, then the 'immutable' thing remain intact but it would be difficult/slowdown for the client system to deal with a Binary object and extract the Bundle document out of it.
May I request the community, a little more guidance on the 'immutable' definition of the FHIR document. If we persist the document as Bundle and then return back the same Bundle with additional Bundle.id, does this break the immutable rule of FHIR document ? (For audit purpose, I can store the the received FHIR bundle in AuditEvent.)
Looping in @Grahame Grieve @Lloyd McKenzie , @Brett Esler , @Nichol Hill , @Richard Townley-O'Neill @Reuben Daniels
Lloyd McKenzie (Jun 14 2019 at 14:36):
Bundle.id wouldn't be changed by the server if you PUT the document rather than posting it, but I see the issue. (Frankly, I don't understand the 'immutable' assertion - documents get updated in much the same way as other resources do.
Morten Ernebjerg (Jun 14 2019 at 19:56):
I would second the call for clarification as I have also been puzzled by this. The (quite possibly misguided) sense I got from the STU3 documentation was that FHIR documents represent essentially "frozen" sets of resources that capture a state at a fixed moment (like a printed letter) and hence have very different lifecycles than normal resources. Specifically, it would be great to have more guidance on which changes (if any) can be made while keeping the Bundle.id and/or the Composition.identifier. unchanged (e.g. to know when updating with a simple PUT on a document Bundle is appropriate)
Grahame Grieve (Jun 14 2019 at 21:35):
you can update it, but it's not longer the attested document
Shovan Roy (Jun 14 2019 at 22:14):
Thanks @Lloyd McKenzie , @Grahame Grieve for your comment.
@Grahame Grieve , in that case what would be FHIR recommended way to persist (POST and PUT) and transact (GET) a document without compromising immutability? Or immutability is applied on the content of the document but not on technical things like id, meta? Again the problem will be on hash matching.
Grahame Grieve (Jun 14 2019 at 22:14):
post it to the binary endpoint
Shovan Roy (Jun 17 2019 at 00:11):
Thanks @Grahame Grieve . I'll use Binary for FHIR Document interaction. However, Binary doesn't have any 'status'. So sounds like I'll have to manage that document life cycle using DocumentReference. Is this a correct approach? I mean if a PUT request happens to that FHIR document, then DocumentReference will be updated in the sever to point out which is the latest version of the Document.
Grahame Grieve (Jun 17 2019 at 03:41):
what's the status? How can you have a status if it's immutable?
Shovan Roy (Jun 17 2019 at 04:04):
@Grahame Grieve , the document is immutable at the receiving end. When in our server we receive it, we have to make sure that the FHIR document is immutable. However the source system can send an amended version of it.
Grahame Grieve (Jun 17 2019 at 04:07):
then you overwrite the binary, and the status of the binary should reflect that. you can use history to look at the history.... or you might want a document reference for it
René Spronk (Jun 17 2019 at 09:38):
An amended version, under document management rules, is in effect a new document. The status (deprecated, active) of each of these documents (old, newly amended) is maintained in a DocumentReference. In such a context you should never update a Binary, for a document is indeed immutable.
Shovan Roy (Jun 17 2019 at 21:19):
Thanks @René Spronk, yes we are going ahead with the Document Reference way.
Angus Millar (Apr 21 2020 at 05:57):
I've been trying to work out how one would load a FHIR document into a server. Of course, as suggested here, I can just POST or PUT the entire document bundle to the [base]/Bundle endpoint, or wrap it in a Binary resource and in much the same way POST to [base]/Binary. But what I had assumed I could do, but now find no evidence of, is pass it to an operation or the [base] endpoint where the server would notice it was a Bundle of type Document and then explode all of its resources into the server and update the Composition resource to have version aware references. Would this not then give an immutable document that can be reconstructed at a later point while also allowing all the granular resource of the document bundle to be discoverable as an individual resource as each of there endpoints.
Is there a reason such an idea is not baked into the spec?
Maybe there is a flaw I'm not thinking of here.
Grahame Grieve (Apr 21 2020 at 06:37):
well, the problem here is that not once do we say that a server has to accept a resource as it is posted
Angus Millar (Apr 21 2020 at 06:40):
If that is the problem then doesn't the same problem apply when stored at the Bundle or Binary endpoint?
Angus Millar (Apr 21 2020 at 06:44):
I've also noted the $document operation on Composition endpoint which states "A client can ask a server to generate a fully bundled document from a composition resource." I don't understand that if we have this operation then why not have equal and opposite operation to put them in the server.
Grahame Grieve (Apr 21 2020 at 07:09):
we could but it would be subject to the problem that we haven't required fidelity. And also because no one has asked for it
Grahame Grieve (Apr 21 2020 at 07:10):
as for storage as a bundle or a binary... we've taken it for granted that a binary end point stores the binary without altering it, but I'm pretty sure we haven't stated that anywhere. We might be able to say tghat
Angus Millar (Apr 21 2020 at 07:34):
I hear you, It still suffers the problem that you can't fine-grain search the content in a Bundle or Binary. I'm going to explore this further as a custom operation $DocuemntExplode and see what issues I find.
René Spronk (Apr 21 2020 at 08:31):
If you POST a bundle to a server endpoint (its root, [base]/) it will be seen as a batch of POSTs and the bundle will be shredded. However, for example because you don;t know how 'old' the document is, and whether the document contains resources that actually update resources taken from a previous document, or previous version of the same document, a operation is probably a better option from a clinical safety perspective. I'd say it's near to impossible for the FHIR spec to define such an operation as its functionality would be highly specific to how one is using a document in a specific project.
People who shred documents probably shouldn't have been using documents in the first place, they should look at documents or (transaction-)bundles instead.
Lloyd McKenzie (Apr 21 2020 at 14:08):
@René Spronk, actually most servers will treat a POST of a document to the base endpoint as an error now. If you want it to be shredded, you have to transform your document into an explicit batch or transaction - which includes indicating for each resource whether you're looking for a create, update, conditional create, etc. You also run into the problem of knowing the appropriate eTag if server updates enforce eTag correctness (which many servers will).
In general, most EHRs won't want received documents to be exploded. Instead, they'll want to carefully curate what they wish to extract out of the document and insert/merge into their EHR - just as they'd do if they received a C-CDA or even a PDF (though the process for extraction with FHIR would presumably be easier).
Last updated: Apr 12 2022 at 19:14 UTC
