STU 3 Candidate

This page is part of the FHIR Specification (v1.4.0: STU 3 Ballot 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

Raw XML (canonical form)

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>
      <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="2016-03-31T08:01:25+11:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="other"/>
      <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"/>
  <system value="true"/>
  <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.