Pretty Good AI vs Develop Health

Two products, one word in common

Ask a practice administrator what prior authorization costs them and you will get two completely different answers depending on which chair they sit in.

The pharmacist and the prescribing clinicians will describe a drug that the patient cannot start. Coverage is unclear, the plan wants a form nobody has seen before, and the whole thing takes a week of phone calls before anyone knows whether therapy begins.

The operations side will describe a procedure that got rescheduled. The authorization was submitted incomplete, it came back for more information, the window closed, and now the front desk is calling a patient to move a date that was agreed six weeks ago.

Develop Health built for the first problem. We built for the second, and for the twenty other things happening in the same building on the same day.

What Develop Health is actually doing

Develop Health calls itself insurance AI for prescribers, and the description is accurate. The clinician writes the prescription in the usual place. Behind that, the product checks whether a prior authorization is required at all, identifies the right payer or PBM, retrieves the plan-specific form, fills it from the chart and clinical notes, submits it, and then chases determination. On a denial it drafts the appeal.

The company publishes a 90 percent reduction in manual work and approvals in under a day where they used to take a week, and its marketplace listing cites a customer moving from roughly 45 minutes of hands-on time per authorization to roughly 3.

That is a real product solving a real thing, and it is not a thing we do. We do not predict pharmacy-benefit coverage at the point of prescription, and we do not create, sign or transmit a prescription. What we handle around a refill is administrative: collecting information, contacting the patient, and routing the request to the right clinician. Prescribing decisions stay with your care team.

What our prior auth co-pilot does

Our authorization work sits on the service and procedure side, inside athenaOne.

Authorization prep compiles the submission before it reaches the authorization team, flags what is missing while there is still time to fix it, and is customized by payer so each submission carries what that particular payer asks for. Status tracking pulls prior-auth and claim status out of payer portals, including no-auth-required determinations and out-of-state benefit checks, and writes it back into athenaOne so staff read status in the chart rather than logging into four portals in sequence.

Then the part that only works because the rest of the platform is there. When an authorization is not going to land before the scheduled date, the system that knows it also runs the phone line and the schedule. It can reach the patient, move the appointment, and leave the case in the staff queue with the reason attached, rather than generating a task that someone finds on Thursday.

That is the pattern across everything we build. Depth of access to athenaOne is what makes the action possible; the action is the point.

A complication both products meet, from opposite ends

The following is an illustrative workflow, not a customer story.

A multi-site rheumatology group runs biologics. A patient is started on a specialty drug on a Tuesday, and separately has an infusion suite appointment booked for the following month that carries its own authorization requirement.

The medication authorization clears in a day. The infusion authorization does not, because the payer wants a clinical note that has not been signed yet. Nothing in either system is broken. The patient simply gets a message saying their medication is approved, and no message at all about the appointment that is about to be moved.

The fix is not a feature. It is a decision, made before either product goes live, about which system talks to the patient about medication access and which one talks to them about their appointment, and a rule that neither sends a message about a case the other one has open.

One case always stays with a person. A patient who calls to say they cannot afford the copay after approval is asking for a financial conversation with real judgment in it. Route that to a human with authority to act, and stop automated contact on that account until they have.

The regulatory clock underneath both

Authorization workflows are being reshaped by rule, not just by software. Under the CMS Interoperability and Prior Authorization Final Rule, impacted payers were required to implement certain prior authorization provisions from 1 January 2026, with the API requirements landing primarily from 1 January 2027.

The practical read for a practice: payer-side status and decision data is going to become more available, more structured, and more automatable over the next two years. What matters is whether the system reading it can also act. A status feed that produces a better-informed task list is still a task list.

Which problem do you have

If therapy start dates are slipping, prescribers are being pulled into paperwork, and the medication queue is where staff hours disappear, that is a pharmacy-benefit workflow and Develop Health built directly for it.

If procedures get rescheduled because authorizations were incomplete, the phone rings unanswered while staff are in portals, referrals age in a fax queue and forms come back late, the authorization delay is one symptom. It is a capacity problem wearing an authorization costume, and buying a medication tool will not move the other four numbers.

Most groups of any size have both, which is why the honest answer here is not a bake-off. Develop Health is already writing to the same athenaOne record we work from. The question worth spending twenty minutes on is which system speaks to your patient first, and about what.

Why we can shape this around how you already work

The reason we can take on an authorization workflow that looks nothing like the last practice’s is access. Production access to 820+ athenaOne APIs is what makes an unusual workflow buildable at all, and most marketplace vendors pick a narrower wedge and build deep inside it.

So we map the process your authorization team already runs, in the order they already run it, and automate that. We do not ask you to re-cut your payer rules, your queue conventions or your escalation path to match a product’s opinion of how authorizations should work. Scoping a new workflow is measured in days and weeks, inside an onboarding window that is already weeks long, and it gets refitted when your payer mix changes.

Tell us how your authorization queue runs today and we will tell you what we would build against it.

Clinical decisions stay with your care team.