FHIR Chat · latest publisher /template is rendering duplicate content · IG creation

<!--  <p>
  Formats: <a href="{{[type]}}-{{[id]}}.xml.html">XML</a>, <a href="{{[type]}}-{{[id]}}.json.html">JSON</a>, <a href="{{[type]}}-{{[id]}}.ttl.html">Turtle</a>
  </p>-->

{% comment %} **********This  bit needs to be moved or removed *********** {% endcomment %}
{% unless example %}
  {% if '{{[type]}}' == 'CapabilityStatement' %}
  <p>
      <a href="{{[id]}}.openapi.json" no-download="true">Raw OpenAPI-Swagger Definition file</a> | <a href="{{[id]}}.openapi.json" download>Download</a>
  </p>
  {% endif %}
{% endunless %}
{% comment %} **************************************** *********** {% endcomment %}
  {% include {{[type]}}-{{[id]}}-html.xhtml %}

  {% include {{[type]}}-{{[id]}}-html.xhtml %}

{% raw %}<div xmlns="http://www.w3.org/1999/xhtml"><h2>SubmitAttachment</h2><p>OPERATION: SubmitAttachment</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/us/davinci-cdex/OperationDefinition/submit-attachment</pre><div><p><strong>The following content is DRAFT, because it has not yet undergone HL7 balloting.</strong></p>
<p>This operation is used to submit attachments for Claims or Prior Authorization. This operation accepts the clinical attachments and the necessary information needed to re-attach them to the claim or prior authorization, and returns a transaction layer HTTP response.  This operation can be used by any HTTP end-point, not just FHIR RESTful servers.</p>
<p>The input parameters are:</p>
<ol>
<li>One or more Attachments as FHIR Resources</li>
<li>Data elements for reassociation to the Claim/Prior Authorization
<ul>
<li>What are the attachments for:
<ul>
<li>Claim</li>
<li>Prior Authorization</li>
</ul>
</li>
<li>A unique claim/prior authorization identifier*</li>
<li>Optionally, one or more unique claim line item identifiers</li>
<li>A unique organization/location identifier (e.g., NPI)</li>
<li>A unique provider identifier (e.g., NPI)</li>
<li>A unique Patient member identifier</li>
</ul>
</li>
</ol>
<p>There are no output parameters.</p>
</div><p>URL: [base]/$submit-attachment</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>AttachTo</td><td>1..1</td><td><a href="http://hl7.org/fhir/R4/datatypes.html#code">code</a></td><td><a href="ValueSet-cdex-attachment-reason.html">http://hl7.org/fhir/us/davinci-cdex/ValueSet/cdex-attachment-reason</a> (Required)</td><td><div><p>Whether the additional information is needed for a claim (unsolicited or solicited) or for prior authorization.</p>
</div></td></tr><tr><td>IN</td><td>TargetId</td><td>1..1</td><td><a href="http://hl7.org/fhir/R4/datatypes.html#Identifier">Identifier</a></td><td/><td><div><p>Claim/prior authorization identifier value. This can be either a filler or placer id*.</p>
</div></td></tr><tr><td>IN</td><td>ItemId</td><td>0..*</td><td><a href="http://hl7.org/fhir/R4/datatypes.html#string">string</a></td><td/><td><div><p>Claim/prior authorization identifier that uniquely reference an line item in the context of the claim or prior authorization. This can be either a filler or placer id*.</p>
</div></td></tr><tr><td>IN</td><td>OrganizationId</td><td>1..1</td><td><a href="http://hl7.org/fhir/R4/datatypes.html#Identifier">Identifier</a></td><td/><td><div><p>Sending organization/location Identifier (e.g., NPI)</p>
</div></td></tr><tr><td>IN</td><td>ProviderId</td><td>1..1</td><td><a href="http://hl7.org/fhir/R4/datatypes.html#Identifier">Identifier</a></td><td/><td><div><p>Sending provider identifier (e.g., NPI)</p>
</div></td></tr><tr><td>IN</td><td>MemberId</td><td>1..1</td><td><a href="http://hl7.org/fhir/R4/datatypes.html#Identifier">Identifier</a></td><td/><td><div><p>Patient member identifier</p>
</div></td></tr><tr><td>IN</td><td>Attachment</td><td>1..*</td><td><a href="http://hl7.org/fhir/R4/resource.html">Resource</a></td><td/><td><div><p>The actual attachments as FHIR resources for Claims or Prior Authorization.  Note that non-FHIR data formats are attached to or referenced by DocumentReference.  Servers <strong>SHALL</strong> support  DocumentReference resource type and <strong>SHOULD</strong> support other types.</p>
</div></td></tr></table><div><p>*Note that an Unsolicited Claim implies that the <em>provider</em> assigns the claim identifier (in other words, a &quot;placer identifier&quot;) when the attachments are sent upon claim generation. Solicited Claims imply that the <em>payer</em> assigned the Claim identifier (in other words, a &quot;filler identifier&quot;) upon receipt of a claim, and that the attachments are in response to a payer request for additional information.  Similarily for Prior Authorization, the the prior auth identifier is <em>provider</em> assigned when the attachments are sent upon prior auth generation, and the prior auth identifier is the <em>payer</em> assigned when the attachments are in response to a request for additional information by the payer.</p>
<p>The following rules apply when using <code>$submit-attachment</code>:</p>
<ul>
<li>The operation only accepts <code>POST</code> transactions - any other HTTP method will result in an HTTP error</li>
<li>For the <code>Attachment</code> parameter, Servers <strong>SHALL</strong> support  DocumentReference resource type and <strong>SHOULD</strong> support other types.
<ul>
<li>The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using <code>DocumentReference.attachment.url</code> or the content as inline base64 encoded data using <code>DocumentReference.attachment.data</code>.  The server system is not required to support both an address and inline base64 encoded data, but <strong>SHALL</strong> support at least one of these elements.</li>
<li>These capabilities <strong>SHOULD</strong> be discoverable and documented by the server (for example, in the CapabilityStatement for FHIR Servers).</li>
</ul>
</li>
<li>When processing messages, a server may return one of several status codes:
<ul>
<li><strong>200 OK</strong>: Indicates that the server has accepted the clinical attachments.</li>
<li><strong>4xx</strong>: Indicates some error in the submission. The client <strong>SHOULD</strong> interpret a 4xx response to indicate that there is no point resubmitting the unaltered operation,</li>
<li><strong>5xx</strong>: Indicates some system error. The client <strong>SHOULD</strong> interpret a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original operation.</li>
<li>The server <strong>MAY</strong> return an <a href="http://hl7.org/fhir/operationoutcome.html">OperationOutcome</a> with additional information, and <strong>SHOULD</strong> do so if the response code is 400 or greater. For example, if the payer has no knowledge of the claim or prior authorization, the OperationOurtcome can alert submitter to check whether they sent it to the wrong payer.</li>
</ul>
</li>
</ul>
<p>See the the <a href="attachments.html">Attachments</a> page for additional guidance and examples.</p>
</div></div>{%  %}