CMS: A CRD check does not start the decision clock

Model discovery and submission as different events

The direct answer is that a coverage-requirements inquiry should create a discovery record, not an authorization-request receipt. Preserve member and coverage context, provider, proposed item or service, codes, date of service, payer endpoint, rule and implementation-guide versions, request and response identifiers, response time, whether authorization is indicated, and the documentation guidance returned. That evidence explains what the provider was told before submission without inventing a payer case or clock.

The actual submission record should identify the authorization request, included services and units, urgency, supporting documentation, sender, channel, payer endpoint, transmission time, technical acknowledgement, payer receipt event, payer case identifier, and any discrepancy between those events. A successful API response, clearinghouse acceptance, or provider-side sent status may not be the same event the payer uses as receipt. The operating contract should define and test which evidence starts the applicable decision timeframe.

Keep the clock running through information requests

CMS's FAQ says the clock does not stop or restart when a payer asks for additional documentation that was not disclosed when the provider submitted the original request, while noting that an extension may be available under applicable program requirements. The case record should therefore retain original receipt, applicable standard or expedited timeframe, due time, information request, disclosed-requirement comparison, provider response, any extension basis and notice, and the unchanged or adjusted deadline with its authority.

A missing-document status should not silently reset elapsed time. Distinguish a request that was never received, a syntactically rejected transmission, an accepted but incomplete request, a payer request for additional information, a provider supplement, an authorized extension, and an administratively closed case. Each state needs a source event, reason, owner, and clock consequence. Qualified program, clinical, operational, compliance, and legal owners should resolve ambiguity rather than letting integration logic choose the most favorable timestamp.

Separate response type from substantive determination

CMS says the payer's API response must approve and specify when the authorization ends, deny with a specific reason, or request information needed for a decision. Store those response classes separately from transport status and from internal clinical-review steps. An approval should retain scope, units, conditions, effective and end criteria; a denial should retain specific reason, criteria and evidence; an information request should state what is needed and how it affects the open case. None should be inferred from a generic completed flag.

The final record should also distinguish determination time, notice generation, notice delivery, provider acknowledgement, member communication, appeal right, appeal submission, and any later reversal. Metrics based on submission-to-determination intervals need the same event definitions used in operations. Combining CRD traffic, duplicate transmissions, episodes of care, information exchanges, and appeal decisions can produce a plausible dashboard that does not reflect the individual prior authorization requests CMS says must be counted.

Test one service from discovery through appeal

A representative test should run CRD for one service, change the returned documentation guidance, submit a standard request, delay the payer receipt event, ask for an undisclosed document, apply and reject an extension, deny with a specific reason, deliver the notice, and reverse the decision on appeal. Reviewers should reproduce every message, version, receipt, clock calculation, user action, clinical determination, notice, appeal, and metric inclusion without treating discovery as submission.

CMS's official FAQ supports the described CRD function, receipt-based clock start, information-request treatment, response classes, decision timeframes, metrics boundaries, and individual-request counting. It does not establish how a particular payer endpoint behaves, which program rule applies to a case, request completeness, medical necessity, authorization, payment, notice compliance, appeal result, or patient outcome. Qualified payer, provider, clinical, program, interoperability, compliance, privacy, security, and legal owners retain their 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.