Why we built an API for payer policy intelligence

Every denied claim starts the same way. Someone in your billing office gets the rejection, pulls up the payer portal, and starts hunting. They need the medical necessity criteria. They need the code coverage. They need to know what’s changed since the last update.

This person opens six browser tabs. They download three PDFs. They search for the right section across 47-page documents. Is this even the current version? They check their email for notes from the last time someone dealt with this payer for this procedure. Maybe they call the payer. Maybe they post in a Slack channel asking for help.

An hour later, they’ve used the policy to create a decent appeal letter.

We don’t think it should be this hard to find the right information, and, more importantly, to use it.

The integration problem

Your billing software knows everything about the claim. It knows the patient, the procedure codes, the diagnosis, the provider. It can generate a claim form in seconds.

But it can't answer the simplest question: what does this payer require for this procedure to get approved?

That information lives in PDFs. It lives in payer portals that don't talk to each other. It lives in the heads of your most experienced staff members. When you want to check coverage criteria, you leave your billing system and start clicking.

No API returns payer policies. No database maps relationships between procedure codes and medical necessity guidelines. You can automate claim submission, but you can't automate the knowledge work that prevents denials in the first place.

What we built

Penelope Health is an API for payer policy intelligence. You send us the payer, plan and either the code of interest or a ‘fuzzy’ policy name, and we return the relevant medical coverage policy, with structured and contextual code coverage.

This is possible because we don’t treat policies as dumb documents. We extract codes with reference to their context within the policy: for a given CPT code, is it explicitly mentioned as being ‘covered’, ‘not covered’ or simply ‘referenced’. Note that many CPT codes are referenced, which are likely covered, but for reasons of plausible deniability are not explicitly mentioned as being so. When searching by code, we typically recommend filtering policies by both ‘covered’ and ‘referenced’.

Behind the API is a knowledge graph. We've structured the relationships between payers, plans, medical coverage policies, CPT codes, HCPCS codes, and ICD-10 codes. When policies update, the graph updates. When you query for a procedure, you get the current medical necessity and coding requirements, not a policy from 2024.

The integration is direct. Your billing system makes an API call. We return structured data. Your team sees what the payer requires before the claim goes out.

Layered on top of this though, we have specialised functions to directly use the policy within our own user interface: to generate prior authorization cases and appeal letters. 

Why this matters for appeals

Denials are expensive, but appeals are worse. Your staff needs to write a letter that references the right policy language, cites the right medical guidelines, and makes the case that the care was necessary. A good one takes hours. You're doing it manually because there's no system that knows both the claim details and the payer's policy logic.

Penelope can generate the first draft. We pull the relevant policy sections, matches them to the clinical documentation, and writes the appeal with proper citations. Your staff can review and send.

Technical choices

We built this as an API first because billing companies already have software. You don't need another portal to log into. You need data you can pipe into your existing workflows.

We focus on structured output. Every policy reference includes the policy number, effective date, and payer source. You can trace every recommendation back to its origin. When policies conflict, we flag it.

We update in real time. Payers change policies constantly. An API that returns stale data is worse than no API at all.

Mid-sized billing companies process tens of thousands of claims per month. Right now, your team triages. They spend deep time on the big dollar denials and hope the rest go through.

With an API, you can check every claim against payer policies before submission. You can auto-generate appeals for denials. You can track which payers have the most policy changes and adjust your processes.

The long game

Healthcare runs on information trapped in documents. Payer policies, medical guidelines, coverage determinations, they all exist as text files that humans have to read and interpret.

We're building the infrastructure to make that information programmable, not just searchable. So your software can answer the question "will this claim get approved?" the same way it answers "what's this patient's balance?"

That's what API-first means for healthcare.

If you're tired of the manual scramble for good quality payer information, we should talk.

Email | Book a call (and get a free audit of your current use of AI)