How adt-kmr/dbms-project-patient-management-system works
1. System shape
- This repo is a multi-service Patient Management System centered on a PostgreSQL database.
- The database is the main source of truth; the rest of the code provides access layers and client experiences around it.
- There are four major application surfaces: Node/TypeScript backend APIs, a Node/TypeScript auth service, a Django admin module, and a Flutter client app.
2. Database core and business rules
- The DB design lives in backend/prisma/schema.prisma, backend/prisma/migrations, and especially backend/prisma/dbms_implementation.sql.
- The schema models the main hospital entities described in the README: employees, patients, prescribe assignments, reports, and patient history.
- Critical logic is pushed into PostgreSQL via stored procedures, triggers, cursors, RLS policies, and hash-chain integrity checks.
- This means authorization and data integrity are enforced both in the app layer and inside the database.
3. Security boundary in the database
- A key architectural feature is Row-Level Security (RLS), implemented in backend/prisma/rls_setup.sql.
- RLS is the final gate for who can see which patient/report rows, which is important for the “doctor only sees assigned patients” rule.
- Report integrity is protected by cryptographic hash chaining, so report history is tamper-evident even if the application layer is bypassed.
4. Backend API service
- The backend/ folder is a separate Node.js service written in TypeScript with compiled JavaScript output alongside it.
- Its middleware set shows the service responsibilities clearly:
- verifyToken handles authenticated access.
- JsonErrorChecker validates request payloads.
- logger provides request/runtime logging.
- This service is the main operational API layer for patient/report workflows and likely mediates most reads/writes to PostgreSQL through Prisma.
5. Auth service
- The auth/ folder is its own Node/TypeScript service with a separate Prisma schema and generated client.
- Architecturally, it is the identity boundary: login, credential validation, and token issuance happen here.
- The backend then consumes those tokens rather than handling password logic directly, which separates authentication from business operations.
6. Administrative web module
- The admin/ directory is a distinct Django project (asgi.py, wsgi.py, settings.py, urls.py) with a fam app and migrations.
- This is the admin-facing management plane, likely used for employee/staff administration and privileged operations.
- It is separate from the Node services, so the repo contains two backend stacks: Django for admin and Node for app-facing APIs/auth.
7. Flutter client application
- pgi_app/ is a full Flutter application targeting Android, iOS, web, Linux, macOS, and Windows.
- The screen structure shows the app experience is organized around:
- login and profile
- dashboard/home
- patients and patient detail
- records and upload
- notifications, settings, and visit logging
- This client is the primary user-facing layer for doctors or staff interacting with patient data.
8. Document capture and OCR pipeline
- The Flutter app includes a dedicated OCR path: camera_capture_page.dart, ocr_page.dart, services/ocr_service.dart, and widgets/web_ocr_demo.dart.
- The build artifacts show integration with Google ML Kit text recognition, plus camera/image/file/permission plugins.
- Architecturally, this is an on-device acquisition and extraction pipeline: capture image or upload document, run OCR locally, then feed extracted text into the app’s record/report flow.
9. Patient/report data flow
- The main lifecycle is: authenticate user → load assigned patients → capture/upload report data → persist report → archive history / compute hashes.
- Doctor-to-patient assignment is represented in the DB via the prescribe relationship.
- Updates and deletes are not just overwritten; they are preserved in a history/audit path, which supports medical traceability.
10. Cross-layer authorization model
- Authorization is layered:
- the auth service proves identity,
- the backend middleware checks token validity,
- the database RLS restricts row visibility,
- and the procedure/trigger logic preserves integrity.
- This is an important diagram boundary: security is not centralized in only one service.
11. Runtime and deployment boundaries
- The repo includes Dockerfiles and a top-level docker-compose.yml, so the services are meant to run as containerized components.
- The practical deployment split is:
- PostgreSQL database
- auth service
- backend API service
- Django admin service
- Flutter client builds for multiple platforms
- That separation matters for the architecture diagram because each service has its own runtime and release path.
12. Tooling and generated artifacts
- The Node services use Prisma heavily; generated clients are committed under auth/generated/prisma and backend schema/migrations live under backend/prisma.
- The Flutter app has generated build output and platform directories, but those are build artifacts rather than architectural subsystems.
- The repo also contains documentation files that describe the DBMS features and novelty, indicating the database design is a major deliverable, not just a supporting component.
Main entry points: backend/main.ts Backend API · auth/main.ts Auth service · main.dart Flutter app · docker-compose.yml Compose stack
Components 20
Database core
PostgreSQL schema, migrations, integrity logic, and row-level security.
- PostgreSQL · Primary patient-management datastore and enforcement boundary.
- DBMS logic · Stored procedures, triggers, cursors, and hash-chain integrity checks.
backend/prisma/dbms_implementation.sql - Schema model · Prisma model for employees, patients, prescribe assignments, reports, and history.
backend/prisma/schema.prisma - RLS policy · Row-level security rules that gate patient and report visibility.
backend/prisma/rls_setup.sql
Node services
TypeScript services for business APIs and authentication.
- Backend API · Main operational API for patient and report workflows.
backend/main.ts - Token guard · Authenticated access check for backend requests.
backend/middlewares/verifyToken.js - Payload check · Request-body validation and JSON error handling.
backend/middlewares/JsonErrorChecker.ts - Logger · Request/runtime logging for the backend service.
backend/logger.ts - Auth service · Identity boundary for login, credential validation, and token issuance.
auth/main.ts - Auth schema · Separate Prisma schema for auth-related persistence.
auth/prisma/schema.prisma - Prisma client · Committed generated Prisma client for the auth service.
auth/generated/prisma/client.js
Admin stack
Django management plane for privileged administration.
- Django admin · Privileged admin plane for staff management and management workflows.
admin/admin/settings.py - FAM app · Admin module with models, views, and migrations.
admin/fam/models.py
Flutter client
Cross-platform app for staff and doctors, including OCR capture.
- Flutter app · Primary user-facing app for staff and doctors.
pgi_app/lib/main.dart - Screens · Login, dashboard, patients, records, profile, notifications, and settings flow.
pgi_app/lib/dashboard.dart - OCR pipeline · Camera/upload capture plus ML Kit text recognition and OCR extraction.
pgi_app/lib/services/ocr_service.dart
Deployment
Containerized runtime boundaries and orchestration.
- Compose stack · Container composition for the repo’s runtime services.
docker-compose.yml - Backend image · Docker build for the TypeScript backend service.
backend/Dockerfile - Auth image · Docker build for the auth service.
auth/Dockerfile - Admin image · Docker build for the Django admin service.
admin/Dockerfile
Connections 24
- Schema model → PostgreSQL: maps data · Defines persistent hospital entities in PostgreSQL.
- DBMS logic → PostgreSQL: executes in · Stored procedures and triggers run inside the database.
- RLS policy → PostgreSQL: secures rows · RLS is enforced directly by PostgreSQL.
- DBMS logic → RLS policy: reinforces · Integrity logic complements row-level security.
- Backend API → Token guard: uses · Backend gates requests through token verification.
- Backend API → Payload check: uses · Backend validates and normalizes request payloads.
- Backend API → Logger: uses · Backend emits operational logs.
- Backend API → PostgreSQL: reads/writes · Primary business API talks to the database.
- Backend API → Schema model: implements · Backend data access is modeled through Prisma.
- Auth service → Auth schema: uses · Auth service persists identity data via Prisma.
- Auth service → Prisma client: runs with · Auth service uses committed generated client artifacts.
- Auth service → PostgreSQL: auth data · Auth service depends on the shared database backend.
- Django admin → FAM app: contains · Django project hosts the admin app.
- FAM app → PostgreSQL: admin data · Admin models and migrations persist into PostgreSQL.
- Flutter app → Screens: organizes · Client UI is structured as a screen flow.
- Flutter app → OCR pipeline: includes · Client includes on-device OCR and capture.
- Flutter app → Backend API: calls · Client consumes the main business API.
- Flutter app → Auth service: authenticates via · Client signs in through the dedicated auth service.
- Backend API → Auth service: trusts tokens · Backend relies on auth-issued tokens for identity.
- Django admin → Backend API: privileged integration · Admin plane can coordinate with the backend service.
- Compose stack → Backend image: builds · Compose includes the backend container.
- Compose stack → Auth image: builds · Compose includes the auth container.
- Compose stack → Admin image: builds · Compose includes the Django admin container.
- Compose stack → PostgreSQL: runs · Compose orchestrates the shared database.