Payers use the 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 as the standard. 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 is not able to complete the Task, refer to the When The Task Cannot Be Completed section.
• A Task.intent 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 LOINC attachment code(s) in the “code” input parameter.
  • If the code is “attachment-request-questionnaire”, the provider system uses Documentation Templates and Rules (DTR) to complete the Questionnaire referenced in the “questionnaire” input parameter.
  • When either code is present, the provider system uses the $submit-attachment operation to return the information to the endpoint provided in “payer-url” input parameter.
• A Task.requester.identifier element representing the Payer ID
• A Task.owner.reference element fixed to “#practionerrole” - a reference the contained PractitionerRole Resource that represents the Provider ID.
• A Task.for.reference element fixed to “#patient” - a reference the contained Patient Resource that represents basic 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 “payer-url” Task.input element representing the Payer endpoint URL to communicate to the provider to submit the attachments using the $submit-attachment operation

It constrains 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 “code” Task.input element to communicate to the provider what attachments are needed using LOINC attachment codes.*
• A “code” or “questionnaire” Task.input element extension representing a claim or prior authorization line item numbers associated with the attachment or questionnaire.
• ​A “signature” Task.input element representing 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 elements to be optional:

• A “questionnaire” Task.input element to communicate to the provider a URL of a data request FHIR Questionnaire that conforms to the DTR SDC Questionnaire Profile or the DTR SDC Questionnaire for Adaptive Form Profile.*
  • A questionnaireDisplay extension to communicate the display name of the Questionnaire
• ​A “POU” Task.input element representing the purpose of use (POU) for the requested data using an extensible CDex Purpose of Use Value Set. For more information about sending purpose POU codes, refer to the Purpose of Use section.
• A “multiple-submits” Task.input element representing a flag to indicate whether the requested data can be sent in multiple submissions
• A “data-value” Task.output element referring to FHIR resource(s) representing the result(s) of the data request code.
• A “response” Task.output element which is a local reference to the FHIR QuestionnaireResponse resulting from the data request Questionnaire. The QuestionnaireResponse conforms to the SDC Questionnaire Response Profile or the SDC Adaptive Questionnaire Response Profile.

* Either a “code” or a “questionnaire” Task.input element is required

This Profile is defined to be contained within the CDex Task Attachment Request Profile. It is referenced by Task.owner 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. It constrains the following elements to be must support (min=0).:

• A default resource ID of “practitionerrole”
• A practitioner.identifier:
• An organization.identifier:

At least a practitioner identifier or organization identifier SHALL be present.

This Profile is defined to be contained within the CDex Task Attachment Request Profile or CDex Task Data Request Profile. It is referenced when additional patient demographic data is communicated for a clinical data request (for example, to verify patient identity for HIPAA compliance regulations). It constrains the following elements to be mandatory (min=1):

• A default resource ID of “patient”
• A member ID identifier slice
• A patient’s name

and the following element to be must support (min=0):

• A patient account number identifier slice
• A date of birth

​The Parameters profile for Da Vinci Submit Attachment Operation

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.

Codes used to identify the type of attachment request and control the payer system’s behavior.

The purpose of a Claim resource and the reason for attachments. It includes the codes “preauthorization” and “claim”.

Claim Attachment Request Example: Claim Attachment Request sent by payer to a provider requesting a signed Progress note (H&P) note

Prior-Auth Attachment Request Example: Prior Authorization Attachment Request with a POU of “coverage authorization” sent by payer to a provider requesting a signed History and physical (H&P) note.

Request Additional Data using a Questionnaire: Prior Authorization Attachment Request with a POU of “coverage authorization” sent by payer to a provider requesting a data request questionnaire be completed.

Request Additional Data using an Adaptive Questionnaire: Prior Authorization Attachment Request with a POU of “coverage authorization” sent by payer to a provider requesting an adaptive questionnaire be completed.

Completed Request for Additional Data using a Questionnaire: Completed Task for CDex Task Example 22. This example has a status of “completed” and a “lastModified” date of 6/17/2022. The “reasonCode” is “request additional data” and the “output” is a QuestionnaireResponse.

Completed Request for Additional Data Using an Adaptive Questionnaire: Completed Task for CDex Task Example 23. This example has a status of “completed” and a “lastModified” date of 6/17/2022. The “reasonCode” is “request additional data” and the “output” is a QuestionnaireResponse.

Request Additional Data Requiring a Verification Signature Using a Questionnaire: Prior Authorization Attachment Request with a POU of “coverage authorization” and Signature required sent by payer to a provider requesting a data request questionnaire be completed and signed.

Completed Request for Additional Data Requiring a Verification Signature Using a Questionnaire: Completed Prior Authorization Attachment Request (CDex Task Example 28) with a status of “completed” and output referencing the digitally signed QuestionnaireResponse.

CCDA Attachment Example: Parameters Resource example showing how it is used to submit attachments using the $submit-attachment operation. It contains a CCDA attachment and the necessary information needed to associate them to the claim.

Signed FHIR Document Attachment Example: Parameters Resource example showing how it is used to submit attachments using the $submit-attachment operation. It contains a Signed FHIR Document attachment and the necessary information needed to associate it to a claim.

PDF Attachment Example: Parameters Resource example showing how it is used to submit attachments using the $submit-attachment operation. It contains a PDF attachment and the necessary information needed to associate them to the claim.

Laboratory Results Attachment Example: Parameters Resource example showing how it is used to submit multiple attachments using the $submit-attachment operation. It contains 3 Hemoglobin A1c results as attachments and the necessary information needed to associate them to the claim.

Completed QuestionnaireResponse Attachment Example: Parameters Resource example showing how it is used to submit a solicited attachment using the $submit-attachment operation. The attachment parameter payload is a QuestionnaireResponse completed using DTR in response to a Questionnaire sent in the Attachments request.

This Task profile is used to solicit information from a system. The Data Consumer uses it when direct query transactions are not an option, and the transaction may require human intervention. It represents both the data request and the returned “data request”. Data requests are supplied as codes, free-text, or FHIR Restful queries. It can also support 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 Task.status with a required binding to HRex Task Status ValueSet (this element is a mandatory Task element). For guidance when the provider is not able to complete the Task, refer to the When The Task Cannot Be Completed section.
• A Task.intent fixed to “order” (this element is a mandatory Task element)
• A Task.code of either “data-request-code”, “data-request-code”, or “data-request-questionnaire” communicating that the Data Consumer is requesting data using a code(or free text), a FHIR RESTful query, or a data request questionnaire.
  • If the code is “data-request-query”, the provider system returns data(s) identified by the FHIR RESTful query in the “query” input parameter.
  • If the code is “data-request-code”, the provider system returns data(s) identified by the LOINC code in the “code” input parameter.
  • If the code is “data-request-questionnaire”, the provider system uses Documentation Templates and Rules (DTR) to complete the Questionnaire referenced in the “questionnaire” input parameter.
• A Task.for element representing the member (i.e.,patient) for whom the data is being requested
• A Task.requester element communicating who is requesting the data
• A Task.owner element representing the Provider who is being asked to provide the data

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

• A Task.identifier element representing the unique data request identifier
• A Task.basedOn element to communicate the order (ServiceRequest, CommunicationRequest, etc.) that authorizes the data request
• A Task.statusReason.text to communicate the reason for the status (for example, if the Task is rejected or failed)
• A Task.businessStatus.text element representing the progress in retrieving the data (for example, “waiting on internal review”).
• A Task.for.reference.identifier element representing a patient business identifier like a Member ID
• A Task.requester.reference.identifier element representing the Data Consumer business identifier
• A Task.owner.reference.identifier element representing the Provider business identifier
• A Task.reasonCode.text to communicate why the data is being requested
• A Task.reasonReference.reference.identifier for the claim, pre-auth or coverage business identifier
• A “query” Task.input element to communicate to the provider what information is needed using a FHIR RESTful query.*
• A “code” Task.input element to communicate to the provider what information is needed using a LOINC code.*
  • For the “code” Task.input element, an extensible LOINC® Document types value set to communicate the specific information being requested
• A Task.input element representing a flag to indicate whether the requested data requires a signature
  • A “data” Task.output element referring to FHIR resource(s) representing the result(s) of the data request code.

It defines the following elements to be optional:

• A meta.tag element representing work-queue hints.
• A “questionnaire” Task.input element to communicate to the provider a URL of a data request FHIR Questionnaire that conforms to the DTR SDC Questionnaire Profile or the DTR SDC Questionnaire for Adaptive Form Profile.*
  • A questionnaireDisplay extension to communicate the display name of the Questionnaire
• A Task.input element representing the purpose of use for the requested data using an extensible CDex Purpose of Use Value Set
• A “response” Task.output element which is a local reference to the FHIR QuestionnaireResponse resulting from the data request Questionnaire. The QuestionnaireResponse conforms to the SDC Questionnaire Response Profile or the SDC Adaptive Questionnaire Response Profile.

It prohibits the following elements (max=0):

• Task.focus

* Either a “query”, “code”, or “questionnaire” Task.input element is required

The set work queue tags that the provider may use in their workflow to process requests. This code set is composed of codes defined by this Guide.

Codes used to identify the type of data request and control the payer system’s behavior.

Query String Request for Condition: Task to seek a patient’s active conditions using the CDex Profile query input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Completed Query String Request for Condition: Completed Task to seek a patient active conditions using the CDex Profile query input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Completed Query String Request for Condition with Contained Output: Completed Task to seek a patient active conditions using the CDex Profile query input and using a contained resource for the output data. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Free Text Request for Condition: Task to seek a patient active conditions using free text in the CDex Profile code input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Completed Free Text Request for Condition: Completed Task to seek a patient active conditions using free text for the input in the CDex Profile code input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Coded Request for Progress note: Task to seek a patient’s latest Progress notes using the CDex Profile code input. This example illustrates the use of FHIR resource references to the various actors.

Completed Coded Request for Progress note - PDF: Completed Task to seek a patient’’'’s latest Progress notes using the CDex Profile code input. This example illustrates the use of FHIR resource references to the various actors. The output data is a contained DocumentReference with an inline base64 encoded PDF document.

Completed Coded RequestOperative note -CCDA: Completed Task to seek a patient’s Operative notes using the CDex Profile code input. This example illustrates the use of FHIR resource references to the various actors. The output data is a contained DocumentReference with an inline base64 encoded CCDA document.

Failed Coded Request for A1C Results: Task to seek a patient’s HbA1c test results using the CDex Profile query input with a failed status. This example illustrates the use of FHIR resource references to the various actors.

Coded Request for A1C Results: Task to seek a patient’s HbA1c test results using the CDex Profile query input. This example illustrates the use of FHIR resource references to the various actors.

Query String Request for Condition with Authorization: In this provider to provider request, a Task is used to request a patient active conditions using the CDex Profile query input. A reference to a formal authorization is provided. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Completed Query String Request for Condition with Authorization: In this completed provider to provider request, a Task is used to request a patient active conditions using the CDex Profile query input. A reference to a formal authorization is provided. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Free Text Request for Condition with Provenance: Task to seek a patient active conditions and its provenance using free text in the CDex Profile code input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Completed Free Text Request for Condition with Provenance: Completed Task to seek a patient active conditions and its provenance using free text in the CDex Profile code input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Query String Request for Condition with Provenance: Task to seek a patient active conditions and its provenance using query string in the CDex Profile query input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Completed Query String Request for Condition with Provenance: Completed Task to seek a patient active conditions their provenance using the CDex Profile query input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Query String Request for Signed Condition Data: Task to seek a patient active conditions using the CDex Profile query input and using the signature input to indicate a signature is required. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Completed Query String Request for Signed Condition Data: Completed Task to seek a signed patient active conditions. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Coded Request for Surgical Operation Note: Task to seek a patient’s latest operative notes using the CDex Profile code input. This example illustrates the use of FHIR resource references to the various actors.

Data Request Using a Questionnaire: Task to seek reason for home oxygen therapy using the CDex Profile questionnaire input. This example illustrates the use of Questionnaire to request data from a data source

Completed Data Request Using a Questionnaire: Completed Task for CDex Task Example 26. This example has a status of “completed” and a “lastModified” date of 6/19/2022. The “output” is a QuestionnaireResponse.Task to seek reason for home oxygen therapy.

Data Request Requiring a Verification Signature Using Questionnaire: Task to seek reason for home oxygen therapy using the CDex Profile questionnaire input. This example illustrates the use of Questionnaire to request data from a data source and requires a digitally signed QuestionnaireResponse.

Completed Data Request Requiring a Verification Signature Using Questionnaire: Completed Task (CDex Task Example 30) with a status of “completed” and output referencing the digitally signed QuestionnaireResponse.

This Signature DataType profile enforces the various elements of signature documented in the CDex guide. It adds the following mandatory (min=1) constraints:

• A Signature.type fixed to ASTM Standard, E1762-95(2013) code = “1.2.840.10065.1.12.1.5” (Verification Signature)
• A Signature.who for the organization or practitioner who signed the Bundle which is either:
  1. a reference to US-Core Practitioner, PractitionerRole or Organization or
  2. an NPI or Tax ID and name of the organization or practitioner
• A Signature.data representing base64 encoded JWS-Signature

In addition, the following mandatory (min=1) element is inherited from the base standard:

• Signature.when - system timestamp when the signature was created

This Bundle profile enforces the various elements of signature documented in the CDex guide to represent an enveloped signature. It adds the following mandatory (min=1) constraint:

• A Bundle.signature element using the CDex Signature Profile

This extension is derived from the SDC Questionnaire Response profile and enforces the various elements of signature documented in the CDex guide to represent an enveloped signature. It adds the following constraints:

• The signature extensions use the CDex Signature Profile

Identifiers type for providers and organizations limited to NPI or US Tax id.

Digital signature example showing how it is used to sign a search set Bundle. The CDEX use case would be a response to a Direct Query where a digital signature was required.

Digital signature example showing how it is used to sign a FHIR Document. The CDEX use case would be the target resource in response to a Task-based request where a digital signature was required. If no signature was required, the response would typically be in the form of an individual resource.

Electronic signature example showing how an image file can be used to sign a document Bundle. The CDEX use case would be the target resource in response to a Task-based request where an electronic signature was required. If no signature was required, the response would typically be in the form of an individual resource.

This example is a simple data request Questionnaire used in the Task Based and Attachments transactions. It indicates that a verification signature is needed when completing the QuestionnaireResponse. It is adapted from the Da Vinci DTR IG.

This Questionnaire Response example demonstrates the response to a CDEX Data Query or Attachments that uses a Questionnaire to request the data when an electronic verification signature is required. It is adapted from the Da Vinci DTR IG. The electronic signature is an image file in the QuestionnaireResponse signature extension. This example is adapted from the Da Vinci DTR IG.

This Questionnaire Response example demonstrates the response to a CDEX Data Query or Attachments that uses a Questionnaire to request the data and an electronic digital Verification signature is required. It is adapted from the Da Vinci DTR IG. The digital signature is a JSON FHIR Signature in the QuestionnaireResponse signature extension. This example is adapted from the Da Vinci DTR IG.

The set of purpose of use codes for the requested data (the output of the task). This code set is composed of FHIR core Purpose of Use security labels and additional codes defined by this Guide.

Codes temporarily defined as part of the CDex implementation guide. These will eventually migrate into an officially maintained terminology (likely HL7’s UTG code systems).

This example is a simple data request Questionnaire used in the Task Based and Attachments transactions. It is adapted from the Da Vinci DTR IG.

This Questionnaire Response example demonstrates the response to a CDEX Data Query or Attachments that uses a Questionnaire to request the data. It is adapted from the Da Vinci DTR IG.

This Questionnaire Response example demonstrates the response to a CDEX Data Query or Attachments that uses a Questionnaire to request the data. The Questionnaire is an adaptive questionnaire and the resulting QuestionnaireResponse contains the generated Questionnaire instance. This example is adapted from the Da Vinci DTR IG. For more information about adaptive questionnaires in FHIR see the SDC Implementation Guide.

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Consumer in Client mode when requesting clinical data from the Data Source during clinical data exchange. The capabilities include one or more of the following interactions:

1. Requesting and Fetching Clinical Data using a FHIR RESTful query
2. Requesting and Fetching Clinical Data using a Task-based query including:
   • Polling or Subscribing for Task update notifications
3. Requesting Attachments
   • Requesting Attachments Using Attachments Codes
   • Requesting Attachments Using Questionnaires

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Consumer in Server mode when responding to a Data Source or one of its proxies during clinical data exchange. The capabilities include one or more of the following interactions:

1. Responding to a query for authorization information represented by a CommunicationRequest or ServiceRequest
2. Responding to the $submit-attachment operation.

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Source in Client mode during clinical data exchange with a Data Consumer. The capabilities include one or more of the following interactions:

1. Post the $submit-attachment operation to a Data Consumer endpoint.
2. Launch Da Vinci DTR.
3. Query for Authorization information represented by a CommunicationRequest or ServiceRequest.
4. Post a subscription notification to a Data Consumer endpoint updating the status of a task.

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Source in Server mode when responding to a Data Consumer during clinical data exchange. The capabilities include one or more of the following interactions:

1. Responding to a FHIR RestFul Query for Clinical Data
2. Responding to a Task-based query request for clinical data including:
   • Polling or Subscription requests for Task update notifications
3. Responding to
   • Requesting Attachments Using Attachments Codes
   • Requesting Attachments Using Questionnaires