Merge pull request #3282 from HL7/FHIR-40294

appled JIRA FHIR-40294,FHIR-42716,FHIR-41271,FHIR-43942

source/messaging.html

@@ -30,9 +30,10 @@ <h1>Messaging using FHIR Resources</h1>
   <li>If the <a href="messageheader-definitions.html#MessageHeader.focus">MessageHeader.focus</a> or
      <a href="messageheader-definitions.html#MessageHeader.response.details">MessageHeader.response.details</a> refer to
      any resources, they SHALL be included in the Bundle entries</li>
-  <li>The bundle MAY also contain additional resources that these other resources refer to. It SHOULD include all resources needed
-     for the receiver to be able to process the message as expected by the MessageHeader.event 
-     (this can be defined by a <a href="messagedefinition.html">MessageDefinition</a> resource)</li>
+  <li>The bundle MAY also contain additional resources that these other resources refer to. It SHOULD include all resources needed for the receiver to be able to process the message as expected by the MessageHeader.event.
+     This can be computably defined by a <a href="messagedefinition.html">MessageDefinition</a> resource 
+     or a <a href="operationdefinition.html">OperationDefinition</a> resource 
+     </li>
   <li>The bundle SHALL NOT include resources that do have references 
     (by <a href="references.html#Reference">Reference</a> or <a href="references.html#canonical">canonical</a> links) 
     to the <code>MessageHeader</code>
@@ -426,7 +427,13 @@ <h3>Asynchronous Messaging using the RESTful API</h3>
 by re-using the same system identifier (and against malicious
 attack).
 </p>
-
+<h4>MessageHeader and REST</h4>
+<p>
+The <a href="messageheader.html">MessageHeader</a> 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 <a href="bundle.html">Bundle</a>, 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 <a href="messageheader.html">MessageHeader</a> 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 <a href="messageheader.html">MessageHeader</a> resources that relate to a resource in order to understand the resource correctly.
+</p>
+[%impl-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.
+[%end-note%]
 <a name="Events"></a>
 <a name="events"></a>
 <h2>Defining Events</h2>
@@ -516,7 +523,7 @@ <h3>Invoking Search via Messages</h3>
 To perform a search with messaging that mirrors REST functionality, the message 
 should leverage a Parameters instance with a standard parameter name of "url" and 
 a valueString that corresponds to the search string that would typically be to 
-the right of the base URL.  E.g. if in REST you would say <code>http://someserver.org/fhir/Patient?name=joe</code>code>, 
+the right of the base URL.  E.g. if in REST you would say <code>http://someserver.org/fhir/Patient?name=joe</code>, 
 then the parameter would have a value of <code>Patient?name=joe</code>.
 </p>
 <p>

source/transport/transport-event-mapping-exceptions.xml

@@ -53,7 +53,7 @@
         <lowerCardinality _pattern="1" _resource="0" reason="Unknown"/>
         <shortUnmatched reason="Unknown">
             <_pattern value="preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown"/>
-            <resource value="in-progress | completed | abandoned | cancelled | planned | entered-in-error"/>
+            <resource value="preparation | in-progress | not-done | suspended | stopped | on-hold | completed | entered-in-error | unknown"/>
         </shortUnmatched>
         <definitionUnmatched reason="Unknown">
             <_pattern value="The current state of the transport."/>