CDex Task Attachment Request Profile

Payers use this Task based profile to request additional documentation ("attachments") for claims or prior authorizations. It constrains the Task resource to minimal necessary data elements needed to request attachments and respond in a way that is compatible with existing X12 277 RFAI and 278 response transactions to allow for association and requests for (typically PDF and CCDA) documents using LOINC and X12 standard codes. It also supports requests for more detailed missing data using Questionnaire, CQL, and QuestionnaireResponse, as supported by Da Vinci DTR.

It constrains the following elements to be *mandatory* (min=1):

• A contained Patient Resource defined by the CDex Patient Demographics Profile and communicating additional patient demographic data elements.
• A contained PractitionerRole Resource defined by the CDex PractitionerRole Profile to communicate the provider ID as either a unique organization/location identifier (e.g., Type 2 NPI) or unique provider identifier (e.g., Type 1 NPI) or both.
• A `Task.identifier` element representing the payers tracking identifier (referred to as the “re-association tracking control numbers”)
• A `Task.status` with a required binding to HRex Task Status ValueSet (this element is a mandatory Task element). For guidance when the provider cannot complete the Task, refer to the When The Task Cannot Be Completed section.
• A `Task.intent` element that is fixed to "order" (this element is a mandatory Task element)
• A `Task.code` of either "attachment-request-code" or "attachment-request-questionnaire" communicating that the Payer is requesting attachments for a claim or prior authorization using a code or data request questionnaire.

- If the code is "attachment-request-code", the provider system returns attachment(s) identified by the attachment code(s) in the "AttachmentsNeeded" input parameter. - If the code is "attachment-request-questionnaire", the provider system uses Documentation Templates and Rules (DTR) to complete the Questionnaire(s) referenced in the "QuestionnaireContext" input parameter. - When either code is present, the provider system uses the $submit-attachment operation to return the information to the endpoint provided in the "PayerUrl" input parameter.

• A `Task.requester`.identifier element representing the Payer ID
• A `Task.owner`.reference element that is fixed to "\#practionerrole" - a reference to the contained PractitionerRole Resource that represents the Provider ID.
• A `Task.for`.reference element that is fixed to "\#patient" - a reference to the contained Patient Resource that represents patient demographic data.
• A `Task.reasonCode` to communicate whether the attachments are for a claim or prior authorization.
• A `Task.reasonReference`.reference referencing the claim or prior authorization ID (business Identifier).
• A "PayerUrl" `Task.input` element representing the Payer endpoint URL the provider uses when submitting attachments with the `$submit-attachment` operation.

It constrains the following elements to be *must support* (min=0):

• A `Task.Restriction.period` element representing the due date for submitting the attachments
• A `Task.statusReason.text` to communicate the reason for the status (for example, if the Task is rejected or failed)
• A "AttachmentsNeeded" `Task.input` element to communicate to the provider what attachments are needed using LOINC or X12 attachment codes.*
• A "AttachmentsNeeded" or "QuestionnaireContext" `Task.input` element extension that communicates claim or prior authorization line item numbers associated with the attachment or questionnaire.
• A "signature" `Task.input` element. This is a flag to indicate whether the requested data requires a signature. For more information about requiring and requesting signatures, refer to the Signatures section.
• A "service-date" `Task.input` element representing the date of service or starting date of the service for the claim or prior authorization. It SHALL be present if the attachment is for a claim.

It defines the following *optional* elements:

• A "QuestionnaireContext" Task.input element to communicate to the provider a URL of a data request FHIR Questionnaire that conforms to the DTR Standard Questionnaire Profile or the DTR Questionnaire for Adaptive Form Profile.*

- A questionnaireDisplay extension to communicate the display name of the Questionnaire

• A "POU" `Task.input` element that is used to indicate the purpose of use (POU) for the requested data using an extensible CDex Purpose of Use Value Set. Refer to the Purpose of Use section For more information about sending purpose POU codes.
• A "multiple-submits" `Task.input` element that is a flag to indicate whether the requested data can be sent in multiple submissions
• A "AttachmentsNeeded" `Task.output` element that references the result(s) of the data request code.
• A "QuestionnaireContext" `Task.output` element which references the FHIR QuestionnaireResponse resulting from the data request Questionnaire. The QuestionnaireResponse conforms to the CDex SDC QuestionnaireResponse Profile or the SDC Adaptive Questionnaire Response Profile.

\* Either a "AttachmentsNeeded" or a "QuestionnaireContext" `Task.input` element is required