4. AUC Order Flow and Scenarios

Scenarios

There are four different scenarios that you can implement to support AUC validation in an external application. This article describes the different flows and indicates the request/responses and interactive dialogs for each. For details on how to format the requests, please see Request/Response Structure. For more details on how to implement this see API Sample Client JavaScript Implementation.

Scenario 1: CPT + Reason Code Provided

The images below show the process flow when the CPT + reason code are provided. The process runs through Figure 1: 1, 2, 3; Figure 2: 14 and 15; and Figure 3: 20, 22, 25, and 16. Let's start with the initial request in Figure 1.

  

If the initial request provides the CPT code (1) and the reason code (2), calling the AUC webservice (3) returns an applink card with an "Insufficient Patient Data" outcome (14) field. 

 

This indicates that there was a correct guideline associated with the Reason Code and that the provided CPT code is present as a recommendation in this guideline. However, the system was not yet able to complete the validation. In other words, the system did not have enough information to validate if the CPT code is the recommended one.

  

As part of the applink card in the response message, the system provides a link that the client can use to launch an interactive application (15) through which the user can provide the missing information. The client can render the application, allowing the user to provide the missing information. When the provided CPT code matches the recommended Advanced Imaging Procedure in the Guideline, the user can select the Confirm button (20) in the interactive application. This calls the Smart Message function in the opening application (22). At this point, the client will need to make a second call (25) to the webservice to retrieve the updated applink card in the response. The calls will need to use the same HookInstanceID that was generated by the client to connect the data sets (see also API Sample Client JavaScript Implementation), which will include the complete set of validation information. The outcome will be "appropriate" and the returned information can be used in the billing reporting on the client side (16).

Scenario 2: CPT Code Only Provided

The image below shows the process flow when the ONLY the CPT Code is provided. The process runs through Figure 1: 1, 2, 4, 5, 6 and then continues the same as the process described in Scenario 1. Let's start with the initial request in Figure 1.

If in the initial request provides the CPT code (1) but no reason code (2), calling the AUC webservice (3) returns multiple applink cards, each with an outcome (14) field. The AUC webservice evaluates every guideline and determines if the provided CPT code is used in the guideline. At this point, the client can render a selection screen (5) to the user with the list of guidelines mentioned in the applink cards. The user can see the outcomes for each guideline and can select which guideline they want to use for validating the order. The image below shows an example of a guideline selection screen for CPT 70450:

 

Each applink card includes the logicnets-defined reason code. Based on the selection the user makes the client can update the request with the logicnets-defined reason code. At this point, the flow continues the same as in Scenario 1.

Notice in the screenshot that users can always select a guideline that does not specify the CPT code. In this case, the user can override the guideline recommendation and the AUC webservice will register this. See Figure 2, Steps 17 and 18.

Also notice that in the example guideline selections screen you will need to render the ability for the user to specify an option to register a different clinical area other than the 8 prioritized ones. When the client makes the second request (Figure 1: 3) the AUC webservice returns the "no-criteria-apply" outcome (14). This outcome needs to be reported the same way as all the other outcomes, because the CPT code is on the list of advanced imaging procedures identified by CMS.

Scenario 3: Reason Code Only Provided

The image below shows the process flow when the ONLY the reason code is provided. The process runs through Figure 1: 1, 7, 8, 10, and then continues the same as the process described in Scenario 1. Let's start with the initial request in Figure 1.

If the initial request provides no CPT Code (1) but does provide a reason code (2), calling the AUC webservice (3) returns a single applink card, which contains all the CPT codes of the matching guideline. This client application can present to the user this list of CPT codes. The image below is an example of what a client screen may look like:

  

The selected CPT code can be included in a new call (see Figure 1: 3) that has both the reason code and the CPT code. Now the process continues as described in Scenario 1.

Scenario 4: No CPT Code and No Reason Code Provided

The image below shows the process flow when no CPT code and no reason codes are provided. The process runs through Figure 1: 1, 7, 11, 12, 13, and then continues the same as the process described in Scenario 3. Let's start with the initial request in Figure 1.

 

In this scenario, the initial request (11) provides no CPT codes and no reason codes. The AUC webservice returns a list of applink cards, one for each guideline. The client can iterate through the applink cards and present a list of guidelines to the user. When the user selects the guideline, the client can make a new request with the reason code details specified in the applink card for this guideline. Now the process continues as described in Scenario 3.