Smile CQL decisions need policy-to-runtime traceability

The executable artifact must point back to controlling policy

A governed rule package should identify the payer legal entity, line of business and plan, benefit and service scope, jurisdiction, controlling policy and version, clinical criteria where applicable, effective and retirement times, policy owner, translator, review and approval, CQL library and dependency versions, terminology sets, FHIR profiles, test suite, build, and deployed environment. The prose source and executable artifact are related records, not interchangeable labels.

Translation decisions should be explicit where policy language depends on judgment, missing facts, precedence, exceptions, or facts not represented in the chosen data model. Preserve annotations that connect each executable clause to its source and route ambiguity to an authorized reviewer. A syntactically valid CQL library does not establish policy fidelity, clinical appropriateness, benefit accuracy, or authority to decide.

Every result needs its runtime evidence envelope

For each execution, retain member and coverage match, payer and plan, provider and facility, requested service and code set, diagnosis and clinical facts used, source resource identifiers and versions, data timestamps, missing or conflicting facts, policy and CQL versions, terminology release, execution time, result, reason path, exceptions, and downstream message identifiers. The record should show the exact inputs evaluated rather than only the final yes, no, or review-required state.

CRD, DTR, PAS, and legacy transactions answer different workflow questions. A requirement-discovery response, documentation session, submitted request, receipt, clinical review, determination, and status update should keep distinct identifiers and clocks. Real-time execution does not prove that every required fact was available or that an X12, portal, delegate, and FHIR route reached the same state.

Central governance must reach delegates without erasing authority

Smile positions the product for delegated partner ecosystems. A payer should therefore inventory which internal system or delegate owns each service, population, criterion, review, notice, appeal, and reporting obligation. Preserve rule-package distribution, acknowledgement, activation, rollback, interface, and reconciliation receipts by delegate. One central catalog is not evidence that the deployed logic is identical or effective everywhere.

The decision record should also identify who had authority to approve, pend, deny, or escalate the case. A deterministic result may qualify for straight-through handling only within an approved scope and complete-data condition. Conflicts, missing information, unsupported services, urgent cases, adverse outcomes, and clinical exceptions need transparent routing to qualified people without rewriting the machine result or presenting a recommendation as the payer's determination.

Test policy drift across data and delivery routes

A representative evaluation should encode a policy with an effective-date change, plan variation, code-set update, clinical exception, incomplete FHIR resource, conflicting attachment, delegate carve-out, urgent case, and prior request already in flight. Run boundary cases through CRD, DTR, PAS, and the relevant legacy handoff, then reproduce the result, reason, message receipts, human escalation, and notice from retained evidence.

Deploy a corrected rule while cases are pending and verify that historical decisions keep their original logic while affected open cases follow a documented transition rule. Smile's page establishes its CQL, FHIR, centralized governance, deterministic adjudication, and delegated-ecosystem positioning. It does not establish policy accuracy, clinical validity, transaction conformance, delegate alignment, decision authority, compliance, turnaround, or patient outcome.

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.