This page is part of the Da Vinci Clinical Documentation Exchange (v2.0.0-ballot: STU2 Ballot 1) 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
Official URL: http://hl7.org/fhir/us/davinci-cdex/OperationDefinition/submit-attachment | Version: 2.0.0-ballot | |||
Draft as of 2021-12-02 | Computable Name: SubmitAttachment |
This operation is used to submit attachments (additional documentation) for claims or prior authorization. This operation accepts the clinical/administrative attachments and the necessary information needed to associate them to the claim or prior authorization and returns a transaction layer HTTP response. The operation may be invoked before, at the same time as, or after the claim or pre-authorization has been supplied to the Payer. This operation can be used by any HTTP endpoint, not just FHIR RESTful servers.
The input parameters are:
There are no output parameters.
The following page is DRAFT and open for review
OPERATION: SubmitAttachment
The official URL for this operation definition is:
http://hl7.org/fhir/us/davinci-cdex/OperationDefinition/submit-attachment
This operation is used to submit attachments (additional documentation) for claims or prior authorization. This operation accepts the clinical/administrative attachments and the necessary information needed to associate them to the claim or prior authorization and returns a transaction layer HTTP response. The operation may be invoked before, at the same time as, or after the claim or pre-authorization has been supplied to the Payer. This operation can be used by any HTTP endpoint, not just FHIR RESTful servers.
The input parameters are:
There are no output parameters.
URL: [base]/$submit-attachment
Parameters
Use | Name | Cardinality | Type | Binding | Documentation |
IN | TrackingId | 1..1 | string | An identifier that ties the attachment(s) back to the claim or prior authorization. This value is referred to as the "tracking control number" In unsolicited claim attachments, the provider assigns the tracking control number on the claim and also on the submitted attachments for that claim for association. In solicited claim attachments, the payer assigns the tracking control number and sends it to the provider with the request for additional information for that specific claim. Similarly, for prior authorizations, the prior-auth tracking control number is provider assigned when the attachments are sent upon prior auth generation as unsolicited attachments, and the prior auth tracking control number is assigned and communicated by the payer when the attachments are in response to a request for additional documentation. | |
IN | AttachTo | 1..1 | code | http://hl7.org/fhir/us/davinci-cdex/ValueSet/cdex-claim-use (Required) | A value of either "claim" or "preauthorization" to communicate what the additional information is needed for. This is known by the provider when submitting unsolicited attachments and communicated to the provider through the request for solicited attachments. |
IN | PayerId | 0..1 | Identifier | The receiving payer identifier. It may be required, because the endpoint may support multiple payers. Currently, there is no standard way to obtain the payer identifiers and implementers will need to obtain them “out of band” when submitting unsolicited attachments. For solicited attachments this value is communicated to the provider through the request. | |
IN | OrganizationId | 1..1 | Identifier | Sending organization/location identifier (e.g., NPI). This is assumed to be known by the provider when submitting unsolicited attachments. For solicited attachments this value is communicated to the provider through the request. | |
IN | ProviderId | 1..1 | Identifier | Sending provider identifier (e.g., NPI). This is assumed to be known by the provider when submitting unsolicited attachments. For solicited attachments this value is communicated to the provider through the request. | |
IN | MemberId | 1..1 | Identifier | Patient member identifier. This is assumed to be known by the provider when submitting unsolicited attachments. For solicited attachments this value is communicated to the provider through the request. This identifier can be either the Payer assigned Member ID or a provider assigned "Patient Account Number" for an unsolicited attachment for prior authorization. | |
IN | ServiceDate | 0..1 | dateTime | 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 prior authorization. This is assumed to be known by the provider when submitting unsolicited attachments. For solicited attachments this value is communicated to the provider through the request. | |
IN | Attachment | 0..* | The attachments that are communicated for a claim or prior authorization. They are applied to the ItemId (line items) and/or Code (LOINC) parameters if present. If no ItemId is present, then the attachment is applied to the entire claim or prior authorization. | ||
IN | Attachment.LineItem | 0..* | string | Claim/prior authorization line item for service in the claim or prior authorization. It may be present when submitting unsolicited attachments. For a solicited claim or claim authorization attachment, this value is the same as the line items communicated in the request. | |
IN | Attachment.Code | 0..1 | CodeableConcept | http://loinc.org/vs/valid-hl7-attachment-requests (Extensible) | LOINC code to identify the specific kind of information being communicated (e.g., a discharge summary or diagnostic imaging report). This value set includes LOINC terms that can be sent by a payer as part of an HL7 attachment request for additional information. It has been curated by the HL7 Payer/Provider Information Exchange (PIE) Work Group. More information about using LOINC in HIPAA attachments and the source of this value set can be found at https://loinc.org/attachments/. It SHOULD be present when submitting unsolicited attachments. For solicited attachments, this value is the same as the LOINC communicated in the request. |
IN | Attachment.Content | 1..1 | Resource | Attachment as a FHIR resource. Non-FHIR attachment data is conveyed using the DocumentReference or Binary resource. Servers SHALL support DocumentReference resource type and SHOULD support other types. | |
IN | Final | 0..1 | boolean | Flag to indicate whether the operation is the last attachment submission (solicited or unsolicited) for the claim or prior authorization. If Final = "true", the Data Source has no more attachments to submit. This is the default meaning if this parameter is omitted. If Final = "false", the Data Source expects to submit more attachments in subsequent operations. Payers typically anticipate a single submission and may discourage multiple submissions. |
The following rules apply when using $submit-attachment
:
POST
transactions - any other HTTP method SHALL result in an HTTP error.Attachment.ItemID
and Attachment.Code
parameters are associated with the attachments in Attachment.Content
. If Attachment.ItemID
is not present, then the attachment is associated with the entire claim or prior authorization.Attachment.Content
parameter, Servers SHALL support DocumentReference resource type and SHOULD support other types.
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.Final
parameter is omitted is Final="true" - the operation is the last attachment submission (solicited or unsolicited) for the claim or prior authorization.See the Attachments page for additional guidance and examples.