Maryland home-care margin recovery: when the claim is built from a check-in that did not match.

Maryland did something most states did not. It built a single state-run system that captures the visit and generates the claim from the same record. The In-home Supports Assurance System (ISAS), inside the LTSSMaryland platform, is where personal-care visits are checked in and checked out, and it is also where the claim is built. That tight coupling is efficient when everything lines up. When it does not, the failure is unforgiving, because there is no separate billing step where a human catches the gap. The exception is generated at the source, and if nobody clears it, the visit simply does not pay.

This page is about where that money leaks in Maryland specifically, and why catching it means reading your ISAS records against the authorization rather than trusting that a delivered visit turned into a paid claim.

One state system that both verifies the visit and builds the claim

Most states layer EVV on top of a separate billing system, so the visit is captured in one place and the claim is built in another. Maryland collapsed that. ISAS is both the visit-verification system and the electronic billing system for personal care. A worker checks in and out by phone, by the LTSSMaryland mobile app, or with an assigned one-time-password token, and ISAS verifies the provider, by Medicaid number and worker identifier, the person, by phone number or token, and the service, against the authorized person-centered plan.

Because the claim is generated from that check-in and check-out record, the quality of the verification is the quality of the claim. There is no second pass where a biller reconciles the visit to the authorization. If the visit data and the authorization do not agree at the moment of capture, the claim that flows out of ISAS carries that disagreement straight into an exception. Maryland built ISAS for personal care before the federal Cures Act deadline of January 1, 2021, so this is a mature, deeply embedded system, not a recent bolt-on.

Service code, participant, and the authorization window

Here is the Maryland-specific mechanism. Three things have to reconcile for an ISAS visit to bill clean. The EVV service code must match the authorized service type. The participant identifier must match an active Medicaid authorization. And a visit that falls outside an active authorization window generates an exception regardless of whether care was delivered.

That third point is the one that quietly costs the most. Authorizations have start and end dates, and the world of care does not always wait for the paperwork. A reauthorization that lapsed for a few days, a visit delivered just before a new authorization posted, a service that shifted between programs, any of these can put a genuine visit outside the active window, and ISAS treats it as an exception. The care happened. The claim did not build clean. EVV claims already in the system can be adjusted to correct errors, but only if someone finds them. The reliable way to find them is to reconcile the ISAS records against the authorizations rather than wait for the exceptions to surface on their own.

Where the margin actually leaks in Maryland

From the way Maryland wires ISAS, the authorization, and the claim together, the recoverable losses cluster in a few predictable places:

• Authorization-window exceptions. Visits delivered outside an active authorization window, held as exceptions even though the care was real. This is the most Maryland-specific leak, because ISAS generates the exception at the source.
• Service-code mismatches. The ISAS service code not matching the authorized service type, so the claim does not bill clean.
• Participant identifier gaps. A visit whose participant identifier does not tie to an active Medicaid authorization at the moment of check-in.
• Program-boundary drift. A member moving across Community First Choice, CPAS, or the Community Options Waiver, where the authorized service and the billed service fall out of step.
• Silent underpayments. Claims that pay below the expected rate, never flagged as a denial, visible only when payment received is compared against payment expected, line by line.

None of these are visible from inside the scheduling view. The schedule says the visit happened. ISAS says the worker checked in. It is only when you reconcile the ISAS check-in and check-out records against the authorizations and the actual remittances that the gap appears.

Why a read-only recovery layer is the right tool for this

Reeve sits read-only over whatever EMR and ISAS export an agency already runs, alongside whatever scheduling and billing system it uses, whether that is WellSky, AxisCare, HHAeXchange, AlayaCare, or anything else, and compares what was delivered with what was authorized and what was actually paid. For a Maryland agency, that means lining up the ISAS check-in and check-out records, the claim lines, and the authorizations, then surfacing every place they fail to reconcile: the authorization-window exceptions, the service-code mismatches, the participant gaps, and the silent underpayments.

Because Reeve is read-only and neutral across every EMR, it never writes to your billing workflow without your control, and it has no reason to look past a finding that implicates a billing module. It hands you a ranked list of recoverable dollars with the reason attached, the window exception or the code mismatch. The ones still inside the 12-month window are the ones you can rebill now.

This is the same engine described across the rest of the site. For the broader map of revenue loss in home care, see where home-care margin leaks. For the authorization side specifically, see home-care authorization tracking. For the full playbook on getting uncollected revenue back, see home care revenue recovery.

What the free Maryland Margin Teardown does

The way to find out whether ISAS exceptions and authorization-window gaps are draining your margin is to look at a real, de-identified slice of your own data, before you spend a dollar. The Margin Teardown is a one-time, read-only read of where margin is leaking in your book: the window exceptions, the code mismatches, the authorization gaps, and the underpayments. It is free, and it is yours to keep whether or not you ever work with Reeve. It carries the same 3×-or-free guarantee the rest of the engine does. If Reeve does not surface at least three times its monthly fee in recoverable margin you agree is real, you do not pay.