ClinicFlow is a clinic management system built on .NET 10 that puts domain complexity first. Modeled with Domain-Driven Design (DDD) and organized around Clean Architecture principles, it separates business logic from infrastructure concerns while using the CQRS pattern — powered by MediatR — to keep every read and write operation explicit, validated, and testable. From appointment lifecycle management to patient penalty tracking and dynamic medical records, all core clinical workflows live in a pure, dependency-free domain layer backed by PostgreSQL 17.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/0Crazy-0/ClinicFlow/llms.txt
Use this file to discover all available pages before exploring further.
ClinicFlow is under active development. The domain model, application services, and infrastructure are evolving. There is currently no HTTP API layer — integration happens directly at the Application layer through MediatR commands and queries.
What ClinicFlow manages
ClinicFlow covers the operational core of a clinic:- Appointment lifecycle — Schedule, reschedule (once), check-in, start, complete, mark as no-show, cancel (standard or late), and automatic reassignment when a doctor is suspended.
- Doctor management — Register physicians with medical license numbers, specialties, consultation rooms, and biographies. Suspend and reactivate with downstream appointment handling.
- Patient management — Primary profile and family-member registration, scheduling clearance checks, and blocked-patient enforcement.
- Penalty system — Track late cancellations and no-shows with typed penalties, time-based blocking, and reactivation events.
- Medical specialties — Associate doctors with named specialties; restrict appointment types to specific specialties.
- Medical records — Structured clinical encounter records with dynamic clinical detail forms backed by JSON schema templates.
- Scheduling — Weekly schedule setup per doctor, enforcing slot conflicts and availability rules.
- User accounts — Registration, login, phone verification, password reset, and role-based access for all four user roles.
User roles
Every operation in ClinicFlow is scoped to one of four roles defined inUserRole:
| Role | Description |
|---|---|
| Patient | Books and manages their own appointments; subject to penalty rules |
| Doctor | Starts and completes appointments; marks no-shows; manages their own schedule |
| Receptionist | Front-desk staff who check in patients, schedule on behalf of others, and process cancellations |
| Admin | Full system access — manages users, doctors, specialties, appointment types, and penalties |
Tech stack
| Technology | Version | Role |
|---|---|---|
| .NET | 10.0 | Target framework for all projects |
| MediatR | 14.1.0 | CQRS mediator — dispatches commands and queries through the pipeline |
| FluentValidation | 12.1.1 | Input validation registered as a MediatR pipeline behavior |
| Entity Framework Core | 10.0.8 | ORM for persistence and EF Core migrations |
| Npgsql.EF Core PostgreSQL | 10.0.2 | EF Core provider for PostgreSQL |
| PostgreSQL | 17 (Alpine) | Primary relational database |
| Bogus | 35.6.5 | Fake-data seeding for local development |
Solution structure
The solution (ClinicFlow.sln) contains three production projects and three matching test projects:
Quickstart
Clone the repo, spin up PostgreSQL with Docker, apply EF Core migrations, and run the test suite in a few commands.
Architecture
Understand the three-layer Clean Architecture, project dependencies, and how CQRS pipeline behaviors fit together.
Appointments
Deep-dive into the full appointment lifecycle — scheduling, rescheduling, check-in, no-show, cancellation, and reassignment.
Domain Model
Explore the core entities, value objects, domain events, and domain services that encode ClinicFlow’s business rules.