Cloud Dental Office

Modern SaaS Practice Management Platform for Dental Providers

A cloud-native, microservices-based dental practice management system built from the ground up with .NET 8, Blazor Server and deep payer interoperability.

---

Architecture

Cloud Dental Office uses a microservices architecture with each bounded context deployed as an independent service:

┌─────────────────────────────────────────────────────────────┐
│                    Blazor Server Portal                      │
│         (MudBlazor · Dark Theme · Real-time · AI Vision)     │
└──────────────────────────┬──────────────────────────────────┘
                           │
                    ┌──────┴──────┐
                    │ API Gateway │  ← YARP Reverse Proxy
                    │   :5200     │
                    └──────┬──────┘
         ┌─────────┬───────┼───────┬──────────┬──────────┬──────────┐
         │         │       │       │          │          │          │
    ┌────┴───┐ ┌───┴────┐ ┌┴─────┐ ┌┴────────┐ ┌┴──────┐ ┌┴─────┐ ┌┴─────────┐
    │Patient │ │Schedule│ │Claims│ │Eligiblty│ │  ERA  │ │ Auth │ │Rx (EPCS) │
    │Service │ │Service │ │Svc   │ │Service  │ │Service│ │  Svc │ │ :5107    │
    │ :5101  │ │ :5102  │ │:5103 │ │ :5104   │ │ :5105 │ │:5106 │ └─────┬────┘
    └────┬───┘ └───┬────┘ └┬─────┘ └┬────────┘ └┬──────┘ └┬─────┘       │
         │         │       │        │           │         │             │
         │         │       │        │           │     ┌───┴──────┐      │
         │         │       │        │           │     │AI Vision │      │
         │         │       │        │           │     │ Service  │      │
         │         │       │        │           │     │ :5108    │      │
         │         │       │        │           │     └────┬─────┘      │
         │         │       │        │           │          │            │
         └─────────┴───────┴────────┴───────────┴──────────┴────────────┘
                        PostgreSQL (per-service DB)
              ┌──────────────────────┴────────────────────┐
              │  privaseeAI Edge Devices (IP Cameras,     │
              │  Tablets, Raspberry Pi) + Azure AI Vision │
              └───────────────────────────────────────────┘

Services

Service	Port	Description
Portal	5000	Blazor Server UI — dashboard, patient management, claims, scheduling, e-prescribing, AI vision
API Gateway	5200	YARP reverse proxy routing to all backend services
PatientService	5101	Not deployed. Patients live in the Portal database; Zocdoc patient resolution uses the Portal's internal-only port 5091. Kept in the repo pending retirement.
SchedulingService	5102	Appointments, operatory management, provider calendars
ClaimsService	5103	Claim lifecycle (draft → submit → adjudicate), 837D generation
EligibilityService	5104	Real-time 270/271 eligibility verification
EraService	5105	835 ERA file processing, claim matching, auto-posting
AuthService	5106	Tenant-aware identity, membership-derived roles, password verification, and short-lived JWT issuance
PrescriptionService	5107	e-Prescribing with DoseSpot integration, EPCS compliance, Surescripts certified
VisionService	5108	AI vision platform — privaseeAI integration, insurance card OCR (Azure AI Vision), narcotics cabinet monitoring, consent recording, clinical note generation
IntakeService	5109	Isolated public intake. Publishes validated booking requests and stores only minimized, durable integration-inbox records; it has no read access to patient/clinical systems.

Shared Libraries

• CloudDentalOffice.Contracts — DTOs, integration events, and API contracts shared across services
• CloudDentalOffice.EdiCommon — Clean-room X12 EDI parser and generators (837D, 270/271, 835)
• CloudDentalOffice.Messaging — Service Bus event-publishing abstraction (IEventPublisher)

---

Public Website Booking Intake

Practice websites (e.g. 3rd Set Smiles) submit appointment requests through a dedicated public service with no read access to patient, clinical, or scheduling databases. It accepts only the minimum information necessary for appointment intake.

flowchart LR
    Website[Practice website] --> Intake[IntakeService]
    Intake --> Bus[Service Bus]
    Bus --> Request[BookingRequest]
    Request --> Review[Staff review]
    Review --> Patient[Match or create patient]
    Patient --> Approval[Approve & Schedule]
    Approval --> Appointment[Appointment]

BookingRequest is the visitor's scheduling intent. Appointment is a practice-confirmed event created only after staff review and approval.

IntakeService (the only internet-facing component) exposes:

POST /api/public/booking-requests

• Disabled by default — returns 404 unless PublicBooking:Enabled is true.
• Requires an API key — Authorization: Bearer <key> or X-Api-Key: <key>, compared in constant time. Missing/wrong key → 401.
• Rate limited — fixed window, 5 requests/minute per client IP. Forwarded addresses are honored only from explicitly configured TrustedProxies.
• No database access. It validates the request and publishes a BookingRequestedEvent to Service Bus, then returns 202 Accepted ({ status, eventId }). It cannot read appointments or PHI.

Request body (PublicBookingRequest):

This is the beginning of the README. Read the rest at the original. Read the full README ↗