MHD_058 - support for Bundle as attachment.url type

[JohnMoehrke]

MHD_058: The profile requires that the document submitted is encoded in a FHIR Binary. Is there interest in also allowing a Bundle of type Document? This would be useful when publishing FHIR-Documents. The FHIR-Document would still need to be seralized into a Bundle of type Document, but that Bundle would not need to be further encoded into a Binary (e.g. base64 encoding). Note that the mime-type in this case would be forced to be the same mime-type as the ITI-65 Bundle, where a Document Source wants to encode ITI-65 in a mime-type that is different than the document, the Binary methodology would need to be used. note that retrieve (ITI-68) does allow the Document Client to ask for the document content in various mime types, thus allowing support for preferred mime type encoding if the Document Responder has the ability to return the content in a encoding other than the DocumentReference indicates.

[simoneOnFhir]

We have a XDS based PHR in Germany the contents of which are mostly FHIR Documents. The PHR will be updated with MHD-Gateways in the future, so we will need to be able to query and provide FHIR Document Bundles through MHD.

..although I just realize that the documents in the PHR are encrypted and hence: Binaries. But assuming that a potential future MHD gateway/PHR connector might also handle the encryption/decryption locally, the input for this connector would be a FHIR Document Bundle in an ITI-65 transaction bundle

[JohnMoehrke]

might this be paired with #122 and simplified even more? Meaning a Document Recipient that receives a Bundle that is a Document type will be expected to create the DocumentReference, and if grouped with XDS then create the SubmissionSet too?

[simoneOnFhir]

Would be nice! However, there are a few attributes, that are mandatory for XDS-compliant resources, but which cannot be derived from the Composition attributes, e.g. practiceSetting, facilityType and probably a few more...

[JohnMoehrke]

I don't think there are mandatory elements that would be a problem. Even if there were, those would only affect recipients that are grouped with XDS, and those could be expected to derive the values from some other information such as the client system or security context. My point is, that if we are willing to derive a DocumentReference from a Composition, and we are willing to derive a SubmissionSet from a DocumentReference ( #122 ), then why can't both be pipelined? If they are pipelined, are there other things that might need to be said? So, I think the concern is more about how #122 works. Right?

[simoneOnFhir]

I absolutely agree. It would be really great if we could reward clients who produce FHIR-compliant structured documents by not having to bother much with XDS at all and have all the subsequent mapping and deriving done by an XDS-aware server. However, I have recently had a very sobering discussion with vendors, if a server could derive an XDS type code if a client provided a coding from a different terminology that has a 1:1 mapping to XDS type codes: Many of the server implementors/vendors (mostly classic XDS Document Registry/Repository vendors looking to implement FHIR facades) were highly reluctant towards "manipulating" the clients metadata, even if it is just the simplest of lookups. I guess they see themselves primarily as archives who persist whatever data they are submitted and they are very apprehensive towards accepting responsibility for changing or adding any data. So I guess it's probably more a philosophical issue rather than a technical one.

[JohnMoehrke]

I have opened a FHIR CR to ask for some clarity - https://jira.hl7.org/browse/FHIR-37444

[sheridancook]

I don't think there are mandatory elements that would be a problem. Even if there were, those would only affect recipients that are grouped with XDS, and those could be expected to derive the values from some other information such as the client system or security context. My point is, that if we are willing to derive a DocumentReference from a Composition, and we are willing to derive a SubmissionSet from a DocumentReference ( #122 ), then why can't both be pipelined? If they are pipelined, are there other things that might need to be said? So, I think the concern is more about how #122 works. Right?

+1 for abstracting XDS-driven requirements for DocumentReference elements (facilityType, practiceSetting, etc) and submission set metadata away from folks solely sending FHIR documents between systems that are pure FHIR/non-XDS. But I'd go further in saying that a new DocumentReference profile would be needed that doesn't exert MS flags on those XDS-related elements. Managing different MS definitions in the same profile ("MS if you are an XDS system" "MS for all") would be a headache for all involved.

US Core DocumentReference is a good starting point for understanding what FHIR-oriented vendors are using as a minimum to exchange DocumentReferences (including ones with FHIR Documents) it shares some constraints with the existing MHD Minimal DocumentReference profile but is notably looser in not considering the following elements MS: relatesTo, securityLabel, content.attachment.language, content.attachment.creation, context.facilityType, context.PracticeSetting, context.sourcePatientInfo

[JohnMoehrke]

I don't think there are mandatory elements that would be a problem. Even if there were, those would only affect recipients that are grouped with XDS, and those could be expected to derive the values from some other information such as the client system or security context. My point is, that if we are willing to derive a DocumentReference from a Composition, and we are willing to derive a SubmissionSet from a DocumentReference ( #122 ), then why can't both be pipelined? If they are pipelined, are there other things that might need to be said? So, I think the concern is more about how #122 works. Right?

+1 for abstracting XDS-driven requirements for DocumentReference elements (facilityType, practiceSetting, etc) and submission set metadata away from folks solely sending FHIR documents between systems that are pure FHIR/non-XDS. But I'd go further in saying that a new DocumentReference profile would be needed that doesn't exert MS flags on those XDS-related elements. Managing different MS definitions in the same profile ("MS if you are an XDS system" "MS for all") would be a headache for all involved.

US Core DocumentReference is a good starting point for understanding what FHIR-oriented vendors are using as a minimum to exchange DocumentReferences (including ones with FHIR Documents) it shares some constraints with the existing MHD Minimal DocumentReference profile but is notably looser in not considering the following elements MS: relatesTo, securityLabel, content.attachment.language, content.attachment.creation, context.facilityType, context.PracticeSetting, context.sourcePatientInfo

This should be a new issue.

[JohnMoehrke]

The FHIR core team (OO workgroup) looked at the Jira ticket https://jira.hl7.org/browse/FHIR-37444

It was decided to assign this to FHIR-I as the point is about the Attachment datatype, which is owned by FHIR-I; and the concept of how to process attachment.url as if it was a Reference needs to be more generally addressed than just within DocumentReference.

[JohnMoehrke]

FHIR-I chat discussion on the topic of using .url to point at any Reference.

[JohnMoehrke]

FHIR-I has indicated that there should be no problem putting a Reference.reference into the attachment.url. And the Attachment datatype does speak to this in both the narrative on Attachment, and on the definition of Attachment.url. So, we should be able to point at the Document Bundle without concern.

[JohnMoehrke]

FHIR R5 (CI build) now has examples of DocumentReference pointing at a Composition, and also DocumentReference pointing at a FHIR-Document Bundle. -- I was FHIR core editor applying the approved CR.

Now that is done. We need to address things like mime-type for consistency across all DocumentSharing pathways downstream and upstream.

[JohnMoehrke]

Question: Now that we have Simplified Publish, is it really necessary to support the publish of a FHIR-Document Bundle feature?

If the answer is YES. Then how does this related to ITI-105 and ITI-106?

• It seems improper to put this into ITI-65, although that is a possibility.
• Simplified Publish could be updated such that .url is allowed, but where the url is to a server where the FHIR Document Bundle can be found and pulled.
• Another transaction can be added that is a Bundle like ITI-65, or could be an operation.

Regardless, this seems different enough to normal Document Sharing that it might be useful to be in a named Option?

How do we pick? Might we just pick the operation choice to see what reaction public-comment and testing produces? (also a good reason to put it into a named option)

[JohnMoehrke]

John to work on ITI-65. Expect not needing an Option defined, should be just adding Expected Action behaviors when the url points at a FHIR Document Bundle.

In various backend environments

• MHDS -- Persist as a FHIR Document Bundle
• XDS/XDR/XCDR - Persist as a Binary equivalent in the mime-type provided from the Document Source. May also persist in opposite mime-type with a transform relationship.
• non IHE defined backend -- discretion of the server.

[JohnMoehrke]

Seems the size/hash rules in ITI-65 would need to change too? It is possible for them to be provided and be right, but is it helpful or distracting?

DISCUSSED: Likely these can not be required when the document is a FHIR-Document Bundle vs a Binary; so need to be relaxed. Might we need an invariant to check this? Or is it okay to just be optional with a MS and narrative explaining some reasons for it to be not included?

[JohnMoehrke]

Should this Issue add explanation of use of the FHIR-Document .meta.profile as the formatcode in the DocumentReference that points at it? This is not exclusive to this new feature, as it is true in the Binary case too.

DECIDED -- Make into a CP as this applies today and is not MHD specific (Action Item John)

[JohnMoehrke]

http://build.fhir.org/ig/IHE/ITI.MHD/branches/Moehrke-publish-Fdocuments/index.html

[simoneOnFhir]

For the sake of consistency I believe that using ITI-105 as it is (with embedded base64 binary) makes sense even for FHIR document bundles. That way the server recieves an immutable document with a verifiable signature an can decide at it's own discretion, whether FHIR documents need to receive any special treatment (beyond separating them from the DocumentReference) or not.

True, for the client embedding the document bundle into the document reference is an unnecessary extra step. But then, so is creating the DocumentReference in the first place. Ideally, any service/operation that creates the DocumentReference from the Composition/Bundle should be able to return the DocumentReference with the embedded content directly. (I'm looking at you, $generate !!)

So "upcycling" the FHIR Document Bundle into valid MHD(s) payload should be just one extra step either way.

[simoneOnFhir]

Another point on the plus side: setting the mimetype properly would be easy for the client: Just set it to whatever format you embedded into the Attachment. It would be completely up to the server to deal with the potential polymorphism of the reference it placed into Attachment.url after separating out the embedded content.

[JohnMoehrke]

For the sake of consistency I believe that using ITI-105 as it is (with embedded base64 binary) makes sense even for FHIR document bundles. That way the server recieves an immutable document with a verifiable signature an can decide at it's own discretion, whether FHIR documents need to receive any special treatment (beyond separating them from the DocumentReference) or not.

True, for the client embedding the document bundle into the document reference is an unnecessary extra step. But then, so is creating the DocumentReference in the first place. Ideally, any service/operation that creates the DocumentReference from the Composition/Bundle should be able to return the DocumentReference with the embedded content directly. (I'm looking at you, $generate !!)

So "upcycling" the FHIR Document Bundle into valid MHD(s) payload should be just one extra step either way.

This feature is different than Simplified Publish. This is a change to ITI-65 to allow FHIR Document Bundles where we use Binary today. The result may look the same on the Query/Retrieve side.

[JohnMoehrke]

Another point on the plus side: setting the mimetype properly would be easy for the client: Just set it to whatever format you embedded into the Attachment. It would be completely up to the server to deal with the potential polymorphism of the reference it placed into Attachment.url after separating out the embedded content.

Yes, agreed.

[JohnMoehrke]

Questions for Discussion today

1. Is this needed now that we have Simplified Publish? -- The last discussion put this question more as an Public Comment question? right?
2. Need a term for the "Binary or FHIR-Document Bundle"
3. How should the provideBundle profile change? Do we need to distinguish DocumentReference that point at Binary from those that point at DocumentBundle?
   4. is this a set of structureDefinition Profiles?
   5. might someone help me use an invariant FHIRpath instead?
4. How prescriptive or informative should we do around persistence of the Document Bundle?
   7. Likely needs to be aligned with the $generate. Might the persistence be more a responsibility of the persistence layer (MHDS, XDS).
   8. Where with MHDS persisting purely as a Document Bundle may be all that is needed,
   9. but XDS requires Binary translation.
   10. Both likely need two DocumentReference for xml vs json seralization?
5. is there an option needed to make it clear Fhir Document is allowed?
6. How are Fhir Documents acceptance indicated in CapabilityStatement?
7. How are constraints on the kind of Fhir Documents (profiles) to be indicated, or is that a concern?

[JohnMoehrke]

1. Continue to develop this, possibly a public-comment poll to drive for feedback. Also, we can always remove one or the other later if they turn out to be redundant.
2. no good term brought forward - still would like a term, for now will need to spell it out "Binary or FHIR-Document-Bundle" or something like that.
3. No technical way to add constraint. So will need to explain this in narrative only.
4. no way known
5. no way known
6. Persistence is not a MHD topic.
7. will try to use same text
8. may be able to hint at possibilities in MHDS, but should really leave this to MHDS
9. XDS must explain the conversion to binary form(s).
10. Discussion points out that the two DocumentReference must have different .url values purely because a Retrieve without a mime-type mentioned in http request needs to return the mime-type as described in the DocumentReference. This may be needed to be said outside this pull-request.
11. still open question
12. still open question
13. still open question

[simoneOnFhir]

@ 2: We used "payload" for lack of a better term...

@ 3/5: I think this could be handled with FHIRPath-Expressions/Invariants, if there is a mandatory fixed value in .content.format, that indicates that the document is a FHIR Bundle and can be used to trigger expressions like "DocumentReference.content.format = 'FHIR-Document-Bundle' implies "

@ 6/8 maybe link to/harmonize with QEDm profile for detailed description on how to extract and store data from a Bundle and maintain Provenance to link extracted resources back to the originating document?

@ 10: could this be handled by allowing multiple .content nodes with each representing one of the available representations on the server, e.g. .content .attachment .contentType= application/fhir+xml .url = Bundle/mydocument?_format=xml .content .attachment .contentType= application/fhir+json .url = Bundle/mydocument?_format=json

Optionally, Document Providers could choose to serve FHIR Documents in a simplified forms such as HTML (Narrative only) or on-the-fly generated PDFs and add an additional .content elements, e.g. .content .attachment .contentType= application/html .url = mydocument?_format=html

With multiple .content elements, Clients could easily discover which representations of the documents are available and chose the appropriate ones for their use case (automated processing vs. presenting to human consumer)

[simoneOnFhir]

@ 12/13: I am still of the conviction, that any FHIR Server that allowes POSTing of DocumentReference and POSTing of Bundle/Binary within a Transaction must also allow individual POSTs of these resources outside a transaction, since a transaction has no special meaning in FHIR except for executing individual REST-Interactions in a transactional manner. Hence I would expect these Servers to also list POST of DocumentReference/Bundle/Binary as a part of their CapabilityStatement. In that case, the Capabilities for POSting to /Bundle could also list all of the allowed FHIR Document Profiles.

[JohnMoehrke]

@ 12/13: I am still of the conviction, that any FHIR Server that allowes POSTing of DocumentReference and POSTing of Bundle/Binary within a Transaction must also allow individual POSTs of these resources outside a transaction, since a transaction has no special meaning in FHIR except for executing individual REST-Interactions in a transactional manner. Hence I would expect these Servers to also list POST of DocumentReference/Bundle/Binary as a part of their CapabilityStatement. In that case, the Capabilities for POSting to /Bundle could also list all of the allowed FHIR Document Profiles.

This might be true from an academic FHIR server perspective. But this is not required of MHD.

[JohnMoehrke]

@ 2: will try payload. Not sure this works well as everything is payload, so that seems to be too general of a word. I think just 'document', where at the top it is explained that document is used for Binary document or FHIR-Document document.

@3/5 -- .format is for a different purpose, it is to express the profile that the document conforms to. Not the type of encoding. I don't think this needs to be resolved

@ 6/9 - QEDm is very downstream of MHD. Already is linkage to XDS/MHDS that is all the deeper MHD should go.

@ 10: No. MHD explicitly forbids multiple .content nodes; because this is the model originally defined in XDS for Document Sharing. Multiple DoumentEntry with explicit relationships is the model that is appropriate, which already provides a method for clients to discover alternative encodings they might want to use. There is already support for allowing a retrieve to react to the http negotiate.