The Accord Dental Data Model

Accord Dental is, at its core, a rules engine that turns a proposed treatment plan and its supporting documents into an explained, defensible pre-determination. Understanding the data model is the fastest way to understand the product: it shows how a case moves from raw clinical documents to a decision where every signal traces back to a specific rule. The model is organized into four layers.

The reference layer: the rules the engine reasons against

The reference layer holds the relatively stable facts and rules a determination is evaluated against. It's the knowledge base:

Tenants, payers, plans, and providers — who the practice is, which insurers and plans are in play, and the rendering providers.
Patients — demographics and identity for the person being treated.
CDT codes — the ADA procedure code set, keyed so that coverage is resolved per payer and code.
The rule sets — ADA guidelines, bundling rules, the downgrade matrix, frequency limits, fee schedules, coverage rules, coordination-of-benefits rules, and clinical criteria.
Overlay rules — tenant-specific policies that sit on top of payer rules.

This layer is what makes the engine's reasoning traceable: every coverage decision resolves to a specific row here — an ADA guideline, a payer rule, or a tenant overlay.

The transactional layer: the case in front of you

The transactional layer captures a specific pre-determination as it comes in:

Pre-D requests — the case itself.
Procedure lines — the proposed CDT procedures, with tooth numbers and surfaces.
Eligibility profiles — the patient's coverage picture for this case.
Clinical evidence — the extracted documents (X-rays, perio charts, narratives, and more) that support the procedures.
Appeals — where a determination is contested.

This is the raw input: what's being proposed, for whom, under what coverage, backed by what evidence.

The computed layer: the engine's output

The computed layer is what Accord produces when it runs the reference rules against the transactional case:

Pre-D states — the assembled state of the determination, including readiness.
Condition instances — the specific conditions the engine flagged for this case.
Cost estimates — the line-by-line expected split between insurance and patient responsibility.
Payer responses — the modeled coverage outcome per procedure.
Pipeline events — telemetry about how the case moved through the pipeline.

This layer is derived, not entered — it's the engine's reasoning made concrete, and it's rebuilt from the inputs rather than hand-authored.

The evidence graph: how conclusions connect to proof

The final layer is a graph that links evidence to conclusions:

Evidence nodes — individual pieces of extracted evidence.
Evidence edges — the relationships between them: which evidence confirms, contradicts, or corroborates which conclusion.

The graph is what lets a determination explain itself. Rather than a black-box "approved" or "denied," Accord can show the chain of evidence and rules that produced the result — the basis for the product's principle that every pre-determination is explained, cited, and defensible.

How a case flows through the model

Put together, a case moves through the layers in order:

Ingestion — clinical documents come in and are extracted into the transactional layer's clinical evidence, deterministically where possible.
Assembly — eligibility, clinical, and coverage assemblers combine the transactional case with the reference rules.
Decision — the engine computes the pre-D state, cost estimate, and payer response in the computed layer, building an explicit decision trace as it goes.
Explanation — the evidence graph links each conclusion to the evidence and rule behind it.

The result is a determination that isn't just a number — it's a reconstructable decision, where every flag points to the ADA guideline, payer rule, or tenant overlay that produced it.

Why the layering matters

The separation between reference (rules), transactional (the case), and computed (the result) is deliberate. Because the computed layer is derived from the other two, a determination can always be rebuilt from its inputs — and because every rule lives as data in the reference layer rather than hardcoded in logic, updating a payer's policy is a data change, not a code change. That's what keeps the engine both auditable and maintainable as payer rules evolve.