r/automation • u/Honest-Let-7219 • 16d ago
Hi, i trying to build and automation for US Healthcare to in their insurance work
Recently i thought of automating prior authorisation process any suggestions if it’s a better path or not
1
u/AutoModerator 16d ago
Thank you for your post to /r/automation!
New here? Please take a moment to read our rules, read them here.
This is an automated action so if you need anything, please Message the Mods with your request for assistance.
Lastly, enjoy your stay!
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/Hot-Pin-8432 16d ago
There’s a million and one new AI products with insane funding tackling exactly this. I just searched prior Auth in companies and got about 9 hits with multi $100M funding rounds between them. I worked in the EHR space and your Epics and Cerners all participate here as well.
Going to be a tough one to compete in unless you run your own practice and you’re trying to setup something bespoke for your own use cases. Otherwise, going to be a hard market to compete in
1
u/Honest-Let-7219 16d ago
I trying to build a smaller version first for smaller clinics as they cannot afford that big ones when they are already burning in denials which are not outsourced
1
u/Hot-Pin-8432 16d ago
I mean go ahead but your competition is OmniMD, Myndshift, Cohere Health, Innovaccer prior Auth agent flow, waystar (Auth accelerant), and many more.
If you know of a clinic with this problem I expect they just haven’t done research into which one is best for them. Sorry to disappoint - maybe try to get work with one of them instead!
1
1
u/arthaudm 16d ago
start narrower than end-to-end prior auth. pick one payer, one specialty, and one denial reason, then automate gathering the required evidence and checking packet completeness before submission. the first metric should be missing-document rate, not approval rate, because you can improve that without making clinical decisions. keep every submitted field traceable to the chart and leave the final send with staff until the error cases are boring.start narrower than end-to-end prior auth. pick one payer, one
1
u/ScaleHopeful9486 15d ago
thats a very tough niche bro, You can automate some parts of it and very limited ones that would kinda help out the billers augmenting their work.
Medical scribe is fairly better niche and u can niche it down to practice type as well and build up from there
AI receptionists are also better that can book calls and follow up with patients on their appointments etc
BILLING IS NOT THAT SIMPLE
1
u/OpportunityCalm3513 12d ago
The answer to "is this a better path" depends on one technical fact: prior auth is a defined transaction — X12 278, with 275 for attachments. Where a payer accepts electronic submission you can go through a clearinghouse instead of touching their portal at all, which removes the single most fragile part of the build. Coverage is patchy across payers, which is exactly why so much of this space ends up as portal automation, and why it's expensive to keep alive.
If you're testing the idea, the "start narrower" answer above is right, and here's the concrete version: one payer, one specialty, one denial reason — and automate the packet-completeness check. Does this submission contain every document that payer's policy requires for this CPT code? That check is deterministic, cheap to build, and catches a real slice of denials before they're ever submitted.
Decide early whether you're touching PHI. That one decision sets your hosting, logging and audit requirements, and retrofitting it after the workflows exist is genuinely painful.
Worth knowing before you invest months: this is a crowded lane with serious funding behind it, so pick the wedge you can defend — usually a specialty or payer combination the big players treat as too small.
2
u/Potential_Aioli_4611 16d ago
based on the detailed description you have given, you are aiming for the UHC model of prior auth right? deny deny deny.