Simplified Publish

[JohnMoehrke]

Prefer that there be a way a Document Source can publish simply using one DocumentReference. This DocumentReference would use attachment.data holding the data. The Document Recipient is allowed to breakout the .data into a Binary and change to .url (may simply be guidance).

• when a SubmissionSet is needed by the recipient, it is derived off of the metadata in the DocumentReference
  • meaning there is no way to carry elements unique to SubmissionSet, (e.g. intended recipient)
  • there is no way to have metadata different than DocumentReference (submitter is the author)
• no way for this to be a replacement
• named option to be visible and hold conditions.

Likely could be supported by RESTful POST of the DocumentReference.

[JohnMoehrke]

@oliveregger how do you think we should implement this? Should we
a. relax the requirements of ITI-65
b. crate another transaction ITI-??? that is this lesser version?

How would we handle the server capabilityStatement? Would we start adding in something that enables a client to understand the minimal requirements of the server? (This might be useful even today regarding minimal, comprehensive, unconntained, and xds-on-fhir.

[JohnMoehrke]

make a new transaction

[sheridancook]

We would encourage consideration of an even more simplified transaction that allows a FHIR Document to be published without the DocumentReference. In our evaluation of MHD for Pan-Canadian Patient Summary - it was unclear if DocumentReference was necessitated for the benefit of XDS systems requiring the submission set metadata. See comment in #123 - if value of having a DocumentReference varies by implementer (and an operation is available to allow implementers the ability to generate the metadata they need after submission) then DocumentReference should be considered optional with avenues to submit FHIR Document alone

[JohnMoehrke]

Good discussion. We might end up there, but right now we are struggling with the concept of being able to support a $generate operation at all. There are derivations from Composition to DocumentReference that would be context dependent, and the results of the $generate should be reviewed or improved by the DocumentSource prior to submitting to an HIE. Thus, we should indeed experiment with a submission that is the FHIR Document Bundle, and see what issues come up.

[JohnMoehrke]

Plan at this point is a new transaction for the simplified push. Need to make clear distinction that can be seen in the Bundle, but also clear distinction for when each are used. Possibly clear distinction when simplified is not allowed.