A modular-monolith hospital management web application. It supports patient, doctor, and administrator workflows while keeping the database as the source of truth.
- Backend: ASP.NET Core 8, layered into API, Application, Domain, and Infrastructure projects.
- Frontend: React with Vite.
- Database: SQL Server, managed through versioned SQL scripts and represented by EF Core entity types. EF Core migrations are intentionally not used.
src/ contains backend projects; client/ contains the React frontend; database/ contains versioned SQL schema, seed, and helper scripts; tests/ contains unit, integration, and API test projects; and docs/ contains development documentation.
- .NET SDK 8.0.423 or compatible 8.0 SDK
- Node.js 22 and npm
- SQL Server
dotnet restore HospitalManagementSystem.sln
dotnet build HospitalManagementSystem.sln --no-restore
dotnet test HospitalManagementSystem.sln --no-build
Set-Location client/hospital-web
npm install
npm run devRun the API separately with dotnet run --project src/Hospital.Api. The health check is available at /health.
Copy src/Hospital.Api/appsettings.Local.example.json to src/Hospital.Api/appsettings.Local.json and provide local values, including a unique JWT signing key of at least 32 characters. The local file is ignored by Git. Production secrets must be supplied through environment-specific secure configuration, never committed. Outside Development, configure the exact frontend URLs in Cors:AllowedOrigins; the API will not start with an implicit CORS allowlist.
The API exposes POST /api/auth/register, POST /api/auth/login, and authenticated GET /api/auth/me. Registration creates an active Patient account and returns a short-lived JWT. Send it as Authorization: Bearer <token>; logout is performed client-side by deleting that token. The API returns 401 for absent, invalid, expired, or bad-credential requests and 403 for an authenticated user without the required role.
The fictional development seed accounts use DevelopmentOnly!123; never use this password or the seed identities outside a local development database.
Authenticated users can read their account profile through GET /api/profile/me. Patients create or update their own profile with PUT /api/profile/me; this generates a stable medical-record number for a new patient profile. Administrators can search patients, doctors, and staff through /api/admin/patients, /api/admin/doctors, and /api/admin/staff, and activate or deactivate another account with PATCH /api/admin/accounts/{userId}/status.
Use GET /api/departments, GET /api/departments/{id}, GET /api/doctors, GET /api/doctors/{id}, or GET /api/departments/{id}/doctors to select an active department and doctor. Only administrators may create or update departments. Inactive departments and doctors are never exposed for selection.
The database is initialized from repository SQL scripts, not EF Core migrations. See database/README.md for the SQL Server command and safety notes.
See docs/DEVELOPMENT.md. Work is created from main in short-lived feature/, fix/, or docs/ branches and merged through reviewed pull requests.
The following guides explain the system, its configuration, and operational checks:
The GitHub Actions workflow validates database initialization, formatting, builds, tests, and published artifacts on every push to main.