DocumentReference $generate

[JohnMoehrke]

Define a $generate operation on documentReference

Given a Document Source has a document (CDA or FHIR) and wants to publish it, a Service is provided that can create DocumentReference/SubmissionSet metadata given the CDA header or FHIR-Document composition using Document Recipient known metadata mapping (Metadata whitepaper), and metadata mapping from PCC.

something like:
Parameters in

• Binary 0..1 - document bits, usually a CDA document
• Document Bundle 0..1 - a FHIR Document
  Parameters out
• DocumentReference created

Note that FHIR core R5 has a prototype of an operation similar, but it is badly modeled and explained, and also does not support submission of a FHIR-Document.

zulip discussion that inspired this issue -- https://chat.fhir.org/#narrow/stream/179166-implementers/topic/DocumentReference.2F.24generate.20Operation

[JohnMoehrke]

@simoneOnFhir indicates they have defined a generatemetadata operation
https://simplifier.net/isik-dokumentenaustausch/generatemetadata

we should consider this.

[sheridancook]

Something to consider that is echoed in that zulip thread- if we are trying to make it easy for folks to generate a DocumentReference, but our operations primarily populate it from the contents of the content being referenced (e.g., FHIR Document Composition)... then we have to be clear to implementers what the value is for them to use DocumentReference/why we're including it as the only (non-binary) entry point for FHIR documents to be included in ITI-65.

I believe there is an argument to be made for harmonization & improvement of search practices, but the value of having a DocumentReference to go along with the FHIR Document has to outweigh the burden of supporting the generate operation for vendors that would otherwise be happy accepting the FHIR Document alone (something we've heard expressed by our implementers in Canada). If the pros don't outweigh the cons for non-XDS implementers/can't be communicated easily, then the expectations around necessitating an anchor of DocumentReference to exchange FHIR Documents need to be reconsidered.

[JohnMoehrke]

The $generate operation would be expected to take input of a FHIR Document, but it is also expected to take input that is a CDA document. So the purpose here is to provide consistent metadata (DocumentReference) regardless of the document encoding.

I think your point, regarding DocumentReference value when the document is a FHIR Document which is defined by a FHIR Composition, is a good point that does need to be a focal point of discussion in the Document Sharing space of the value.

I would not disagree with those that are starting with a FHIR Composition, that the DocumentReference that is purely a derivation directly mapping from the Composition is limited value. That value would be only that the DocumentReference is a single metadata definition for all kinds of documents including FHIR Composition. However, even in this case, the $generate, may not be just a one-for-one mapping. The Composition is very focused on the original use, where the DocumentReference is focused on the broader uses of the content beyond the original use. Those Document Consumers that are within the original use for the Composition, likely would be served fine by the Composition alone, and likely have high fidelity access to the Composition. Those beyond the original use, such as longitudinal health information exchange that might be well beyond state, or country boarder, would benefit from a more accessible metadata.

Thus the transition from Composition to DocumentReference may add or remove fidelity. For example the DocumentReference.type and DocumentReference.category may be broader or use valuesets that are more internationally friendly. It is this point that we need to make very clear in the definition of the $generate operation.

[simoneOnFhir]

Assuming that "those starting with a composition" are most likely FHIR native applications, I think the ability to derive a DocumentReference is of great value! Once a Composition is finalized, in needs to be bundled up and stored seperately in order to maintain the document data seperately from the "working" data, wich may change over time.
Stored Bundles however have limited search capabilities through the RESTful API, so in order to store and retrieve finalized documents, even FHIR-native systems have to rely on DocumentReferences.

[JohnMoehrke]

The FHIR core (OO workgroup) discussed https://jira.hl7.org/browse/FHIR-34043

Which addressed the problem with the $generate definition. They decided to align the definition with the given example. This will only appear in R5.

So, for R4 IHE will need to define our own $generate that is properly defined with a note that we will move to the FHIR core $generate when we align with FHIR R5.

[JohnMoehrke]

FHIR-I chat discussion I started on if we can reference the R5 version of $generate... rather than having to create an IG specific operation until R5 is profiled by our IG.

[JohnMoehrke]

Will add a new Actor that serves the $generate.

[JohnMoehrke]

0bdc886