Coverage change detection

Most buildings find out coverage changed when the claim comes back denied.

By then the stay is over, the authorisation was never obtained, and somebody is writing an appeal about a plan switch that happened six weeks ago. Aacuity re-verifies every patient on your census on a schedule, compares each answer to the last one, and sends only what moved — the termination, the MCO switch, the benefit days that disappeared, the liability amount that changed — to the person who has to do something about it.

Run it against your census Read the developer story

Running in production Medicare · state Medicaid programmes · managed care · commercial

Changes — Riverside, Tue 2 Sep

4 findings · 118 checked

Alvarez, M. Critical Medicaid terminated — end date 31 Aug 2026 now present on an otherwise unchanged response. first seen 06:12

Boateng, K. High MCO changed — Tufts Health Together → UnitedHealthcare Community Plan, effective 1 Sep. first seen 06:12

Doyle, P. Medium SNF benefit days remaining 42 → 18. Date of last billing activity moved — somebody else billed Medicare. first seen 06:13

Whelan, R. High Patient liability $0 → $1,340 / month after a redetermination nobody was told about. first seen 06:13

114 residents unchanged — not shown, on purpose Next check Wed 05:45

Why we exist

Healthcare still talks to payers through phone trees, fax machines and portals designed in 2003.

Every interaction between a provider and a payer — checking whether somebody is covered, getting an authorisation, asking why a claim was denied — is still a person, on hold, retyping something. The information exists. It is simply not reachable in a way software can use, and so it is reached by hand, one patient at a time, or not at all.

Aacuity is building that conversation as an interface. Change detection is the first piece and the one that is live: instead of a person re-checking a census they do not have time to re-check, the census is re-checked on a schedule and the differences come to them. Authorisations are next. After that, the phone call itself.

Two ways in

Neither of them is an EHR integration project.

The reason change detection works for every healthcare company is that it is not gated on you having an engineering team. If you have an API, use it. If you have a spreadsheet, use that.

Option one

API — you call us, or we call you

Developers

Push a roster and pull a change feed, or give us a webhook and we deliver findings as they are confirmed. Every check, every delta and every severity is available as JSON; nothing on this page is a screen you have to look at to get the data.

One POST to push a roster; one GET to read what changed since your last cursor.
Webhooks for teams who would rather be told than poll.
Real findings only by default — baselines and bookkeeping are opt-in.
Severity is a floor, not an equality match, so you subscribe to “high and above” once.

Option two

Portal — no integration at all

Operators

Send us the census or patient list you already produce, or let us pull it. That is the whole setup. No feed to build, no interface engine, no IT ticket, no one on your side writing code. The findings arrive as an email a business office manager can act on before their first meeting.

Upload a list, forward a scheduled census export, or let us fetch it.
A cadence per facility — daily where it matters, weekly where it does not.
One email per building, addressed to the people who own the outcome.
The same findings in a portal when somebody wants to look further.

This is the part that is easy to under-sell. A facility does not need a developer, a data feed or an EHR project to use Aacuity. It needs a list of patients. That is why “every healthcare company” is a claim rather than a slogan.

Scope

Change detection for every healthcare company.

Nothing about the engine is specific to one vertical. Re-verify a population on a schedule, diff each answer against the last one, and decide which differences are worth somebody’s attention — that is the whole shape of it. The population can be a nursing home’s census, a home health agency’s active patients, a hospital’s admitted list, a behavioural health caseload, a dialysis schedule, a physician group’s panel. The census changes. The problem does not.

Skilled nursing is where it is proven today, because that is where an undetected termination costs the most and is noticed the latest. It is where the product was hardened, not where it is scoped.

In production today against traditional Medicare, Medicare Advantage, state Medicaid programmes and their managed care organisations, and commercial payers — each of which says the same thing in a different dialect, which is a problem we have already solved rather than one you inherit.

What it catches

Coverage moves constantly. Nobody tells the building.

These are real delta types from the live catalogue, at the severity the engine actually enforces. The severity is not decoration: it is what decides whether this wakes somebody up or waits for the weekly digest.

Finding	Severity	What it means to you
Medicaid terminated	Critical	An authoritative end date has appeared. Every day after it is unfunded.
Eligibility flipped to ineligible	Critical	The state now says no. Usually a missed redetermination, and usually reversible if you catch it.
MCO terminated or changed	Critical	The single largest billing-impact change there is. Different payer, different auth, different contract.
Part A or Part B terminated	Critical	Medicare carries an end date. Skilled days stop being billable on it.
Patient liability changed	High	Spend-down or NAMI moved. Somebody now owes an amount nobody has collected.
Coverage line vanished	High	A line that was there last week is gone from an otherwise healthy response. Flagged provisionally, then confirmed.
MBI changed	High	The identifier you have been billing under is no longer the right one.
New hospice election	High	Somebody elected hospice elsewhere. It changes who may bill for what, immediately.
Long-term-care status changed	High	Institutional status gained, lost or re-dated — often the difference between paid and denied.
SNF days used or remaining moved	Medium	The benefit period is shorter than your census believes.
Date of last billing activity moved	Medium	Another provider billed Medicare for this patient. Often the first sign of a hospitalisation nobody reported.
Recertification month changed	High	The renewal you were going to prepare for is now due on a different date.
First check — coverage found	Low	A baseline, not news. Recorded so the second check has something to differ from.

Around eighty delta types are live. The developer reference lists every one with the severity the engine enforces, and it renders from the engine’s own registry rather than being written by hand, so it cannot quietly fall behind.

Signal, not noise

The hard part is not looking things up. It is knowing what is new.

Anyone can re-run an eligibility check. Run it on two hundred residents every morning and you have created a second problem: two hundred answers that all look like an answer. A report that flags everything gets read twice and then filtered into a folder.

A real finding

Alert

Something about this patient’s coverage is different from the last time we looked, and the difference has money or care attached to it. A termination date. A new MCO. A liability amount.

This is the only category that reaches a human by default.

A first sighting

Baseline

We have never checked this patient before, so everything about them is technically new. Reporting it as a change would mean every new admission arrives as a page of alerts.

Recorded, retrievable, never sent as news.

Bookkeeping

Suppressed

A payer restated the same coverage with different whitespace, a name lost a middle initial, a message got reworded. The response differs. The coverage does not.

Held out of the alert stream entirely, so nobody learns to ignore it.

The split is what makes a daily report readable. A building with a hundred and eighteen residents gets four lines, and the four lines are true. That is the product.

For developers & AI agents

Smart routing: send us the string that is actually in the chart.

The reason eligibility is hard to automate is not the transaction. It is knowing where to send it. Aacuity takes the identifier and the raw payer name your system already has, and works out the rest.

Here is what a caller actually has. A member ID, and a payer name typed by an admissions coordinator at half past four:

UHC SENIOR CARE OPTIONS MA-Y001

To route that correctly you would need to know that this is UnitedHealthcare’s Massachusetts Senior Care Options plan; that SCO is a dual-eligible programme, so the check belongs with a Medicare Advantage trading partner rather than with MassHealth; which of several UnitedHealthcare payer identifiers that particular product answers on; and how Massachusetts words a managed-care segment differently from Ohio or West Virginia.

A caller should not have to know any of that. Neither should an agent. Send the identifier and the string; get back a normalised answer, with the payer we resolved it to and how confident we were.

Ambiguity comes back as ambiguity — candidates and confidence, never a confident guess. A wrong route is a wrong answer about somebody’s coverage, and that is worse than no answer.

Request

POST /v1/eligibility/resolve
Authorization: Bearer sk_live_…

{
  "member_id": "1EG4TE5MK73",
  "payer_text": "UHC SENIOR CARE OPTIONS MA-Y001",
  "state":      "MA",
  "dob":        "1941-03-08"
}

Response

{
  "payer": {
    "name":       "UnitedHealthcare Senior Care Options",
    "kind":       "medicare_advantage_dual",
    "route":      "ma_trading_partner",
    "confidence": 0.97
  },
  "coverage": {
    "active":     true,
    "effective":  "2025-01-01",
    "terminates": null,
    "liability":  0
  },
  // enrol this member and every later check is a diff
  "monitor": true
}

One vocabulary, every payer

Medicare, Medicaid, managed care and commercial answers come back in the same shape, with the same field names, whatever dialect the payer replied in.

State dialects handled here

Where the managed-care organisation lives in the response, and which code carries patient liability, differs by state. That difference stops at our boundary.

Monitoring is one flag

A resolve call can also enrol the member. Every subsequent check is compared to the last, and you receive deltas rather than answers.

Cadence and delivery

Checked on your schedule. Read in one email.

Cadence: Set per facility, not per account. Daily where the payer mix moves; weekly where it does not.
Recipients: Chosen per building. A regional director gets every building; a business office manager gets theirs.
Threshold: A severity floor per recipient. Subscribe to “high and above” once and stop reading the rest.
Quiet days: Nothing changed means nothing arrives. An empty report trains people to skim.
Everything else: Still there. The portal and the API hold every check, including the ones that were not worth an email.

Coming next

The rest of the conversation.

Change detection is the piece that is live. It is not the whole thesis. The same routing that knows where an eligibility check belongs knows where the other interactions belong too.

In build

Authorisations, as an API call, for every payer

Submit a prior authorisation, check where it is, and receive the decision — through one interface, whether the payer behind it has a modern API, a portal with a login, or neither. The provider’s side of it should look the same either way.