Da Vinci Clinical Data Exchange (CDex)
2.1.0 - STU 2.1 United States of America flag

Da Vinci Clinical Data Exchange (CDex), published by HL7 International / Payer/Provider Information Exchange Work Group. This guide is not an authorized publication; it is the continuous build for version 2.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-ecdx/ and changes regularly. See the Directory of published versions

Requirements: CDex Payer Requirements

Official URL: http://hl7.org/fhir/us/davinci-cdex/Requirements/cdex-payer Version: 2.1.0
Standards status: Trial-use Maturity Level: 2 Computable Name: CDexPayerRequirements
Other Identifiers: OID:2.16.840.1.113883.4.642.40.21.36.3

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

This Requirements resource lists all the CDex Payer requirements defined in the narrative sections of this IG.

Language: en

CONF-012SHALL

This Task.input element represents the service date or the service's starting date for the claim or prior authorization. If the attachment is for a claim, it SHALL be present and precise to the day. It is optional if the attachment is for a prior authorization.

Links:

CONF-022SHALL
  1. Servers SHALL document in their Capability Statement's CapabilityStatement,operation.documentation element or payer-supplied documentation:

Links:

CONF-023SHALL
  1. When the payload is too big, the Server SHALL use The HTTP 413 Content Too Large client error response status code (alternate status messages "Request Entity Too Large" or "Payload Too Large").

Links:

CONF-024SHALL
  1. Servers SHALL document instructions for the Client when the payload is (or is anticipated to be) too big. (for example, send a URL + authorization information, offload to external storage, split multiple files into multiple operations)

Links:

CONF-025SHALL
  • If the signatures fail verification when processing the [$submit-attachment] operation, the Data Source/Responder SHALL return an HTTP 400 Bad Request and an OperationOutcome declaring that the signature was invalid.

Links:

CONF-079SHALL
  • A "ServiceDate" 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.

Links:

CONF-098SHALL

For CDex attachment requests transactions, the Payer SHALL use the [CDex Task Attachment Request Profile] to solicit information from a Provider.

Links:

CONF-099SHALL

For CDex attachment requests transactions, the Payer SHALL use the [CDex Task Attachment Request Profile] to solicit information from a Provider.

Links:

CONF-003SHOULD

|Attachment.Content|{{OK}}(DocumentReference, QuestionnaireResponse if support Requesting Attachments Using Questionnaire|{{OK}}(Servers SHOULD support other FHIR types)|

Links:

CONF-021SHOULD
  • The Payer SHOULD return an informational OperationOutcome with the HTTP accept response if the attachments can not be associated with a current claim or prior authorization and are being held for association with a future claim or prior authorization. An OperationOutcome example is used in Scenario 1b below.

Links: