Stream: fhir/documents
Topic: document lifecycle/version
Craig Anderson (Apr 30 2019 at 13:25):
Does FHIR support the ability to lifecycle (or version) a document? Something akin to the way the current regulatory submission standard (eCTD) handles application and document lifecycles.
For example, in a regulatory context. A pharmaceutical company submits an application to Health Canada containing a document v1.0. During the review process the company wants to submit an updated version of the document (v1.1). v1.1 replaces v1.0.
document v1.1 has a relationship reference to v1.0 showing that it replaced the older version.
Lloyd McKenzie (Apr 30 2019 at 14:49):
See Composition.relatesTo - specifically the "replaces" relationship.
Craig Anderson (Apr 30 2019 at 19:30):
Thanks Lloyd,
After looking at Composition, DocumentManifest and DocumentReference, I suspect they can be used together to replicate the concept of a regulatory application. Generally speaking does that sound reasonable?
Lloyd McKenzie (Apr 30 2019 at 19:37):
DocumentManifest and DocumentReference are usually used separately from Composition. If you're submitting a document, it's either going to be a FHIR Document, in which case it'll be a Bundle that starts with Composition and then points to all of the other relevant resources that form the 'content' of the document; or it'll be a non-FHIR document in which case the content will be sent as binary information either embedded in or pointed to by DocumentReference. (DocumentReference can also point to FHIR Documents, but in that case the metadata in the DocumentReference is redundant with what's in the Composition and the DocumentReference is used as an index entry pointing to a document held elsewhere.) DocumentManifest is primarily used for IHE's Mobile Health Data (MHD) specification, though it could theoretically be used for other purposes. It might have a place in a regulatory submission
Craig Anderson (May 03 2019 at 20:44):
Got it. thank you
Craig Anderson (Jan 22 2020 at 19:05):
Has FHIR described any special methods for packaging and exchanging documents as a single file? For example, if the document is made up of a single .xml and five .jpg's. Would they be exchanged as a single package using .zip or would FHIR have a unique .fhir (something akin to the DOCX approach).
Lloyd McKenzie (Jan 22 2020 at 19:17):
The JPGs would typically be embedded in the FHIR Document as Binary resources (which would involve base64-encoding the JPGs). They would be Bundle entries just like any of the other resources in the document.
John Moehrke (Jan 23 2020 at 11:57):
and that Bundle (of type document) could be indexed and communicated using DocumentReference... as is defined in US-Core and also IHE MHD implementation guide.
Lloyd McKenzie (Jan 23 2020 at 18:14):
Right. If you needed metadata around the JPEG, you can use DocumentReference to convey that
Last updated: Apr 12 2022 at 19:14 UTC
