FHIR Release 3 (STU)

This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

Operation-messageheader-process-message.xml

Infrastructure And Messaging Work GroupMaturity Level: N/ABallot Status: InformativeCompartments: Device, Practitioner

Raw XML (canonical form)

Jump past Narrative

Operation Definition

<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="MessageHeader-process-message"/> 
  <text> 
    <status value="generated"/> 
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2> Process Message</h2> 
      <p> OPERATION: Process Message</p> 
      <p> The official URL for this operation definition is: </p> 
      <pre> http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message</pre> 
      <div> 
        <p> This operation accepts a message, processes it according to the definition of the event
           in the message header, and returns a one or more response messages.  This  operation is
           described in detail 
          <a href="messaging.html#process">on the messaging page</a> 
        </p> 

      </div> 
      <p> URL: [base]/$process-message</p> 
      <p> Parameters</p> 
      <table class="grid">
        <tr> 
          <td> 
            <b> Use</b> 
          </td> 
          <td> 
            <b> Name</b> 
          </td> 
          <td> 
            <b> Cardinality</b> 
          </td> 
          <td> 
            <b> Type</b> 
          </td> 
          <td> 
            <b> Binding</b> 
          </td> 
          <td> 
            <b> Documentation</b> 
          </td> 
        </tr> 
        <tr> 
          <td> IN</td> 
          <td> content</td> 
          <td> 1..1</td> 
          <td> Bundle</td> 
          <td/>  
          <td> 
            <div> 
              <p> The message to process (or, if using asynchronous messaging, it may be a response message
                 to accept)</p> 

            </div> 
          </td> 
        </tr> 
        <tr> 
          <td> IN</td> 
          <td> async</td> 
          <td> 0..1</td> 
          <td> boolean</td> 
          <td/>  
          <td> 
            <div> 
              <p> If 'true' the message is processed using the asynchronous messaging pattern</p> 

            </div> 
          </td> 
        </tr> 
        <tr> 
          <td> IN</td> 
          <td> response-url</td> 
          <td> 0..1</td> 
          <td> uri</td> 
          <td/>  
          <td> 
            <div> 
              <p> A URL to submit response messages to, if asynchronous messaging is being used, and if
                 the MessageHeader.source.endpoint is not the appropriate place to submit responses</p> 

            </div> 
          </td> 
        </tr> 
        <tr> 
          <td> OUT</td> 
          <td> return</td> 
          <td> 0..1</td> 
          <td> Bundle</td> 
          <td/>  
          <td> 
            <div> 
              <p> A response message, if synchronous messaging is being used (mandatory in this case). For
                 asynchronous messaging, there is no return value</p> 

            </div> 
          </td> 
        </tr> 
      </table> 
      <div> 
        <p> This operation does not use the parameters resource; the parameters &quot;async&quot;
           and &quot;response-url&quot; always go in the URL, if they are used, and the message parameter
           is always the body of the HTTP message</p> 

      </div> 
    </div> 
  </text> 
  <url value="http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message"/> 
  <name value="Process Message"/> 
  <status value="draft"/> 
  <kind value="operation"/> 
  <date value="2019-10-24T11:53:00+11:00"/> 
  <publisher value="HL7 (FHIR Project)"/> 
  <contact> 
    <telecom> 
      <system value="url"/> 
      <value value="http://hl7.org/fhir"/> 
    </telecom> 
    <telecom> 
      <system value="email"/> 
      <value value="fhir@lists.hl7.org"/> 
    </telecom> 
  </contact> 
  <description value="This operation accepts a message, processes it according to the definition of the event
   in the message header, and returns a one or more response messages.  This  operation is
   described in detail [on the messaging page](messaging.html#process)"/> 
  <code value="process-message"/> 
  <comment value="This operation does not use the parameters resource; the parameters &quot;async&quot;
   and &quot;response-url&quot; always go in the URL, if they are used, and the message parameter
   is always the body of the HTTP message"/> 
  <resource value="MessageHeader"/> 
  <system value="true"/> 
  <type value="false"/> 
  <instance value="false"/> 
  <parameter> 
    <name value="content"/> 
    <use value="in"/> 
    <min value="1"/> 
    <max value="1"/> 
    <documentation value="The message to process (or, if using asynchronous messaging, it may be a response message
     to accept)"/> 
    <type value="Bundle"/> 
  </parameter> 
  <parameter> 
    <name value="async"/> 
    <use value="in"/> 
    <min value="0"/> 
    <max value="1"/> 
    <documentation value="If 'true' the message is processed using the asynchronous messaging pattern"/> 
    <type value="boolean"/> 
  </parameter> 
  <parameter> 
    <name value="response-url"/> 
    <use value="in"/> 
    <min value="0"/> 
    <max value="1"/> 
    <documentation value="A URL to submit response messages to, if asynchronous messaging is being used, and if
     the MessageHeader.source.endpoint is not the appropriate place to submit responses"/> 
    <type value="uri"/> 
  </parameter> 
  <parameter> 
    <name value="return"/> 
    <use value="out"/> 
    <min value="0"/> 
    <max value="1"/> 
    <documentation value="A response message, if synchronous messaging is being used (mandatory in this case). For
     asynchronous messaging, there is no return value"/> 
    <type value="Bundle"/> 
  </parameter> 
</OperationDefinition> 

Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.