processing: The prior authorization request has been received and is currently being processed. This is the initial status indicating that the system is handling the request. Generally it will only be in this state for up to a few minutes.
awaiting_review: Processing has completed and the AI answers have been generated. The prior authorization will remain in this state until submitted by a user in the platform.
awaiting_outcome: The request has been submitted to the payer or pharmacy benefit manager and is awaiting an outcome.
validating_outcome: An outcome has been received but requires additional validation by the Develop Health team to ensure accuracy before finalizing the result back to you. This is a short lived status that occurs in some cases, and should generally be resolved in a few hours or less. If an issue is found during validation, the prior authorization will be transitioned back to the awaiting_outcome status while our team corrects the issue. You should wait until receiving a completed/failed status before relaying any outcomes to the patient.
completed: The prior authorization process has completed successfully, with an approval or denial outcome.
failed: The prior authorization has failed due to an error or unexpected outcome. This status may require attention to resolve any issues.
cancelled: The prior authorization request has been cancelled by the user, and no further processing will occur.
See the diagram below for a visual representation of the status workflow.
Represents the response structure for a GET /prior-authorization/:id request.
This class extends the generic ApiResponse, specifically tailored to handle responses related to
prior authorizations. It primarily includes the data attribute, which holds detailed information
about the benefit verification process and its results.
The payer name on the card. This field is not normalized, so the same plan may have different names depending on the way it appears on the card. i.e. 'United Healthcare', 'United', 'United Health' could all appear
The payer name on the card. This field is not normalized, so the same plan may have different names depending on the way it appears on the card. i.e. 'United Healthcare', 'United', 'United Health' could all appear
If applicable, the Base64 encoded insurance card image you send in the request is stored on our servers. A signed URL to the image is returned here. This URL has a short expiry time, so you should download the image immediately after receiving it if you want to view the asset.
A collection of evidence items supporting the authorization request. Any other supporting evidence that doesn't fit into one of the explicitly declared fields above can be added here.
Title of the evidence. This will be shown to users in the platform UI so it's recommended to give it a name that would be meaningful to them, such as 'Intake Form'
The type of object. This will always be 'prior_authorization', from this endpoint, but this can be helpful for differentiating between different types of objects when parsing webhook responses.
Optional list of choices for the question. If provided, the answer must be one of the choices. It's important to include this list of choices for any multiple choice question. This allows our AI to know what a user has effectively said 'no' to by picking another option. I.e. for a question 'Do you have any of the following conditions: Diabetes, Heart Disease, Cancer, None of the above' if the user answers 'None of the above' we can infer that they don't have any of those conditions. Without the choices list we would have no way of knowing that.
The date and time (if available) when the visit note was created. This is important for ensuring we have an accurate timeline of the patient's history.
