Stream: implementers
Topic: DocumentReference/$generate Operation
Simone Heckmann (Sep 23 2021 at 18:10):
Question about DocumentReference/$generate:
It sounds as if the persist parameter should be boolean but it is Binary. What's the sematics here? If a Binary is provided in the persists parameter, it will be persisted? But then why is the url parameter mandatory if submitting the input as Binary is an option...?
Does persist include persisting the resulting DocumentReference or just the submitted Binary?
John Moehrke (Sep 23 2021 at 18:20):
I think I have always read that as Boolean.. but it clearly doesn't say that, it says Binary.
Simone Heckmann (Sep 23 2021 at 18:37):
Yep. I was confused too, Booleans are kind of binary...
David Pyke (Sep 23 2021 at 19:31):
It's to allow 0 (No) 1(yes) 2(I guess) 3(could do) 4(If I have to) and 5(you tell me). Boolean just didn't cover the possibilities well enough
Elliot Silver (Sep 23 2021 at 20:03):
It's binary, just a very short binary. 0 = no, 1 = yes. But you have to base64 encode it first.
Simone Heckmann (Sep 23 2021 at 21:28):
Boolean is actually insufficient because I still don't know whether this persists the (FHIR/CDA-)Document I put into the operation or the DocumenteReference it returns .
So the options are at least as follows:
0 - none
1 - document only
2 - DocumentReference only
3 - both
4 - document + OperationOutcome in case of error
John Moehrke (Sep 24 2021 at 13:26):
I would really like to see this advance, and would like to be involved. There is clearly a linkage to IHE OnDemand and Deferred Creation.
Simone Heckmann (Sep 24 2021 at 14:06):
Assuming that persist=true not only creates a DR but also persists both the original (CDA-/FHIR-)Document AND the DR, that would be the most efficient "Provide Document" interaction possible :big_smile:
Simone Heckmann (Sep 24 2021 at 14:08):
Basically just yeeting the document at the Repo :rolling_on_the_floor_laughing:
Simone Heckmann (Sep 30 2021 at 15:34):
Currently the in-parameter only allows to submit a url. I think this should be broardened to also allow for the submission of a Composition resource as an input parameter. Having to expose the Composition on a restful endpoint before calling the operation seems unnecessarily complicated.
I wonder if the error with the persist (Binary) parameter happened because it got tangled up with the intention to also allow the input of CDAs as Binaries...?
Simone Heckmann (Sep 30 2021 at 15:46):
I added https://jira.hl7.org/browse/FHIR-34043 for the improvement of this operation.
Simone Heckmann (Feb 25 2022 at 12:41):
I'll be needing an implementable $generate-Operation for a current project. So I have spent some time thinking about this.
Here's my suggestion:
Input-Parameters for $generate:
fhir-document 0..1: Bundle (for FHIR-Documents) or alternatively
non-fhir-document 0..1: Binary (for non FHIR Documents such as CDA or other non FHIR-Data to generate the DocRef from maybe IHE-XDS-Metadata).
non-fhir-document-type 0..1 code: In case of Binary input an additional parameter might be needed to indicate how to interpret the input. Binary.contentType might be insufficent here...? Binding to a VS could be used to indicate what sorts of Binary data are allowed here.
targetEndpoint 0..1 uri: Beyond the plain Field mapping I would expect the operation to also attempt to resolve things like Patient democraphics, Author information or Encounter information from the Bundle/CDA/ebXML to actual FHIR Resources on the Server and fill the references in DocumentReference accordingly. (Although the OperationDefinition should not make any assumtions on what the matching criteria are, since they might differ between use cases and jurisdictions)
Assuming that the $generate Operation could be provided by third party services other than the Server that eventually processes the resulting DocumentReference, an additional parameter will be needed to provide the Endpoint of the Server where the matching Patient/Ancounter/Author should be searched.
The return parameter can remain unchanged:
*docRef: DocumentReference 1..1
Any opinions on whether that sounds like a good idea? I wonder if this is still in the spirit of what the $generate-Operation was initially intended to be. Documentation is sparse, so I'm basically guessing what it was intended to do...
@John Moehrke
I'd be happy to create and test drive an OperationDefinition accordingly.
John Moehrke (Feb 25 2022 at 12:43):
IHE did accept the new work item to look at these kind of improvements to MHD. I hope you can join that effort, and thus I would be happy to see anything you propose.
John Moehrke (Feb 25 2022 at 12:48):
I am not exactly understanding your proposal here. In normal XDS today there is a On-Demand documentReference type, where the potential-publisher advertises the set of document types it is willing to create on-demand. Thus a consumer that wants one, just asks for one to be created. In this scenario, as part of a FHIR $operation, one would just pass in the on-demand documentReference, and get back the document created. I think there is a proposal for this kind of operation.
John Moehrke (Feb 25 2022 at 12:49):
There is work in the IPS space to do this, not exactly this same way, but rather compatible.
John Moehrke (Feb 25 2022 at 12:50):
I could see a $operation (patient, profile[, timeframe])
John Moehrke (Feb 25 2022 at 12:51):
@Oliver Egger ?
Simone Heckmann (Feb 25 2022 at 13:12):
I believe, on demand document creation is a different thing. I am dealing with a situation of "I already have a structured document (CDA, FHIR or other) and need a DocumentReference, so I need someone to do the field mapping for me, presumably some terminology-lookups an figure out the correct patient/author references für the DocumentReference.
The next step could be to POST the document with the newly created DocumentReference to a simple FHIR Server for Storage, of - if sufficent Metadata has been provided/added - submit to an MHD Endpoint.
Simone Heckmann (Feb 25 2022 at 13:13):
Basically a Service that does this: http://hl7.org/fhir/composition-mappings.html#fhirdocumentreference
(plus some searching/resolving....)
Simone Heckmann (Feb 25 2022 at 13:14):
The same service could be used to map ebXML to DocumentReference or create DocumentReferences based on CDA header information
John Moehrke (Feb 25 2022 at 13:18):
oh, that would be a nice service. More detail in the PCC technical framework. It would also need to be informed by the metadata mapping rules of the community -- ala the IHE Metadata Handbook.
John Moehrke (Feb 25 2022 at 13:19):
I would like to see that written up as an issue we consider this quarter.
Simone Heckmann (Feb 25 2022 at 13:29):
I'm trying to keep it somewhat IHE/XDS agnostic for now, just assume we need a plain old DocumentReference based on a plain old Document-Bundle. But I am hoping, that the operation can be adopted into FHIR core and from there be constrained to serve more specific mapping requirements, such as XDS
Simone Heckmann (Feb 25 2022 at 13:30):
hence the ping
John Moehrke (Feb 25 2022 at 13:30):
understood. the generic operation could be less specifically defined... but profiled into MHD it could add more specifics
Simone Heckmann (Feb 25 2022 at 13:32):
Yes. For example you could profile the input Bundle and specify the minimum requirements for the Composition metadata in order for the mapping to work. Same for the output DocRef: Could be constrained to comply to MHD minimal Metadata requirements
Elliot Silver (Mar 02 2022 at 09:49):
I was just looking at the $generate operation, and it doesn't make sense. I assume the input url is meant to point to the "document", but are there any expectations around what that document is? I'm guessing the description doesn't mean to say "FHIR Document (i.e. Bundle)" and is purposely using "document" loosely, but I'm not sure.
The description of the persist parameter talks about storing the "document at the document end-point (/Document)." First of all, I don't think there is a /Document endpoint; the closest we come is the /Bundle endpoint, but then if we accept that, does it change the interpretation of "document" throughout?
Finally, I don't see how the operation has enough information to work. I give the server an arbitrary URL and it's suppose to be able to retrieve whatever "document" is there and extract enough information to fill out a DocumentReference? (a) Good luck filling out more than contentType and size when the url is for a plain text file, and (b) If the document itself has enough information in it to fill out a DocumentReference, why am I bothering with the operation, or with DocumentReference itself?
I think I'm missing some fundamental concept here of how this is supposed to work.
John Moehrke (Mar 02 2022 at 12:06):
Yes, there are CR already pointing that out. What we are trying to do is figure out who originally crafted the operation to understand what they were thinking, and if anyone has implemented it. Otherewise we were thinking of changing it as Simone has recommended.
John Moehrke (Mar 10 2022 at 17:08):
The example given on the page differs from the formal definition, but is more logical. So it seems the definition is wrong.
Grahame Grieve (Mar 10 2022 at 19:37):
I don't think it was me
Grahame Grieve (Mar 10 2022 at 19:38):
But I think the 'document' has to be a FHIR Document, so that it generate a matching DocumentReference
John Moehrke (Mar 10 2022 at 20:08):
IHE is considering an option like this, but more flexible yet linked to IHE defined mapping and IHE defined metadata handbook guidance.
Last updated: Apr 12 2022 at 19:14 UTC
