Document explicitly: 1) That what is being communicated is Notification and not an Alert. 2) The Assumption is data is being transferred but not responsibility. The Receiver determines the action it takes based on the information it receives. The MessageHeader event code allow the receiver to guide the handling. 3) List of Receiver - typically is out of band business process. As done today regarding feedback to the Sender: Messaging does provide a mechanism for a response message, however, by design we have avoided response messages in an attempt to make the implementation as light wt as possible and avoid requiring implementation of FHIR messaging beyond support of the $process-message operation and message structure. The FHIR $process-message operation define the http response codes +/- OO that provide at least partial implementation of what the commenter is suggesting. namely : "200 OK: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response. 202 Accepted: Indicates that the receiving system has accepted custody of the message 204 No Content: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the messageheader-response-request extension), no response is being provided" And the implementer can provide additional information in the OO such as to " considered-it also provides a reference if the appropriate action was not taken and would at least provide a data point for process/quality improvement" Without more rigorous testing and implementer experience it is premature to define the response behavior any further.