Stream: ihe
Topic: DocumentReference/$generate in context of MHD
Simone Heckmann (Sep 27 2021 at 08:38):
In that thread, we discussed some of the syntactical issues with the current specification of the $generate operation.
In this thread I would like to talk about the implications of using $generate in an MHD context.
I think the operation makes a lot of sense for implementers who want to send a FHIR document via MHD/XDS . Having an endpoint that is able to map the Composition metadata to the appropriate DocumentReference for an MHD/XDS affinity domain could be super convenient.
What I am currently unclear about however is the expected behaviour of $generate...
Does it simply map the content according to this mapping?
Or can I expect the operation to also do some terminology translate operations in order to figure out the appropriate class/type codes for the domain.
Is there a general expectation that Compositions sent via MHD are aligned with the DocumentReference or could for example the classcodes differ (assuming that documents are classified differently at the point of creation than in an XDS context - internal vs. external...?)
Interestingly the mapping between CDA and DocumentReference seems to leave room for differences in class/type codes, whereas the mapping between Composition and DocumentReference does not.
I realize that these mappings are merely informational but I think there is impact on what the expected behaviour of $generate is.
Opinions, anyone?
John Moehrke (Sep 27 2021 at 12:50):
The questions about $generate likely need a broader audience. This is not an IHE defined operation, and we have not discussed the use of $generate.
John Moehrke (Sep 27 2021 at 12:53):
As to the internal vs external -- yes, this is intended. The mapping given for Composition -> DocumentEntry/Reference are advice, not mandates. There is an update of the IHE-PCC technical framework to provide a mapping advice similar to what they have today for CDA->DocumentEntry/Reference. The IHE advice should be more clear on the adjustment to the Document Sharing community needs. As you point out class code is commonly different.
Simone Heckmann (Sep 30 2021 at 14:37):
John Moehrke said:
The questions about $generate likely need a broader audience. This is not an IHE defined operation, and we have not discussed the use of $generate.
I think that the general assumption with FHIR operations is, that they define an interface but not the business logic behind it.
A generic Patient/$everything implementation might just bundle up all resources pertaining to a patient whereas a US realm implementation would return the data according to meaningful use.
In the same fashion, a generic implementation of DocumentReference/$generate might just use the suggested Composition->DocumentReference mapping whereas an MHD(S)-adjacent implementation would probably want to do more than that.
I opened this discussion in /ihe to figure out what the "more than that" could be. Or would you assume a similar functionality in an MHD(S) context to be a seperate operation?
John Moehrke (Sep 30 2021 at 14:49):
interesting proposal to me.
John Moehrke (Sep 30 2021 at 14:49):
much like a specific FHIR based way to do the OnDemand document entry.
John Moehrke (Sep 30 2021 at 14:51):
I had not thought of doing $generate on the DocumentReference endpoint. Presume it is actually DocumentReference/[id]/$generate
Simone Heckmann (Sep 30 2021 at 15:28):
Since the DocumentReference doesn't exist yet at the time of calling the operation I think it should be ResourceType specific, not instance specific. The Composition (or CDA) for which the DocumentReference should be created is provided as an input parameter.
Simone Heckmann (Sep 30 2021 at 16:19):
John Moehrke said:
much like a specific FHIR based way to do the OnDemand document entry.
I'm not entirely sure, we're thinking about the same use case. I mostly consider $generate as a service Document Recipients could provide for (IHE incompetent) Document Sources to help them prepare an ITI-65 transaction. "Just give me your document, I'll figure out the appropriate metadata for you..."
Specifically for FHIR based clients that already went through the effort to create a document bundle with all the structured metadata, I think it would be nice to reward them with a quick and simple way to transform the Composition into the required DocumentReference. And it makes sense to have a server do it for them because looking up the mappings for e.g. class and type codes might require some serious terminology infrastructure.
But I am sure there are lots of other useful applications in the MHD(S) realm...
John Moehrke (Sep 30 2021 at 19:21):
oh, definitely not what I was thinking. that seems useful, but different. that would seem to be a useful FHIR Operation for MHD to define. today MHD expects the Document Source that is able to provide a document to be knowledgeable about what that document is. What you are describing may be needed, but is something less functional than a Document Source. Something that starts with some kind of structured/coded document that it this actor does not understand, it calls upon a service to prepare (or even invoke) the responsibility of a Document Source. So something pre-Document Source.
Document Publisher -> Document Describer -> Document Source -> Document Recipient --> Document Registry
John Moehrke (Sep 30 2021 at 19:24):
Just the organization I think of.. different grouping (I grouped Document Describer and Document Source), could group Document Publisher with Document Source.
Last updated: Apr 12 2022 at 19:14 UTC
