Executive Summary
Claim 37 extends Claim 36's allegiance-firewalled dual-product architecture with a temporal dimension. Each check in the shared 332-check canon carries not only role-neutral logic but also an effective-date range and a citation to a specific version of the regulation or payer policy it implements. The identical check definition executes in two temporal directions: pre-bill, before a claim is submitted, to substantiate that a proposed claim complies (feeding the provider-facing AREB); and post-bill, after a claim has been paid, to detect that a paid claim did not comply (feeding the payer-facing PIEB).
Because both directions execute the same check_code against the same citation at the same effective-dated rule version, the provider's pre-bill substantiation and the payer's post-bill detection cannot silently diverge into two different interpretations of what the rule required on the date of service.
Problem Statement
Compliance rule catalogs drift. A provider-side vendor's "as of" interpretation of a coverage rule and a payer's "as of" interpretation of the same rule are typically maintained in separate systems, updated on separate schedules, by separate teams reading the same regulatory text independently. Over months or years those two copies diverge - not because either side is acting in bad faith, but because rule catalogs are living documents and nobody reconciles two independently maintained versions of the same rule as a matter of course.
The practical consequence is that a dispute over a paid claim often becomes a dispute about whose version of the rule is correct rather than a dispute about the facts of the claim itself - an argument that is expensive to resolve and, because the rule texts were never formally version-pinned to a citation, often unresolvable on the record.
Why Existing Approaches Are Insufficient
- Independently maintained provider and payer rule tables: Two copies of "the same" rule updated on different schedules will drift, and neither side has visibility into when or how the other's copy changed.
- Undated or citation-free rule logic: Many claims-editing systems encode current rule behavior without a persisted effective-date range or a citation to the specific regulatory version, making it difficult to reconstruct what the rule actually required on a historical date of service.
- Single-direction execution: A rule engine built only for pre-bill scrubbing or only for post-bill audit has no structural guarantee that its logic matches a counterpart engine running the other direction.
Technical Architecture
Canon Check Record Structure
| Field | Purpose |
|---|---|
check_code | Stable identifier shared by both execution directions |
effective_start / effective_end | Date range during which this version of the check applies |
citation | Reference to the specific statute, regulation, or payer-policy document and version implemented |
logic_definition | Direction-neutral evaluation logic, identical for pre-bill and post-bill execution |
Dual-Direction Execution
Pre-bill execution evaluates a proposed claim before submission, using the check_code version whose effective-date range covers the intended date of service, and reports a pass/fail substantiation result into the AREB pipeline. Post-bill execution evaluates an already-paid claim, using the check_code version whose effective-date range covers the claim's actual date of service - not the version current when the post-bill check happens to run - and reports a pass/fail detection result into the PIEB pipeline.
Date-of-Service Version Resolution
Resolving a check to its date-of-service-effective version, rather than the version current at execution time, prevents a later rule update from retroactively changing the outcome for claims filed under an earlier, still-applicable rule - a form of protection against unfair retroactive rule creep in either direction.
Canon Versioning Model
Because both AREB and PIEB resolve the same check_code against the same citation and the same effective-date range, a provider's pre-bill substantiation result and a later payer post-bill detection result on that identical claim are, by construction, evaluated under the identical rule interpretation. Any disagreement that remains is a genuine factual dispute about the claim - not an artifact of two rule catalogs that quietly diverged.
| Scenario | Provider-Side (Pre-Bill) | Payer-Side (Post-Bill) | Rule Version Used |
|---|---|---|---|
| Claim submitted and paid within canon's current effective range | AREB substantiation, direction A | PIEB detection, direction B | Same citation, same version |
| Rule updated after date of service, before post-bill review | Already evaluated at time of submission | Re-evaluated at date-of-service version, not current version | Historical version pinned to date of service |
Prior Art Differentiation
| Approach | Version-Pinned to Citation? | Shared Definition Both Directions? | Date-of-Service Resolution? |
|---|---|---|---|
| Independently maintained provider / payer rule tables | Rarely | No | Inconsistent |
| Generic claims-editing rule engines | Sometimes (current version only) | N/A (single direction) | Often uses execution-time version |
| JIL Sovereign Effective-Dated Canon | Yes, every check | Yes, identical definition | Yes, pinned to date of service |