Documentation›End-User Guide›Chapter 0
Chapter 08 min readLast reviewed: May 2026

Overview & Glossary

Welcome to Rendum

Rendum is a multi-tenant Medicare Advantage eligibility and billing platform. It ingests payer contracts, processes eligibility files, applies a deterministic rules engine, and produces per-member-per-month billing decisions with an audit chain you can show an auditor on demand.

This guide is for the end-users who run the platform day-to-day — billing operations, customer-success teams, and tenant administrators. Each chapter is self-contained; the order matches the natural workflow (set up payers and contracts, ingest eligibility, run billing, export, audit).

How the platform works

You upload payer contracts; Rendum's Layer 0 AI pipeline extracts a structured rule configuration from each contract. You ingest eligibility files from your payers (and optionally service-delivery files); Layer 1 / 1b parse the files, resolve members against your roster, and write events into a per-member state machine. At month-end you trigger a billing run; Layer 2 (the rules engine) reads the state and the active rule per payer and decides who bills, for how many days, at what rate. Layer 3 packages the decisions into a billable roster CSV, an audit package PDF, and (on demand) evidence bundles. Everything that touches billable state writes an immutable, hash-linked audit row.

Glossary

The following terms appear throughout this guide. Skim once; refer back as needed.

Tenant
Your organization on the platform. Every record is tenant-scoped; cross-tenant access is impossible.
Org Unit (optional)
A sub-division within a tenant (region, line of business) used for RBAC partitioning.
Payer
A Medicare Advantage organization you contract with. Every contract, rule, member roster, and billing decision is associated with one payer.
Contract
The PDF document a payer sends describing rates and rules.
Rule configuration
The structured representation of a contract; the active rule per payer drives billing decisions.
Member
An individual enrolled with one of your payers. Members have eligibility events, service-delivery events, and decision history.
Eligibility file
A file (CSV / XLSX / EDI 834) from a payer asserting who is eligible for the upcoming period.
Service-delivery file
A file describing services actually rendered to members. Required by payers whose rule sets requiresServiceDelivery: true.
Member state
The per-member, per-payer state machine: Active / Suspended / Terminated / Pending plus effective and termination dates.
Billing run
A month-end (or ad-hoc) job that produces decisions for every active member across selected payers.
Decision
The per-member-per-month output: billable / not-billable, days, rate, charge, reason.
Decision class
The enum that explains a decision: BILLED_ACTIVE, NOT_BILLED_RETROACTIVE, NOT_BILLED_NO_SERVICE, BILLED_PARTIAL_TERM, etc.
Retroactive window
The period after the asserted effective date during which Rendum allows late-arriving evidence to change a decision. Defined per payer in the rule configuration.
Triggering service events
The service-delivery rows that justified a billed-active decision under service-delivery reconciliation (Layer 2). Carried on the decision so auditors can trace it back.
Combined benefit
A payer-specific arrangement where two services bill jointly under a single primary code + secondary suffix. Resolved by the combined-benefit resolver (Layer 3).
Audit trail
The append-only, hash-linked record of every action.
Audit chain
The cryptographic hash chain that links each audit row to the prior one.
Audit package
The PDF + manifest export of a billing run, suitable for handing to an external auditor.
Evidence bundle
The deeper ZIP export targeting a single decision, including input files + rule snapshot + decision trace + audit-chain segment.
Exception
A row the platform flagged during ingestion or rule evaluation that needs human resolution.
Layer 0
The AI pipeline that turns contract PDFs into rule configurations.
Layer 1
Eligibility file ingestion.
Layer 1b
Service-delivery file ingestion.
Layer 2
The deterministic rules engine that produces decisions.
Layer 3
Output: rosters, audit packages, evidence bundles.
Confidence tier
The Layer 0 classification of how confident the AI is in an extracted rule field: AUTO_ACCEPT, NEEDS_REVIEW, MANDATORY_REVIEW, HUMAN_REQUIRED.
PHI
Protected Health Information. Encrypted at rest under a tenant-scoped key in Azure Key Vault.
MBI
Medicare Beneficiary Identifier. A PHI field; encrypted.
RBAC roles
OWNER, ADMIN, BILLING_MANAGER, OPERATIONS, VIEWER — in descending order of privilege.
SSO
Single Sign-On. Rendum supports SAML and OIDC per tenant.

The agent layers, briefly

  • Layer 0 ingests contracts. Output: signed-off rule configurations per payer.
  • Layer 1 ingests eligibility files. Output: EligibilityEvent rows plus MemberState updates.
  • Layer 1b ingests service-delivery files. Output: ServiceDeliveryEvent rows plus lastServiceEventAt / hasServiceInCurrentMonth.
  • Layer 2 runs the rules engine. Output: decisions persisted to the database, with 100% test coverage enforced in CI.
  • Layer 3 packages output. Output: roster CSVs, audit packages, evidence bundles.

What this guide covers

  • Chapter 0 — Overview & Glossary (you are here)
  • Chapter 2 — File ingestion (eligibility upload, schema review)
  • Chapter 3 — Rules & Contracts (review, sign-off, override)
  • Chapter 4 — Billing run (trigger, monitor, regenerate)
  • Chapter 5 — Exceptions (queue, resolve, escalate, dismiss)
  • Chapter 6 — Exports (rosters, audit packages, evidence bundles)

The Admin Guide covers tenant configuration, users and roles, payer + contract administration, integrations, and file-source setup.

Where to get help

  • In-app: every page has a "?" icon (coming soon) that opens a contextual help drawer with the relevant chapter.
  • Email: support@rendum.io.
  • Status: status.rendum.io for platform health.
Next →
Chapter 2 — File ingestion