GuidingCare needs three records for three stages of utilization review

One case can contain several review questions

HealthEdge's current GuidingCare page presents a utilization-management module supporting the authorization lifecycle, including peer, physician, and concurrent-review workflows and integrations with evidence-based guideline products. Its explanatory material identifies prospective, concurrent, and retrospective review as different assessments. That distinction is operationally important because the service timing, available evidence, decision question, and consequence can change across the same episode of care.

Prospective review concerns planned care before it occurs. Concurrent review evaluates care while it is being delivered and may depend on evolving clinical information and requested duration. Retrospective review examines care after delivery under the applicable policy and facts. A generic authorized, denied, or complete label cannot explain which review occurred, what period and service it covered, or whether a later stage changed the operational position.

Give each stage its own scope and clock

The record for each stage should identify the member and requester, payer and plan context, service and codes, site and provider, requested dates or units, review type, request and receipt times, documentation set, policy and guideline versions, reviewer role, decision criteria, determination, reason, effective scope, communication, additional-information loop, appeal rights where applicable, and source transaction or correspondence.

Turnaround measurement also needs a stage-specific clock. Intake, complete-information receipt, clinical review, peer review, extension, decision, notice, and implementation are different timestamps. Pausing a clock for missing material should preserve who requested what, when it was supplied, and which rule allowed the pause. Otherwise a single elapsed-time figure can hide whether the delay occurred before a complete request, during review, or after determination.

Link transitions without carrying conclusions forward blindly

A prospective determination may authorize a defined service and period without resolving later medical necessity for additional days. A concurrent review may modify scope based on new facts without rewriting the earlier determination. A retrospective review may address a different question and should not be presented as if it were the original prospective response. Every transition needs a dated relationship to the prior state and an explanation of what remained effective.

Criteria integration should preserve the guide, version, section, inputs, output, reviewer interpretation, exception, and final payer authority. An automated or guideline-supported recommendation is not interchangeable with a payer determination or provider action. If policy, eligibility, benefit context, coding, or clinical evidence conflicts, the workflow should route the ambiguity and retain both inputs rather than selecting a convenient status.

Test an episode that changes after care begins

A representative evaluation should submit a prospective request, receive an approval with bounded dates and units, begin care, request additional days through concurrent review, supply new documentation, receive a partial determination, and later open a retrospective review. Reviewers should reconstruct each question, clock, evidence set, criteria version, authority, notice, and effective scope while seeing how the stages relate without overwriting one another.

HealthEdge's official page supports the described authorization-lifecycle, review-workflow, guideline-integration, and three-assessment positioning, but no member, benefit, policy, request, clinical record, guideline result, determination, notice, appeal, integration, implementation, or outcome was independently tested here. Payers, providers, clinicians, and their compliance and legal owners retain the applicable clinical, coverage, operational, regulatory, and payment decisions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Prior Auth Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.