todo Unique Id for this message Id of the thread - a series of messages that pertain to the same logical sequence, and are all identified by the same thread identifier Instant the message was sent Code that identifies the event this message represents, and connects it with the event definition in the FHIR specification Information about the the message that this message is a response to - if it is a response The source application from which this message originated The destination application which the message is intended for The person or device that performd the data entry leading to this message. Where there is more than one candidate, pick the most proximal to the message. Can provide other enterers in extensions The logical author of the message - the person or device that decided it should happen. Where there is more than one candidate, pick the most proximal to the message. Can provide other enterers in extensions The person or organization that accepts overall responsbility for the contents of the message. The implication is that the message event happened under the policies of the responsible party The effective time - the real world time of the even that the message represents. Usually this is just a starting time, but some message events also have an end time (do x for period y) The cause of the event - a reason for why this message is being sent The actual data of the message - a reference to the focus class of the message. See Extensions The id of the message that this a response to Code that identifies the type of response to the message - whether it was successful or not, and whether it should be resent or not True if this is not the first response, because the request message has been received more than once The message was accepted and processed without error Some internal unexpected error occured - wait and try again. Note - this is usually used for things like database unavailable, which may be expected to resolve, though human intervention may be required The message was rejected because of some content in it. There is no point in re-sending without change. The response narrative must describe what the issue is The message was rejected because of some event-specific business rules, and it may be possible to modify the request and re-submit (as a different request). The response data must clarify what the change would be, as described by the event definition A middleware agent was unable to deliver the message to it's supposed destination