Zorva

How Zorva works

What the auditor reads, what rules it pulls, how findings surface to your biller for review, and what the audit trail looks like under the hood. For the technical buyer in your clinic.

Open the sample claim

The audit loop in 4 steps

  1. 1

    Claim arrives at the auditor

    Every claim is an 837P payload. The auditor parses it into a structured object: encounter_id, patient_id, rendering_provider_npi, date_of_service, line_items[] (CPT + modifiers + dx pointers + units), and diagnosis_codes[]. Alongside it, the biller has attached the clinical note (a paste field, a CSV upload, or a fetched-from-EMR blob).

  2. 2

    Rules are retrieved

    From the structured claim, the auditor fetches the applicable AHCIP rules. v12 ships with 18 rules covering modifier-25, telehealth, CMGP, lab coverage, the most-common AHCIP denial codes, and the per-claim-shape trigger phrases that fire them.

  3. 3

    Auditor prompts the LLM

    The claim + the applicable rules + the clinical note are passed to the LLM as a structured prompt. Temperature 0, seed pinned, model version pinned — re-running the same input produces the same findings. The LLM emits a JSON array of findings, each citing the rule_id, the quote from the note, the suggested code, and a one-line explanation.

  4. 4

    Findings surface to the biller

    Each finding is on the encounter-detail page with the rule, the quote, the fix recommendation, and the per-finding dollar impact. The biller accepts the real ones, dismisses the false positives, and submits. Every state-changing click is appended to the hash-chained audit trail.

The 18 AHCIP rules in v12

The ruleset is grouped into three buckets: high-severity (likely to cause a denial), medium-severity (likely to cause an underpayment), and low-severity (coding-hygiene). Trigger phrases in the clinical note pull each rule into the candidate set; the LLM emits the finding.

High severity — 5 rules
  • rule_ahcip_referring_npi — Specialist referral on file but no referring_provider_npi on the 837P. AHCIP denial 80G.
  • rule_ahcip_modifier_25_unlock — Procedure + E/M same-day without -25 on the E/M. Bundled underpayment.
  • rule_ahcip_non_insured_service — Service billed to AHCIP that is non-insured (e.g. cosmetic, AWV, HMV). Unbillable rejection.
  • rule_ahcip_cmgp — GP performing a same-day procedure without CMGP modifier. 50% visit-line underpayment.
  • rule_ahcip_telehealth_consent — Telehealth visit without documented patient consent. AHCIP GR 3.3.
Medium severity — 7 rules
  • rule_ahcip_lab_coverage — Lab billed without an AHCIP-eligible diagnosis pointer.
  • rule_ahcip_dx_linkage — Line item with no diagnosis pointer; bundling risk.
  • rule_ahcip_preventive_opportunity — Patient eligible for a preventive service that wasn't billed.
  • rule_ahcip_consultation — Specialist consult billed without prior-referral documentation.
  • rule_ahcip_after_hours — After-hours premium code eligible based on service time, not applied.
  • rule_ahcip_duplicate_service — Same procedure billed twice in a 30-day window for the same patient.
  • rule_ahcip_age_inappropriate — Service billed that is age-restricted (e.g. pediatric vaccine on adult).
Low severity — 6 rules
  • rule_ahcip_modifier_pair — Modifiers that should be paired but aren't (e.g. -25 and -57).
  • rule_ahcip_place_of_service — Place-of-service code inconsistent with the procedure.
  • rule_ahcip_units_cap — Units billed exceed the per-day cap for the procedure.
  • rule_ahcip_fee_sched — Billed amount inconsistent with the AHCIP fee schedule.
  • rule_ahcip_time_threshold — Time-based code missing duration documentation.
  • rule_ahcip_rolling_window — Service violates a per-time-period rolling cap (e.g. annual physical limit).

Determinism contract

Every audit run is reproducible. The same input produces the same output, byte-for-byte, across runs.

  • Temperature 0. Set on the LLM call. The model emits the highest-probability token at every position.
  • Seed pinned. Set on the LLM call. The model’s internal RNG is initialized to the same value every time.
  • Model version pinned. Set on the LLM call. The model identifier (e.g. MiniMax-M3-2026-06-23) is part of the request, not a default.
  • Ruleset pinned. v12 + 18 rules. Any change to the ruleset is a new prompt version with its own MANIFEST entry.

Re-running a prior encounter — same clinical note, same claim payload, same v12 prompt — produces the same findings. The /security page has the full reproducibility contract.

The hash-chained audit trail

Every state-changing click (accept, dismiss, flag, encounter upload, contact submission) is appended to a hash-chained JSONL log. Each row's cryptographic_signature is computed as: 

SHA-256(
  prev_signature ||
  tenant_id ||
  user_id ||
  event_type ||
  timestamp ||
  payload_canonical_json
)

A privacy officer can re-export the log and re-verify the chain offline. Any tampering — even one byte — breaks the chain at the tampered row. The dashboard exposes a "verify chain" command for tenants with the privacy_officer role.