Data Model
The core entities Alvero reasons over, and how they map to public structured-data vocabularies for SEO and AEO.
Core entities
| Entity | Purpose | Key fields |
|---|---|---|
| Practice | The tenant boundary | id, name, NAP, timezone, PMS connection |
| Provider | A dentist or hygienist | id, practiceId, name, role, license |
| Appointment | A scheduled visit | id, practiceId, providerId, patientId, start, status, CDT codes |
| Claim | An insurance claim | id, practiceId, cdtCodes[], payer, status, amountCents |
| Patient | A person of record (PHI) | id, practiceId, demographics, balance, recallStatus |
Practice
The root tenant. Every record is scoped to a practiceId; cross-tenant access is impossible by design at the Worker layer.
Provider
Drives chair utilization, production attribution, and the per-provider morning briefing.
Appointment
Source for same-day production, hygiene utilization, and recall pipeline. Emits appointment.created / appointment.updated.
Claim
Feeds AR aging and the EOB Verification Agent. Emits claim.submitted / claim.adjudicated.
Patient
PHI-bearing. Access is logged at the row level with reviewer attribution; outbound communication is gated by human approval.
schema.org mapping
Each Practice maps to a schema.org/Dentist entity (name, address, telephone, geo, medicalSpecialty, areaServed) — the same structured data published in the homepage @graph for the four owner-network practices.
{
"@type": "Dentist",
"name": "Kelowna Dental Centre",
"medicalSpecialty": ["GeneralDentistry","CosmeticDentistry"],
"areaServed": { "@type": "City", "name": "Kelowna" }
}