Covendo · Coverage monitoring for skilled nursing
Covendo re-verifies every resident’s coverage on a schedule and reports only what changed. A check that finds nothing new emits nothing.
Medicare · CMS / Medicaid · 47 states + DC / Managed care · payer-direct / Cadence · daily to monthly, per facility
| Resident | Facility | Change | From → to | Effective | Severity |
|---|---|---|---|---|---|
| Marjorie Alvarezpt_81be04 | River Bend | Managed-care plan changed | SENIOR WHOLE HEALTHWELLSENSE | 2026-08-01 | High |
| Dennis Whitfieldpt_40cc19 | Oak Hollow | Coverage terminated | activetermed | 2026-07-31 | High |
| Rosalind Okoyept_2a7f55 | Cedar Point | QMB status added | falsetrue | 2026-08-01 | High |
| Harold Benningpt_9d1e30 | Oak Hollow | Hospice elected | noneelected | 2026-08-05 | High |
| Eleanor Pacept_66b0a2 | River Bend | Part A days remaining | 4112 | 2026-08-09 | Medium |
| Priscilla Nakamurapt_c3084b | Marsh Creek | Patient liability changed | $0.00$184.00 | 2026-08-01 | Medium |
Illustration of the change feed. Residents, facilities and values are fabricated; no real resident data appears anywhere on this site.
Two ways to use it
For admissions and the business office
We watch every resident’s coverage and email you what changed. Nothing to install, nothing to integrate.
For EHRs, billing platforms and group IT
A documented REST API over the same engine. Push a roster, pull the feed, drive the schedule from your own product.
sk_live_ bearer keys, one per tenant, rotatable without downtime.
What it catches
A plan is reassigned, benefit days run out, a QMB flag appears. None of it arrives as a notice — it shows up weeks later as a denied claim, long after the days were delivered.
| What changes | What we report | Why it costs money |
|---|---|---|
| Coverage starts and stops | Terminations with an authoritative end date, new plans, coverage that begins in the future. | Days billed to a payer that is no longer on the hook. |
| Plan identity | Medicaid MCO switches, Medicare Advantage plan changes, roster payers the payer disagrees with. | Claims and authorisations sent to a plan that dropped the resident. |
| Benefit depth | Part A days remaining, lifetime reserve, hospital days, therapy dollars, deductible. | A stay that quietly stopped being covered mid-month. |
| Liability | Patient liability and coinsurance amounts moving up or down. | Money collected from the wrong party, or never collected at all. |
| Dual and QMB status | Dual eligibility appearing or lapsing, and QMB status changing. | Billing a resident who cannot lawfully be billed. |
| Hospice and elections | Hospice election and revocation, and other program flags. | The wrong payer for every day from that date forward. |
| Census data quality | Member numbers that fail at the payer, a date of birth the payer disputes, a dead plan. | Rejections that look like coverage problems but are typing errors. |
Verification routes
Real eligibility transactions through a clearinghouse — not screen scraping, not portal logins.
Whichever route a resident’s coverage comes through, it lands in the same feed and the same digest. You never have to know which one ran.
Medicaid, state by state
47states + DC
Nothing changed.
138 residents re-checked. No alerts, and no email went out.
Signal, not noise
Re-check a few thousand residents every week and you get a few thousand pages of mostly-unchanged output, which nobody reads. You get the difference instead.
The split that makes it usable
Most monitoring tools drown you: onboarding a building floods the inbox, tidying the census floods it again, and within a fortnight the alerts are ignored. Your feed keeps the three apart, and only one of them ever reaches you.
A real coverage change at the payer, worth a person’s attention. This is what lands in a digest, with severity, dates and the old and new values on the face of it.
→ Emails you. Counts as signal.
Where a resident’s coverage stood when they joined your feed. It is recorded so the history is complete from day one, and it is never treated as news.
This is why onboarding a facility does not fill anyone’s inbox on the first morning.
→ Recorded in the feed. Never emailed.
A correction to your own census rather than a change at the payer — a transposed member number put right, a spelling fixed.
It is kept in the feed with its source, so the record is honest, but it is not a coverage event and it never pages anyone.
→ Kept and attributed. Never emailed.
Cadence and delivery
Each facility sets its own frequency with an explicit day. Recipients are people, not mailing lists — one person gets one email covering every building they cover.
3 facilities · 5 alerts since your last digest
River Bend Care Center 2 alerts
M. Alvarez MCO changed → WELLSENSE
E. Pace Part A days 41 → 12
Oak Hollow 2 alerts
D. Whitfield Coverage termed 2026-07-31
H. Benning Hospice elected 2026-08-05
Cedar Point 1 alert
R. Okoye QMB added false → true
41 baselines and 3 data-entry changes recorded and not included.
Ingestion
Sending us a roster never silently starts a run. Sync the census as often as you like without spending a lookup or generating a finding.
Full replace per facility, idempotent. Admits, discharges and payer changes are recorded and tagged as coming from your roster.
Send the spreadsheet you already produce. Rows that cannot be matched are quarantined for review, never guessed at.
However it arrives, you get one roster per facility and one view of it. The route in makes no difference to what you read.
A check runs when your schedule says so, or when you ask for one. Never as a side effect of updating the roster.
For developers
Authenticate with a bearer key. Anything a person can do on a screen can be scripted, because the screen is calling the same endpoint.
Endpoints
kind and since; cursor-paginated.
Authorization: Bearer sk_live_...{
"changes": [
{
"id": "ch_3f9a2c",
"kind": "alert",
"type": "mco_changed",
"patient": { "id": "pt_81be04", "name": "Marjorie Alvarez" },
"facility": "river-bend",
"payer_type": "medicaid",
"field": "mco_name",
"old_value": "SENIOR WHOLE HEALTH",
"new_value": "WELLSENSE",
"effective_date": "2026-08-01",
"detected_at": "2026-08-11T05:04:12Z",
"severity": "high",
"source": "verification"
}
],
"next_cursor": "eyJ0IjoiMjAyNi0wOC0xMSJ9"
}
// Illustrative payload. Names are fabricated.// request
{ "types": ["medicare", "medicaid"] }
// response
{
"run_id": "run_5c1d0e",
"status": "queued",
"patients": 138
}// request — weekly, every Tuesday
{
"frequency": "weekly",
"day_of_week": 1
}
// response
{
"frequency": "weekly",
"day_of_week": 1,
"next_run_at": "2026-08-18T05:00:00Z"
}The quickest way to judge it is one facility, one check, and the list of what it found that nobody had noticed.
Tell us which buildings you run and which states they are in. We set the account up and make you an administrator on it.
Book a walkthroughGet an sk_live_ key, push a roster and pull the change feed against your own data.