Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-41271

Clarify whether receiver should throw away MessageHeader

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R6
    • FHIR Infrastructure
    • MessageHeader
    • Messaging
    • 3.5
    • Hide

      Will add the following language to the 'messaging' page as a sub-section above "Asynchronous Messaging using the RESTful API":

      "MessageHeader and REST"

      "The MessageHeader is important and necessary when interpreting the contents of a message - they cannot be understood without it. However once resources are removed from the message bundle, and processed into some other context (e.g. PUT/POST to a RESTful API, or deconstructed into a database, or transferred into any other context), the content of the MessageHeader SHALL not be relevant for interpreting the contents of the resource. To be explicit, applications using a RESTful API are not required to look for past MessageHeader resources that relate to a resource in order to understand the resource correctly.

      ::Implementation Note

      Information that will need to be available to understand the resources that remain after processing a message should be conveyed using other resources - e.g. Task, Composition, etc."

      Show
      Will add the following language to the 'messaging' page as a sub-section above "Asynchronous Messaging using the RESTful API": "MessageHeader and REST" "The MessageHeader is important and necessary when interpreting the contents of a message - they cannot be understood without it. However once resources are removed from the message bundle, and processed into some other context (e.g. PUT/POST to a RESTful API, or deconstructed into a database, or transferred into any other context), the content of the MessageHeader SHALL not be relevant for interpreting the contents of the resource. To be explicit, applications using a RESTful API are not required to look for past MessageHeader resources that relate to a resource in order to understand the resource correctly. ::Implementation Note Information that will need to be available to understand the resources that remain after processing a message should be conveyed using other resources - e.g. Task, Composition, etc."
    • Nick Radov/Grahame Grieve: 15-0-0
    • Clarification
    • Non-substantive

    Description

      Is the MessageHeader resource intended to be transient in messaging workflow? That seems to be implicitly understood in some quarters but isn't explicitly stated in this module so we would appreciate clarification on that point. SHOULD a message receiver throw away the MessageHeader after processing the message?

      I discussed FHIR-40264 with lloyd and he thinks that a reason to remove certain elements from MessageHeader is that resource type is transient. The receiver may throw it away after processing the message and isn't expected to persist it. Thus any metadata which does need to be persisted by the receiver should be moved into separate Task resources. If we do go that route then we would at least need more detailed documentation and examples showing how to use Task for that case. There may also be differences between persisting message metadata for auditing and reporting purposes versus for clinical care.

      We might want a joint discussion between FHIR-I and InM before making a decision on this issue since FHIR-I owns the Messaging module and InM owns the MessageHeader resource type. Depending on the outcome of this issue a separate issue might be needed for MessageHeader.

      Tagging RikiM in case she wants to add additional comments.

      Attachments

        Activity

          People

            Unassigned Unassigned
            nradov Nick Radov
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: