The system of record for a dental practice.
Scheduling, patients, claims, eligibility, and ERAs live in one inspectable platform. Practice websites and marketplace partners read a vendor-neutral public availability contract and submit booking intent. They never become the calendar. They never see PHI.
One calendar. One source of truth.
The same ISchedulingAvailabilityService is canonical. A marketplace adapter is a channel, not a second calendar.
Public intake, isolated by design.
IntakeService is internet-facing, disabled by default, API-key and rate-limited. It has no read access to patient, clinical, or scheduling databases.
Source you can inspect.
Apache 2.0. Read the contracts, the booking flow, and the isolation boundary. No black box.
From a free slot to a confirmed appointment.
Partners see bookable time. Staff remain the authority. BookingRequest is not an Appointment.
1 · Availability
GET free slots. JSON and .ics expose only bookable time, with an opaque encrypted availabilityToken. Slugs, not database ids.
2 · Intent
POST booking-request returns 202 and publishes BookingRequestedEvent. Staff approve later. The slot is revalidated server-side.
3 · Review
The portal matches or creates the patient, then approves, rejects, or asks for follow-up.
4 · Record
Only after staff action does the practice calendar hold a confirmed event. Partners never write it.
Conceptual flow. Exact adapters are validated per practice. Scheduling APIs →
A website should not become a second calendar.
Practice sites and marketplace partners need bookable time. They should not own the operatory, see PHI, or write appointments. Cloud Dental Office keeps the calendar inside the practice. Partners consume a vendor-neutral availability contract and submit intent. If the bus is down, intake returns 503 so the website can fall back to email. Scheduling outages do not lose bookings.
Read the public contract →Bounded contexts, already built.
Each service is its own context behind a YARP gateway. The portal is Blazor Server. The public edge is IntakeService — and only IntakeService.
Patient
Demographics, insurance, search.
Scheduling
Appointments, operatories, provider calendars.
Claims
Lifecycle and 837D generation.
Eligibility
270/271 verification.
ERA
835 processing and posting.
Auth
Tenant-aware identity and JWT issuance.
e-Prescribing
DoseSpot / EPCS.
AI Vision
privaseeAI and insurance-card OCR.
Intake
Isolated public booking and availability.
Cloud Dental Office is the practice surface. Cloud Health Office is the payer.
Staff see lifecycle status, a timeline, patient responsibility, and posted financials — not X12 transactions or clearinghouse vendors. Claim submission goes to Cloud Health Office. Intelligence comes back through a practice-facing API.
What is ready
- Claim submission to Cloud Health Office — implemented.
- Claim intelligence API (status, timeline, responsibility) — implemented.
- Posted financials to the patient ledger — implemented.
- Eligibility via payer transaction router — in progress.
- Predetermination / advanced EOB — reserved.
From first call to a scoped pilot.
Evaluate the source yourself. Then we scope a public-intake channel for one practice.
1 · Align on scope
We map the practice calendar, website, and any marketplace channel. We agree what IntakeService will expose — and what it will not.
1–2 weeks
2 · Enable public intake
API key, rate limit, practice timezone, booking horizon. Disabled by default until you turn it on. The website keeps an email fallback.
1–2 weeks
3 · Pilot a channel
Staff review booking requests in the portal. Partners stay on the public contract. The calendar remains the practice’s.
Ongoing
Evaluate on your own, or talk about a pilot.
Engineers can clone the repo today. Practice operators can tell us what they are running. We reply in person — no automated queues.
Keep the calendar. Let partners read slots.
Source-available. Apache 2.0. Deployed beside the practice, not instead of it.