CDex Scenarios Description

Task Based Approach Task Based Approach:
A system that needs information about a patient/member and which can solicit that information using the asynchronous CDEX Task based approach.
For detailed documentation see: http://build.fhir.org/ig/HL7/davinci-ecdx/task-based-approach.html
  • Example Transaction:
    • Data Consumer creates a Task on the Data Source’s system soliciting a patient’s knee surgery report and then polls for updates to the Task.
    • Data Source completes the data request and updates the Task with the requested information and the status to “completed”.
    • The Data Consumer fetches the completed Task and the documents referenced in it.
Direct Query Direct Query:
A system that needs information about a patient/member and which can solicit that information using standard FHIR RESTful queries.
For detailed documentation see: http://build.fhir.org/ig/HL7/davinci-ecdx/direct-query.html
  • Example Transaction: Action: Synchronous Data Consumer executes a RESTful search the Synchronous Data Source’s system that will return the patient’s active medication orders
Submit Attachment Submit unsolicited attachment:
 Provider invokes the ‘$submit-attachment’ operation on the Payer’s endpoint to attach a document to an existing Claim or Prior Authorization.
The Data Consumer returns a success code For detailed documentation see: http://build.fhir.org/ig/HL7/davinci-ecdx/sending-attachments.html
Example Transaction:
  • Provider submits a visit summary for a claim they are submitting to the Payer using $submit-attachment.
  • The Data Consumer returns a success code indicating that the $submit-attachment payload was recieved.
  • Association of the attachment to the Claim resource.
 Request Attachment Requesting Attachments:
 Payer solicits additional information for a claim or prior authorization using the asynchronous CDEX Task based approach.
The actual data requested uses “attachments codes” or a FHIR Questinnaire. For detailed documentation see:
http://build.fhir.org/ig/HL7/davinci-ecdx/requesting-attachments-code.html and http://build.fhir.org/ig/HL7/davinci-ecdx/requesting-attachments-code.html.
  • Example Transaction 1:
    • Payer asks for a visit summary for a Payer’s claim using Task using and attachment code
    • In a separate transaction the Provider submits the requested data using $submit-attachment to the Payer.
  • Example Transaction 2:
    • Payer asks for a additional data for a Payer’s Home Oxygen Therapy Claim using a FHIR Questionnaire
    • In a separate transaction the Provider submits the completed FHIR QuestionnaireResponse using $submit-attachment to the Payer.
 Submit Solicited Attachments Submit Solicited (Requested) Attachment:
 Provider invokes the ‘$submit-attachment’ operation on the Payer’s endpoint to attach a document or QuestionnaireResponse to an existing Claim or Prior Authorization.
The Data Consumer returns a success code For detailed documentation see:
http://build.fhir.org/ig/HL7/davinci-ecdx/sending-attachments.html
  • Example Transaction 1:
    • In a separate transaction, Payer asks for a visit summary for a Payer’s claim using Task using and attachment code
    • The Provider submits the requested data using $submit-attachment to the Payer.
    • Association of the attachment to the Claim resource.
  • Example Transaction 2:
    • In a separate transaction, Payer asks for a additional data for a Payer’s Home Oxygen Therapy Claim using a FHIR Questionnaire
    • The Provider submits the completed FHIR QuestionnaireResponse using $submit-attachment to the Payer.
    • Association of the attachment to the Claim resource.
Direct Query Type
&clinical-status=active,recurrance,remission
Proceed

Patient: [loading...]

Cancel

Data Request (Task) Created Workflow Type Status

[loading...]

Patient: [loading...]

Cancel

CDEX: Provider Unsolicited Attachment Transaction
Patient: [loading...]
Tracking control number:
Select a pre-existing tracking control number for this patient (if the list is empty it probably means the patient does not have any pre-existing claims or prior authorizations. You can make up your own custom tracking control number using the checkbox below or select another patient)
Custom tracking control number:
When the Tracking Control Number check box is selected, you can add your own custom tracking control number.


Custom tracking control number type:
When the Tracking Control Number check box is selected, you can select whether your own custom tracking control number is for a claim or prior authorization.

Custom tracking control number type:
Enter date of service or starting date of the service for the claim or prior authorization. It is optional if the attachment is for a prior authorization.





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 )


CDEX: Payer Response to Unsolicited Attachments Transaction

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

Edit data request (patient:

[loading...]

)

Workflow Type

Review data request (patient:

[loading...]

)

Workflow:
Request:

Confirmation

Data request (Task) successfully sent to Data Source (Provider).

OK

Confirmation

Direct Query request successfully sent to url:

OK

Provider Endpoint Configuration

Save configuration
Error

CDEX: Provider Response to a CDex Task Posted by a Payer
Attachment(s) requested

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: Payer Requesting Attachments or Additional Data for a Claim or Prior Authorization
Patient: [loading...]
Attachment Codes or Questionnaire

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



Select a Claim or Prior Auth:
Select a pre-existing claim or prior-authorization for this patient. (if the list is empty it probably means the patient does not have any pre-existing claims or prior authorizations. You can create a new claim for this patient or select another patient)

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
Custom payer endpoint:
A "3rd party" endpoint where the the CDEX Task will be posted instead of the default RI FHIR Server.
Provider side operation
Attachment(s) requested
Task Date Status

Patient [Loading ...]

Select Name Date LOINC Extensions
Patient [Loading ...]


Questionnaire

This will launch a simulation of DTR process before submit the requested attachment

Task

Questionnaire

Created/Updated resources

Parameter created

Operation outcome

Claim updated

OK Download resources

Provider side operation
Created/Updated resources

Questionnaire Response

Modified Task

Submit Attachment Download resources