![]() |
Cancel
Submit unsolicited attachment(s):
Click on Submit Attachment(s) button to invoke the $submit-attachment operation to submit
unsolicited attachments
and the necessary information to associate them with the claim or prior authorization for
claims
or prior authorization to Payer. The Payer will return an HTTP response”
(NOTE: Use this same label and text for the solicited attachments flow )
Parameter successfully created
Parameter:
Payer Receives Body $submit-attachments operation Transaction which is a
Parameters resource containing One or more attachments as FHIR Resources and
Data elements for the association to the claim/prior authorization.
Attachment as a FHIR resource.
Non-FHIR attachment data is conveyed using the DocumentReference.
Servers SHALL support the DocumentReference resource type and SHOULD support other types.
Operation outcome
Status codes:
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.
Claim:
The Payer associates the attachments to the claim or prior authorization, and processes the claim.
This is not part of CDEx. It is shown here to demonstrate one possible Payer scenario using the FHIR
Claim resource.
Payer records it on their Claim resource like this…
1.- Attachment data from Submit Attachment Operation–> Claim.supportingInfo.valueAttachment
2.- Assign id for this attachment within the Claim resource --> Claim.supportingInfo.sequence
Claim.item.sequence matched to —> line item data from Submit Attachment Operation
3.- Claim.item.informationSequence refers to Claim.supportingInfo.sequence (id for attachment within
the Claim resource from above)
OK
Download
Download resources:
Click on this button download a zip file containing all the content in the Text boxes above
[loading...]
)Workflow Type
[loading...]
)
Workflow:
Request:
Provider response If the Task was successfully created, The user can complete the request by clicking the “OK” button below and the “Submit Solicited Attachments” button on the CDex Dashboard
OK
Download
Download resources:
Click on this button download a zip file containing all the content in the Text boxes above
CDex Attachments are requested in Task.input using either Attachment Codes or FHIR Questionnaire.Select how CDex Attachments are requested in Task.input using the radio buttons below
Request Questionnaire
Request Questionnaire:
Select from existing Questionnaires to communicate the missing data. Currently there is only
a single option.
LOINC Attachment Code
LOINC Attachment Code:
Select the LOINC attachment code(s) to communicate the missing data. Typically, these
concepts represent data in document form (e.g., a PDF or CCDA). For more information about
LOINC attachment codes see https://loinc.org/attachments/
Signature required:
Check this box to indicate that the PAYER requires a digital signature for this transaction.
If selected, it will trigger the Payer to verify any attachments that are FHIR resources are
a
signed FHIR bundle
(PDF and CCDA(xml) are assumed to be natively signed).
Create task:
POST CDex Task to Provider's FHIR Server to solicit attachments.
Cancel
The Table below shows the data elements used to create the CDex Task for requesting attachments or additional data for a claim or prior authorization. | |
---|---|
Tracking ID (Provider or Payer Assigned) | |
Task.code | data-request |
Use | Claim attachment (CLMATTCH) |
Payer ID | Get it from app |
Payer URL | Get it from app |
Provider ID | cdex-example-practitioner (Dr. Ronald Bone) |
Claim/PreAuth ID | |
LOINC Attachment Code | |
Due date | |
Date of service | |
Member ID | |
Patient name | |
Patient Account No. | |
Patient DOB |
Task | Date | Status |
---|
Select | Name | Date | LOINC | Extensions |
---|
This will launch a simulation of DTR process before submit the requested attachment
Task
Questionnaire
Questionnaire Response
Modified Task