Page History

• https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/Proposal.20for.20message.20identifier.20issues
  • Relationship between bundle and messageHeader
    • Minimum message is bundle with messageHeader – for a communications ACK
    • You have to make a bundle for each message
    • Batch bundle with entry for each bundle
    • So we should support the bundle.identifier, but no need for a messageHeader.identifier
    • If the snapshot that is the message cannot be maintained in restFUL representation, if you have a purely FHIR server where all resources are stored, so they can be updated – cannot keep the messageHeader resource AFTER the bundle was set
    • So MUST have RESTful persistence of the bundle = similar to V2 messages
  • For intermediaries, when you are forwarding to multiple recipients you should update the bundle.identifier
  • You don’t want to use the bundle.id for the intermediary to change, because the bundle.id can be reassigned by the receiving server – that’s why you need bundle.identifier
  • We only need bundle.identifier - left note on zulip
  • Proposal to suggest to remove FHIR messaging from the specification and write an IG in V2 on how to send a FHIR retrieval result message (ORU with RP in OBX-5 to the FHIR resource(s)) see if we get feedback

• We only need bundle.identifier

• https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/Does.20every.20message.20have.20a.20response.20message.3F
  • FHIR spec is clear for synchronous response
  • For asynchronous response and support for other transport mechanisms to support messaging, MUST have at least one response back to message
  • Require a response message (SHALL) and adapt to the transport mechanism you are using
    • For process message expect an http response of 200 response is ok
    • Must have endpoint defined for those ACKs, so that needs to be included in the initial bundle that is being sent – that is covered
    • Return bundle is 0..1 – maybe to support sending of operationOutcome?
  • There seems to be disconnect between instructions under messaging: https://build.fhir.org/messaging.html and process-message: https://build.fhir.org/messageheader-operation-process-message.html
  • Propose to update the messaging instructions page: https://build.fhir.org/messaging.html and carve out an exception for operation process-message

• Propose to update the messaging instructions page: https://build.fhir.org/messaging.html and carve out an exception for operation process-message

• These are jiras that have been approved by Gender Harmony group and need the official vote for V2.9.1 ballot
• will be sent later this week - for voting on March 7th

• FHIR-40264
  • This affects the notifications IG
  • Changes to messageHeader.author / sender / responsible
    • We need sender – for many reasons – at minimum for v2-FHIR Mapping from MSH-4
    • How would you reference the task for the purpose of identifying the sender/author/responsible?
    • If messageHeader.responsible and messageHeader.author was intended to be used for workflow, then task should be used, but what if that was used for identifying the responsible levels (device / person / role / organization)
    • jira that discusses how to use author, sender and responsible = FHIR-32403
      • proposed disposition is to move messageHeader.responsible to extension

Approve errata and publication request RE: V2.9, V2.9.1 

MSH-6 repeatability.

NOT DISCUSSED