This page is part of the Da Vinci Clinical Documentation Exchange (v1.0.0: STU1) based on FHIR R4. The current version which supercedes this version is 1.1.0. For a full list of available versions, see the Directory of published versions
Draft as of 2021-12-02 |
<OperationDefinition xmlns="http://hl7.org/fhir">
<id value="submit-attachment"/>
<text>
<status value="extensions"/>
<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>This operation is used to submit attachments (aditional information) for Claims or Prior Authorization. This operation accepts the clinical/administrative attachments and the necessary information needed to re-associate them to the claim or prior authorization, and returns a transaction layer HTTP response. This operation can be used by any HTTP endpoint, 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 is the documentation for:
<ul>
<li>Claim</li>
<li>Prior Authorization</li>
</ul>
</li>
<li>A unique claim/prior authorization identifier (referred to as the "re-association tracking control numbers")*</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>
<li>Date of Service</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#string">string</a></td><td/><td><div><p>Claim/prior authorization identifier value referred to as the "re-association tracking control numbers"*</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 a line item in the context of the claim or prior authorization.</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>ServiceDate</td><td>0..1</td><td><a href="http://hl7.org/fhir/R4/datatypes.html#date">date</a></td><td/><td><div><p>Date of service or starting date of the service for the claim or prior authorization. This parameter <strong>SHALL</strong> be present and precise to the day if the attachment is for a claim. It is optional if the attachment is for a prior authorization.</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 attachment implies that the provider assigns the tracking control number on the claim and also on the submitted attachments for that claim for re-association. Solicited Claim attachments are when the payer assigns the Claim control number and sends the provider a request for additional information for that specific claim. Similarly for Prior Authorization, the prior auth identifier is provider assigned when the attachments are sent upon prior auth generation, and the prior auth identifier is the payer assigned control number 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>The ServiceDate parameter <strong>SHALL</strong> be present and precise to the day if the attachment is for a claim. It is optional if the attachment is for a prior authorization.</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 <a href="attachments.html">Attachments</a> page for additional guidance and examples.</p>
</div></div>
</text>
<url
value="http://hl7.org/fhir/us/davinci-cdex/OperationDefinition/submit-attachment"/>
<version value="1.0.0"/>
<name value="SubmitAttachment"/>
<title value="Submit Attachment Operation"/>
<status value="draft"/>
<kind value="operation"/>
<date value="2021-12-02T20:24:41-08:00"/>
<publisher value="HL7 International - Patient Care Work Group"/>
<contact>
<name value="HL7 International - Patient Care Work Group"/>
<telecom>
<system value="url"/>
<value value="http://www.hl7.org/Special/committees/patientcare"/>
</telecom>
<telecom>
<system value="email"/>
<value value="patientcare@lists.HL7.org"/>
</telecom>
</contact>
<description
value="This operation is used to submit attachments (aditional information) for Claims or Prior Authorization. This operation accepts the clinical/administrative attachments and the necessary information needed to re-associate them to the claim or prior authorization, and returns a transaction layer HTTP response. This operation can be used by any HTTP endpoint, not just FHIR RESTful servers.
The input parameters are:
1. One or more Attachments as FHIR Resources
1. Data elements for reassociation to the Claim/Prior Authorization
- What is the documentation for:
- Claim
- Prior Authorization
- A unique claim/prior authorization identifier (referred to as the "re-association tracking control numbers")*
- Optionally, one or more unique claim line item identifiers
- A unique organization/location identifier (e.g., NPI)
- A unique provider identifier (e.g., NPI)
- A unique Patient member identifier
- Date of Service
There are no output parameters."/>
<jurisdiction>
<coding>
<system value="urn:iso:std:iso:3166"/>
<code value="US"/>
</coding>
</jurisdiction>
<code value="submit-attachment"/>
<comment
value="\*Note that an Unsolicited Claim attachment implies that the provider assigns the tracking control number on the claim and also on the submitted attachments for that claim for re-association. Solicited Claim attachments are when the payer assigns the Claim control number and sends the provider a request for additional information for that specific claim. Similarly for Prior Authorization, the prior auth identifier is provider assigned when the attachments are sent upon prior auth generation, and the prior auth identifier is the payer assigned control number when the attachments are in response to a request for additional information by the payer.
The following rules apply when using `$submit-attachment`:
* The operation only accepts `POST` transactions - any other HTTP method will result in an HTTP error
* The ServiceDate parameter **SHALL** be present and precise to the day if the attachment is for a claim. It is optional if the attachment is for a prior authorization.
* For the `Attachment` parameter, Servers **SHALL** support DocumentReference resource type and **SHOULD** support other types.
* The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using `DocumentReference.attachment.url` or the content as inline base64 encoded data using `DocumentReference.attachment.data`. The server system is not required to support both an address and inline base64 encoded data, but **SHALL** support at least one of these elements.
* These capabilities **SHOULD** be discoverable and documented by the server (for example, in the CapabilityStatement for FHIR Servers).
* When processing messages, a server may return one of several status codes:
* **200 OK**: Indicates that the server has accepted the clinical attachments.
* **4xx**: Indicates some error in the submission. The client **SHOULD** interpret a 4xx response to indicate that there is no point resubmitting the unaltered operation,
* **5xx**: Indicates some system error. The client **SHOULD** 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.
* The server **MAY** return an [OperationOutcome](http://hl7.org/fhir/operationoutcome.html) with additional information, and **SHOULD** 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.
See the [Attachments](attachments.html) page for additional guidance and examples.
"/>
<resource value="Claim"/>
<system value="true"/>
<type value="false"/>
<instance value="false"/>
<parameter>
<name value="AttachTo"/>
<use value="in"/>
<min value="1"/>
<max value="1"/>
<documentation
value="Whether the additional information is needed for a claim (unsolicited or solicited) or for prior authorization."/>
<type value="code"/>
<binding>
<strength value="required"/>
<valueSet
value="http://hl7.org/fhir/us/davinci-cdex/ValueSet/cdex-attachment-reason"/>
</binding>
</parameter>
<parameter>
<name value="TargetId"/>
<use value="in"/>
<min value="1"/>
<max value="1"/>
<documentation
value="Claim/prior authorization identifier value referred to as the "re-association tracking control numbers"*"/>
<type value="string"/>
</parameter>
<parameter>
<name value="ItemId"/>
<use value="in"/>
<min value="0"/>
<max value="*"/>
<documentation
value="Claim/prior authorization identifier that uniquely reference a line item in the context of the claim or prior authorization."/>
<type value="string"/>
</parameter>
<parameter>
<name value="OrganizationId"/>
<use value="in"/>
<min value="1"/>
<max value="1"/>
<documentation value="Sending organization/location Identifier (e.g., NPI)"/>
<type value="Identifier"/>
</parameter>
<parameter>
<name value="ProviderId"/>
<use value="in"/>
<min value="1"/>
<max value="1"/>
<documentation value="Sending provider identifier (e.g., NPI)"/>
<type value="Identifier"/>
</parameter>
<parameter>
<name value="MemberId"/>
<use value="in"/>
<min value="1"/>
<max value="1"/>
<documentation value="Patient member identifier"/>
<type value="Identifier"/>
</parameter>
<parameter>
<name value="ServiceDate"/>
<use value="in"/>
<min value="0"/>
<max value="1"/>
<documentation
value="Date of service or starting date of the service for the claim or prior authorization. This parameter **SHALL** be present and precise to the day if the attachment is for a claim. It is optional if the attachment is for a prior authorization."/>
<type value="date"/>
</parameter>
<parameter>
<name value="Attachment"/>
<use value="in"/>
<min value="1"/>
<max value="*"/>
<documentation
value="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 **SHALL** support DocumentReference resource type and **SHOULD** support other types."/>
<type value="Resource"/>
</parameter>
</OperationDefinition>