Concurrent Review and the 278 Extension: Getting Continued-Stay Right

Initial prior authorization gets the attention — it is what CMS-0057-F regulates most directly and what the FHIR tooling was built around. But ask any UM operations lead where the actual grief lives and the answer is usually concurrent review: the patient is already in the bed, the approved days are running out, and the hospital's case manager and your reviewer are negotiating a continued stay against a clock that started before anyone opened the file.

This article covers how continued-stay review is supposed to work, how the X12 278 models it, which decision clocks actually govern it, and the two places the workflow reliably breaks.

What concurrent review is, mechanically

Concurrent review is utilization review conducted during the care it evaluates — most commonly an inpatient admission, but also ongoing outpatient courses like home health episodes, therapy series, or behavioral health programs. The initial review certifies the admission and some quantity: a number of days, visits, or units. Concurrent review then re-evaluates medical necessity as the stay progresses, in cycles: the facility submits updated clinical, the reviewer certifies additional days or declines, and a next-review date is set. Discharge planning runs in parallel, because the honest output of a continued-stay review is as often "ready for a lower level of care" as it is "more days."

Two structural facts distinguish it from initial review. First, there is an existing certification — a reference number, an approved quantity, an end date — so every subsequent request is an amendment to something, not a fresh question. Second, denial mid-stay is a reduction or termination of already-approved care, which regulators treat far more severely than a prospective denial. The ERISA claims-procedure regulation at 29 CFR 2560.503-1 makes any reduction or termination of an approved ongoing course of treatment an adverse benefit determination that must be noticed early enough for the member to appeal before the care stops.

How the 278 models it: UM02 and friends

The 278 carries the continued-stay lifecycle in the UM segment's certification type code. An admission arrives as UM02 I — initial, usually under the AR admission review request category. The continued-stay request is UM02 4 — extension: more of the same certified service, beyond the approved period or quantity, tied to the original certification. Its neighbors complete the picture — R (renewal) starts a new certification period for a recurring service, S (revised) changes the substance of what was certified (the level-of-care change lives here), and the appeal types pick up after an adverse determination.

The operationally load-bearing rule: an extension must carry the original certification number so the payer can locate the authorization being extended. Extensions that arrive without it, or with the number mangled by an intermediary, fail matching and bounce as AAA rejections — the payer literally cannot find what you are asking to extend. On the response, the HCR action codes do the same work as on an initial request: A1 certifies the extension in total, A2 partially certifies (three more days, not seven — the most common concurrent outcome), A3 declines, A4 pends for clinical. A partial certification on an extension is where quantity accounting gets subtle: systems must record approved units cumulatively against the stay, not per-transaction, or downstream claims matching will disagree about what was authorized.

Whose clock governs a continued-stay decision

Here is where operations teams get tangled, because the CMS-0057-F timeframes everyone memorized in 2026 — 72 hours expedited, 7 calendar days standard — were written for prior authorization requests, and a continued-stay decision usually cannot wait for either. The applicable clocks come from several overlapping sources, and the strictest one wins:

• ERISA plans (self-funded and insured group coverage). Under 29 CFR 2560.503-1(f)(2)(ii), an urgent-care request to extend an ongoing course of treatment, made at least 24 hours before the approved period expires, must be decided within 24 hours of receipt. Miss the 24-hour filing window and the request falls into the ordinary urgent-care track (72 hours) instead.
• Accreditation. NCQA's UM timeliness standards expect notification of urgent concurrent decisions within 72 hours of the request across product lines — a bound NCQA aligned in its 2025 standards year, moving commercial and Exchange from the older 24-hour notification expectation. Accredited plans are audited against these rates, delegate or not.
• Medicaid managed care. 42 CFR 438.210(b) sweeps requests for "initial and continuing authorizations of services" into the same contractual machinery, with the expedited 72-hour path available whenever the standard timeframe could seriously jeopardize the enrollee's health — which describes most continued-stay requests for a patient currently admitted.
• Contracts. Hospital agreements frequently promise concurrent determinations within one business day of receiving complete clinical. That private SLA can be stricter than any of the above.

The practical consequence: a continued-stay queue cannot share SLA logic with the standard prior-auth queue. Each request needs a computed deadline derived from product line, urgency, and the expiration date of the current approval — the same discipline argued for in pend management under the 72-hour clock, with one addition unique to concurrent review: the deadline that matters most is often not "decision due" but "current approval lapses."

Where continued-stay workflows actually break

Midnight discharges and the lapsed-approval gap. Approved days expire at a day boundary; patients do not. A stay approved through Tuesday whose extension request arrives Wednesday morning is, formally, a request to extend an authorization that has already lapsed — some systems reject it outright, others silently reclassify it as retrospective review with a 30-day clock nobody intended. The ERISA regulation's 24-hour rule only attaches when the request beats the expiration by 24 hours, so a facility that submits at hour 23 has, by rule, a slower clock than one that submitted a day earlier. Operationally, the fix is on both sides: facilities need next-review dates that trigger submission at least a day before lapse, and payer intake needs an explicit policy — documented, not tribal — for extensions received within some grace window after expiration, so they are worked as concurrent rather than bounced into the retrospective pile while the patient is still in the bed.

Level-of-care changes mid-stay. A patient stepping down from ICU to med-surg, or from acute to skilled nursing, is not an extension of the same service — it is a different certified service, which the 278 models as a revised certification (or a new request for the new setting), not UM02=4. Case managers under time pressure submit it as an extension anyway, because that is the button that references the existing auth. The result is an authorization whose certified level of care no longer matches the care being delivered, which surfaces months later as a claims dispute. Intake teams should treat "extension with a different revenue code or service type" as a red flag to re-route, and payer portals and 278 intake edits can catch it at the front door instead of in claims.

One more edge worth naming: concurrent review generates the densest event history of any authorization type — multiple decisions, changing quantities, shifting end dates, all against one certification number. If your systems overwrite current state instead of appending events, you cannot reconstruct what was approved as of a given service date, and both appeals and audits will eventually require exactly that reconstruction.

Verify transaction specifics against the X12 005010X217 TR3 and your payers' companion guides, and the clock requirements against 29 CFR 2560.503-1, 42 CFR 438.210, and the NCQA UM standards for your current accreditation year.