Da Vinci Clinical Data Exchange (CDex)
2.0.0 - STU2 United States of America flag

This page is part of the Da Vinci Clinical Documentation Exchange (v2.0.0: STU2) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

OperationDefinition: Submit Attachment Operation

Official URL: http://hl7.org/fhir/us/davinci-cdex/OperationDefinition/submit-attachment Version: 2.0.0
Standards status: Trial-use Maturity Level: 2 Computable Name: SubmitAttachment

Copyright/Legal: Used by permission of HL7 International all rights reserved Creative Commons License

Providers use this operation to submit solicited and unsolicited attachments or additional information for claims or prior authorization. The $submit-attachment operation accepts the clinical/administrative attachments and the necessary information to associate them with the claim or prior authorization and returns an HTTP response. For unsolicited attachments, the Provider invokes this operation before, concurrently, or after the claim or pre-authorization transaction. For solicited attachments, the Provider invokes it when responding to a Payer request for attachments or additional information. Any HTTP endpoint can use $submit-attachment, not just FHIR RESTful server endpoints.

The input parameters are:

  1. One or more attachments as FHIR Resources
    • Optionally, one or more unique line item numbers associated with the attachment
    • Optionally, the attachment code used to request for the information
  2. Data elements for the association to the claim/prior authorization
    • A unique identifier that ties the attachment(s) back to the claim or prior authorization. (referred to as the “re-association tracking control numbers”)*
    • What are the attachments for:
      • Claims
      • Prior Authorizations
    • Optionally, a unique payer identifier
    • A unique organization/location identifier (e.g., Type 2 NPI) and/or unique provider identifier (e.g., Type 1 NPI)
    • A unique Patient member identifier
    • A Date of Service
    • A Flag indicating whether the operation is the last attachment submission for the claim or prior authorization.

There are no output parameters.

URL: [base]/$submit-attachment

Parameters

UseNameScopeCardinalityTypeBindingDocumentation
INTrackingId1..1Identifier

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.

INAttachTo1..1codeCDex Claim Use Value Set (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.

INPayerId0..1Identifier

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.

INOrganizationId0..1Identifier

Sending organization/location identifier (e.g., Type 2 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. A ProviderId parameter or OrganizationId parameter or both SHALL be present.

INProviderId0..1Identifier

Sending provider identifier (e.g.,Type 1 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. A ProviderId parameter or OrganizationId parameter or both SHALL be present.

INMemberId1..1Identifier

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.

INServiceDate0..1dateTime

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.

INAttachment1..*

The attachments that are communicated for a claim or prior authorization. They are applied to the LineItem (line items) and/or Code (LOINC) parameters if present. If no LineItem is present, then the attachment is applied to the entire claim or prior authorization.

INAttachment.LineItem0..*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.

INAttachment.Code0..1CodeableConcepthttp://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 when requesting attachments using attachments codes. When requesting attachments using Questionnaire, there is no code in the request and the code is typically not present in the response.

INAttachment.Content1..1Resource

Attachment as a FHIR resource. Non-FHIR attachment data is conveyed using the DocumentReference or Binary resource. Servers SHALL support the DocumentReference resource type and SHOULD support other types. If Servers support requesting attachments with Questionnaire, then the SDC Questionnaire Response Profile SHALL be supported and the SDC Adaptive Questionnaire Response Profile SHOULD be supported.

INFinal0..1boolean

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:

  • The operation's endpoint SHALLonly accept POST transactions - any other HTTP method SHALL result in an HTTP error.
  • A ProviderId parameter or OrganizationId parameter or both SHALL be present.
  • 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 prior authorization.
  • The Attachment.LineItem and Attachment.Code parameters are associated with the attachments in Attachment.Content. If Attachment.LineItem is not present, then the attachment is associated with the entire claim or prior authorization.
  • For the Attachment.Content parameter, Servers SHALL support DocumentReference resource type and SHOULD support other types. If Servers support requesting attachments with Questionnaire, then the SDC Questionnaire Response Profile SHALL be supported and the SDC Adaptive Questionnaire Response Profile SHOULD be supported.
    • 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).
  • The default meaning when the Final parameter is omitted is Final="true" - the operation is the last attachment submission (solicited or unsolicited) for the claim or prior authorization.
  • When processing the operation, a server may return one of several status codes:
    • 200 OK: Indicates that the server has accepted the clinical attachments.
      • If the attachments can not be associated with an existing claim or member, the server SHOULD return an OperationOutcome to inform the Data Source that the attachments are being held for a subsequent association to a claim or prior authorization.
    • 4xx: Indicates some error in the submission. The client SHOULD interpret a 4xx response to indicate that there is no point in 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 SHOULD return an OperationOutcome with additional error information if the response code is 400 or greater. For example, if the payer does not know the claim or prior authorization, the OperationOutcome can alert the submitter to check whether they sent it to the wrong payer.

See the Attachments page for additional guidance and examples.