This endpoint is designed to streamline the submission of prior authorization requests for medications or treatments. It requires various key pieces of information about the patient, including demographics, insurance details, and the prescription in question. Additionally, the submission should include supporting evidence, such as visit notes, lab results, and intake forms, to justify the need for the prescribed medication or treatment.
To effectively use this endpoint, please ensure the following information is included in your request:
Patient Demographics: Essential details such as the patient’s name, date of birth, and contact information.
Insurance Details: A photo or scan of the patient’s insurance card (preferably front and back), including the group number, payer, membership number and RX details. If an image is not available, or the patient provided extra information not on their card (such as rx codes) you can also provide this structured data in the API.
Prescription Information: Detailed data on the prescribed medication or treatment, such as drug name, dosage, and administration instructions.
Evidence: Critical supporting documents and data such as visit notes and laboratory results. This section is particularly versatile, allowing for a variety of formats and contents to support the authorization request.
Given the diverse nature of medical records and evidence, our API is built to accommodate a wide range of data formats. Structured data can be filled into predefined fields, while unstructured data, such as additional JSON content about the patient, can be included in the content block within the evidence objects. This flexibility ensures that even non-standardized data can be effectively utilized in the prior authorization process.
In the future we will support uploading files and scans, such as PDFs, images, and other documents, to the evidence section. Currently these are not utilized in the answering flow, but we will be adding support for them in the future. The API does support uploading these, and in a future version of our answering model they will be used.
We highly recommend you talk to a member of your company who actively submits prior authorizations when collecting the data for this endpoint. For the system to work effectively, we require the exact same data that those staff members currently have access to. A great test is to collect the data and see if the staff member is able to use that data alone to submit a new prior authorization through your existing system.
After submitting a request, the system processes the data and returns a response indicating either the successful reception of the request or detailing any errors or additional information needed. Our advanced AI algorithms will analyze the provided information, including any uploaded files or scans, extracting and utilizing relevant details to facilitate the authorization process.
You’ll notice in the response error section at the bottom of this page that there are several possible errors that can occur. Particularly during the ramp up period you’ll likely see the daily_prior_auth_request_limit_reached error. We’re still in the process of reaching 100% plan coverage, so seeing the unsupported_patient error is also expected. We want to make integrating as easy as possible, so the details of these error codes can generally be ignored. You’ll likely want to process them all the same way as detailed below.
We’d suggested taking the following approach when integrating:
Make the API request for all prior authorizations that you need to submit, and let us handle the ramp up on our end. i.e. We’d recommend not feature flagging or limiting this to certain patients. We have a daily limit that starts off at just 5 requests that we can increase rapidly. Using this approach allows us to work with your ops team to gradually increase the volume we handle as we see successful responses from the insurance companies.
If you receive an error code, fallback to your companies existing process for handling prior authorizations. We’ll gradually reduce the number of errors you receive as we ramp up to 100% coverage.
As a developer reading these docs we understand it might be difficult to know what data to provide and how best to structure it. Please know that we at Develop Health are here to help! A member of our engineering team will happily work with you to ensure you’re providing the right data in the right format.
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Body
application/json
Represents a request for creating a prior authorization for a medication. This includes detailed
information about the patient, their diagnosis, prescribed medication, evidence supporting the need for treatment,
insurance details, and responses to relevant questionnaires.
A collection of evidence items supporting the authorization request. Any supporting evidence that doesn't belong in the other predefined fields 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'
Insurance information for the patient. We will extract the required information from the insurance card images you provide. Please provide both the front and the back of the card. This is optional if you provide insurance_content, but highly recommended to ensure best results.
Insurance information for the patient. Values provided here will be used in combination with those extracted from any insurance cards provided. We recommend providing this information when available to ensure best results. If you provide both insurance and insurance_content, the values provided here will be used and the values extracted from insurance will be used as a fallback.
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
Specifies the simulated outcome for a completed prior authorization. Setting this field will instantly complete the prior authorization request and send a webhook with the value of this field. You will not be charged for these requests and you will not be sent the prior auth for manual review.
Specifies the priority of the prior authorization request. This is used to determine the order in which requests are processed. Lower values indicate higher priority.
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.
A specific code identifying the error. While we'll aim to ensure that the occurence of these errors is minimal, it's likely they will occur. To prevent delays to patient care, we generally recommend that you implement a strategy of falling back to your existing process for handling a prior authorization if you encounter one of these errors. The Develop Health team will then work with you in parallel to fix the issue. The following codes are currently possible:
unsupported_patient: This means that the patient you submitted the prior authorization for is not currently supported. We're rapidly increasing our PBM and payer coverage, so we'll be reducing the occurrence of these over time.
unsupported_drug: The drug you submitted is not yet supported for prior authorization.
daily_prior_auth_request_limit_reached: The daily limit for prior authorization requests has been reached. There is a temporary limit set on new accounts to ensure that submissions are accurate before we allow unlimited submissions. The Develop Health team will work with you to increase this limit as quickly as possible.
daily_prior_auth_request_new_plan_limit_reached: The daily limit for prior authorization requests for new plans has been reached. As we increase our payer and plan coverage this limit ensures that submissions are accurate before we allow unlimited submissions.
insurance_card_member_id_ocr_failure: We were unable to extract the member ID from the insurance card image provided and no discrete values were provided.
insurance_content_invalid_rx_bin: The Rx BIN provided in the insurance content is invalid. This should be a 6 digit number.
other: An unexpected error occurred during the prior authorization process.
