Stream: implementers
Topic: immutable document bundle
Florian Wolf (Mar 24 2022 at 10:12):
Hi guys,
i am just reading through the document bundle specifications.
"Once assembled into a bundle, the document is immutable - its content can never be changed, and the document id can never be reused."
Does that mean, on a document bundle query I am not even allowed to reconcile patient information referenced in the bundle?
Or is that just related to a signed document bundle?
John Moehrke (Mar 24 2022 at 12:57):
if you reconcile the data, you will be creating a new document, thus a new Bundle, thus a new id.
Florian Wolf (Mar 24 2022 at 14:44):
thanks for the answer... so that means a document bundle is always a kind of snapshot.? even if the document is in status preliminary or something like this?
John Moehrke (Mar 24 2022 at 16:15):
correct. specifically a document Bundle is 'the' instantiation of a snapshot. the original content can be made into many instances. We just call each a unique instance. There is relationships, so the lifecycle of replacement etc is visible. But each document Bundle is a snapshot, and thus given a unique id.
Elliot Silver (Mar 24 2022 at 16:18):
I don't think it's absolutely black and white. The language you quote is not normative; there are no "shalls" in it that require a certain behaviour or you're not FHIR-compliant. It describes expectations. I can imagine, in some use cases, something like changing the status could be an update, while in others that might be prohibited. My reading of the intent though, is that the content is not expected to be maintained over time--you wouldn't have a "current medications" document.
John Moehrke (Mar 24 2022 at 16:24):
I hope that is not true. -- I created FHIR-36636
Elliot Silver (Mar 24 2022 at 16:31):
@John Moehrke , in your POV, can a server process the document on receipt, perhaps replacing the included patient with a patient resource on the local server? What about stripping unknown extensions from the content?
Lloyd McKenzie (Mar 24 2022 at 16:32):
A server can 'process' the document however it likes - but if it stores something other than the original document as a Binary blob, then if it spits it out again, it's a different document.
John Moehrke (Mar 24 2022 at 16:33):
that would seem to me to be a new document, with a relationship to the old, and provenance as to why the data was changed.
John Moehrke (Mar 24 2022 at 16:34):
document lifecycle is fully defined and supportable.
Elliot Silver (Mar 24 2022 at 16:35):
IMHO, Document lifecycle is poorly defined in Bundle.
John Moehrke (Mar 24 2022 at 16:36):
that is what DocumentReference is about
Elliot Silver (Mar 24 2022 at 16:42):
John Moehrke said:
that is what DocumentReference is about
...if you're using DocRef in conjunction with Documents. But if you're not, lifecycle becomes much more difficult.
John Moehrke (Mar 24 2022 at 16:48):
well, no problem in my view.. DocumentReference does have a defined scope and purpose.
John Moehrke (Mar 24 2022 at 16:49):
but a document Bundle also has the Composition within, and thus each instance of a document Bundle can be known the relationship to that Composition, and the lifecycle management that Compostion supports
Last updated: Apr 12 2022 at 19:14 UTC
