Hospital Management System RBAC — appointments, roles, and viva defense

Hospital Management Systems are a staple MERN final year topic in Indian colleges because the domain is familiar and the role matrix is rich. Patients book visits, doctors see schedules and write notes, reception manages the front desk, admins configure departments and billing. If your permission story is fuzzy, the viva collapses into “it is a CRUD app with a medical skin.” This post shows how to design and defend RBAC and appointment rules so the project reads as intentional architecture.

The reference shape matches Hospital Management System: JWT auth, four roles, slot booking, visit notes, simple invoices, audit trail. Compare the RBAC spine with Library Management System and the custom-rule lesson in hotel booking architecture.

Opening pitch (40 seconds)

“Our Hospital Management System is a MERN application with role-based access for admin, doctor, receptionist, and patient. Patients book appointments against doctor availability; reception can book on behalf of patients; doctors manage their schedule and clinical visit notes; admins manage departments, users, and billing configuration. Authorization is enforced with Express middleware, not only React menus. Appointment creation rejects double-booked slots. Visit notes and invoices reference the appointment lifecycle so records stay consistent.”

That pitch sets domain + security + one invariant. Stop and demo.

Four roles — keep names identical everywhere

Patient: register/login, browse doctors by department, book own appointments, view own visits and invoices, cancel when policy allows.
Receptionist: search patients, create/reschedule appointments, check-in flow, take payments / generate invoices as designed.
Doctor: view own schedule, update appointment status for own patients, write visit notes and prescriptions for assigned visits.
Admin: departments, doctor profiles, user roles, audit log, override paths documented in the matrix.

Write a permission matrix in Chapter 4 (roles × actions). Mismatched labels — “Staff” in UI vs “receptionist” in JWT — are an avoidable viva wound.

Middleware pattern

Same as other FinalYearKit MERN domains: auth verifies JWT → requireRole('doctor','admin') → controller. Ownership checks matter: a doctor JWT must not open another doctor’s private notes by guessing ObjectIds. Reception may see operational data; patients only patientId === req.user.id.

For a focused JWT refresher, use JWT authentication in MERN final year projects. For another three-role worked example, see Library Management System RBAC viva.

Why hospital is more than generic CRUD

Schema-driven admin forms can manage departments and doctor profiles. Appointments need custom handlers:

• ▸Validate doctor belongs to department
• ▸Ensure slot is in the future (or same-day policy you defined)
• ▸Reject overlapping appointments for the same doctor
• ▸Optionally enforce max daily appointments
• ▸On cancel/complete, free the slot according to status rules

Billing should compute totals on the server from service line items, not trust a client amount field. Clinical notes should be immutable or append-only after finalize if you implemented a lock — state the rule.

Saying “we used generic CRUD for catalog entities and custom controllers for appointments/billing” is a high-mark architecture sentence.

Appointment state machine

Example statuses: scheduled → checked_in → in_consultation → completed, plus cancelled / no_show.

Rules to memorize:

• ▸Patient cancels only before check-in (e.g., until T−2 hours)
• ▸Reception marks check-in
• ▸Doctor transitions to completed with a note required (if you enforce it)
• ▸Cancelled and completed are terminal
• ▸Invalid jumps return 400

Diagram this in Chapter 4. Chapter 6 tests: double book → 409; patient cancels completed visit → 400; patient reads another patient’s note → 403.

Slot model options

Option A: discrete slots (10:00, 10:20, …) as documents or embedded arrays on a daily schedule. Unique index on { doctorId, startTime } with status active.
Option B: interval booking with overlap queries like hotel stays.

Pick one and defend it. Discrete slots are easier to explain in undergraduate vivas and map cleanly to reception whiteboards.

Clinical data boundaries

Visit notes and prescriptions are sensitive. Minimum defenses:

• ▸Doctor (assigned) and admin can read; patient can read own summary if product requires; reception might see scheduling fields but not full clinical text — match your matrix
• ▸Audit log on note create/update
• ▸No public listing route for notes

Do not claim HIPAA/NABH compliance. Say “academic prototype with role isolation; production would need institutional security review and encryption at rest policies.”

Prescriptions as embedded arrays

A visit document can embed { medicine, dose, duration, instructions }[] with a reasonable max length. Pharmacy stock is out of scope unless you built it — mention Pharmacy Ecommerce only as a different retail domain, not as clinical dispensing.

Billing and invoices

Simple model: invoice references appointment/visit, embeds line items (consultation fee, lab charge), stores subtotal, tax, total computed server-side. Status: unpaid → paid. Reception records payment method (cash/UPI placeholder).

Viva hook: “Client cannot set total=0 via DevTools; server recalculates from line items and fee masters.” Same trust-boundary lesson as hotel rate snapshots and restaurant order totals.

Seed fee masters per department so demos are non-empty.

ER-style entities for the report

User (role), PatientProfile, DoctorProfile, Department, Appointment, VisitNote, Invoice, AuditLog.

Relationships:

• ▸DoctorProfile ↔ User (1:1)
• ▸DoctorProfile → Department
• ▸Appointment → Doctor, Patient, Department
• ▸VisitNote → Appointment
• ▸Invoice → Appointment/Visit

Mongo embed/reference choices: see MongoDB schema design for MERN final year. Appointments reference doctors/patients; line items embed inside invoices.

Sequence diagrams worth practicing

Patient self-book: login → list doctors → select slot → POST appointment → unique slot check → save → confirmation.
Reception book: search patient → select doctor/slot → POST with receptionist actor in audit.
Consultation: check-in → doctor opens appointment → write note → complete → optional invoice.

Narrate one sequence while the UI runs so the panel connects diagram to product.

Seed data for Indian college demos

Create:

• ▸Departments: General Medicine, Orthopedics, Pediatrics
• ▸Doctors with weekday slots IST morning/evening
• ▸Patients with Indian names/phone placeholders
• ▸A few scheduled appointments for “today” and “tomorrow”
• ▸One completed visit with note + invoice

Empty hospital dashboards kill demos. Idempotent seed scripts save viva mornings.

Frontend UX by role

Patient app views: find doctors, my appointments, my invoices.
Reception desk: appointment calendar, quick book, payment.
Doctor desk: today’s queue, note editor.
Admin: users, departments, audit, fee config.

Hide navigation by role; still enforce API checks. Use consistent status badges (scheduled/completed) matching the state machine vocabulary.

Deployment and privacy notes

MongoDB Atlas + hosted API is common. Remind the panel:

• ▸Secrets in env
• ▸HTTPS in production
• ▸Seed passwords only for demo tenants
• ▸No real patient data from a live clinic without permission — use fictional seed

If asked about telemedicine video: out of scope unless implemented; future work slide.

Viva Q&A bank

Q: How do you prevent double booking?
A: Unique constraint / conditional create on doctor+slot; conflicts return 409. Show with two quick bookings in Postman if needed.

Q: Can a patient book for someone else?
A: Self-book only for patient role; reception books on behalf of patients after identity check at desk — modeled as receptionist actor.

Q: How is this different from a hotel booking system?
A: Similar slot/overlap ideas, but hospital adds clinical notes, department taxonomy, and stricter read boundaries on medical fields. Hotel focuses on room occupancy and stay pricing — see hotel booking architecture.

Q: Why four roles not three?
A: Reception operational workflow differs from clinical doctor workflow; collapsing them muddies permissions and UI. Admin remains configuration/audit.

Q: Emergency walk-ins?
A: Reception creates same-day appointment with next free slot or an walk_in flag if implemented; otherwise documented limitation.

Q: Lab reports / imaging?
A: Out of scope for base kit; future module. Do not invent screens mid-viva.

Q: Password storage and JWT?
A: bcrypt hashes; JWT with role claims; middleware order auth then requireRole.

Testing table for Chapter 6

| Case | Expected | | --- | --- | | Patient books free slot | 201, status scheduled | | Second book same slot | 409 | | Patient GET other patient notes | 403 | | Doctor completes without note (if enforced) | 400 | | Cancel after complete | 400 | | Invoice total tampered by client | server total wins | | Admin views audit after reception book | entry present |

Run these the night before.

Presentation tips

Slide 2: role matrix.
Slide 3: appointment state machine.
Slide 4: architecture (React → Express → Mongo).
Live: patient book → reception check-in → doctor note → invoice.

Four-minute path. Resist touring every admin form.

Differentiation when another team also built “hospital”

Add one sharp rule: department-wise fees, doctor leave calendar blocking slots, SMS placeholder log, or analytics (appointments per department chart). Depth on one rule beats cosmetic UI twins. Customize college name and department list so it does not look like an untouched template — see also customize kit with college name if you use a kit baseline.

Pre-viva checklist

• ▸[ ] Four role logins work
• ▸[ ] Permission matrix printed
• ▸[ ] Double-book demo ready
• ▸[ ] Note + invoice path works
• ▸[ ] Patient 403 demo ready
• ▸[ ] Seed “today” appointments exist
• ▸[ ] ER diagram readable on projector
• ▸[ ] Atlas IP / env secrets verified at venue

Department and doctor profile design

Departments are not just dropdown labels. They drive browse UX (“show Orthopedics doctors”), fee defaults, and report analytics. Doctor profiles should include qualification text, consultation duration, weekday availability windows, and active flag. Deactivating a doctor must block new bookings while preserving historical appointments for audit.

Receptionists should search patients by phone/name with pagination — hospitals in demos that list every patient in one unpaginated table look naive when the seed grows past a pageful.

Recurring availability

Model weekly templates (Mon 10:00–13:00) that generate concrete slots for the next N days. Regenerating slots is a good implementation talking point: cron vs on-demand generation when the patient opens the booking calendar. On-demand is simpler for final year; say so.

Notification stubs as depth

SMS/email gateways are flaky in vivas. A credible pattern: write notification rows to a NotificationLog collection (“Appointment scheduled”, “Invoice paid”) and show them in admin UI. Claim “provider integration is future work” while still demonstrating the domain event. Panels accept this when you are honest. Claiming Twilio delivery without credentials on campus Wi-Fi is how demos die.

Analytics that fit undergraduate scope

One aggregation chart is enough:

• ▸Appointments per department last 30 days
• ▸Cancellation rate
• ▸Revenue sum from paid invoices by week

Use MongoDB aggregation + a simple chart in React. Empty charts are worse than no chart — seed completed data. This satisfies many “reports module” rubric lines without building a full BI tool.

What “medical” does not require

You do not need ICD-10 coding, HL7 FHIR, drug-interaction AI, or DICOM viewers to pass. Those buzzwords without implementation hurt credibility. Prefer complete appointment → note → invoice loops. If a panelist pushes FHIR, answer: “Interoperability standards are future work; our academic scope is RBAC operations for a single clinic deployment.”

Group viva role split

Suggested ownership:

• ▸Member A: RBAC + JWT middleware
• ▸Member B: appointment slot engine
• ▸Member C: UI role dashboards + billing screens

Cross-train enough that absence of one member does not zero the project. External examiners sometimes pick the “quiet” teammate for the hardest question — quiet teammates still need the matrix memorized.

Mapping to SRS shall-statements

Example requirements language:

1. ▸The system shall allow patients to book only available doctor slots.
2. ▸The system shall prevent two active appointments for the same doctor and start time.
3. ▸The system shall restrict clinical note access per the role matrix.
4. ▸The system shall calculate invoice totals on the server from fee masters and line items.
5. ▸The system shall record actor, action, and entity for sensitive mutations in an audit log.

Trace each shall to a controller test row in Chapter 6. Traceability impresses structured examiners more than extra screenshots.

Demo script (five minutes)

1. ▸Login as patient → book Dr. Mehta tomorrow 11:00.
2. ▸Login as receptionist → show the appointment on the desk calendar → check-in.
3. ▸Login as doctor → open visit → add note + prescription line → complete.
4. ▸Reception → generate/pay invoice → show server total.
5. ▸Login as patient → attempt to open another patient’s note API in Postman → 403.
6. ▸Admin → show audit entries for the booking and note write.

This script proves RBAC, slot booking, clinical workflow, billing integrity, and audit without wandering through every CRUD screen.

Naming and branding before PDF freeze

Replace placeholder clinic names with your college hospital/dispensary theme if appropriate, keep fictional patient data, and align screenshots with the ER labels. Small consistency work prevents “template smell” comments that overshadow solid middleware. The RBAC story is the mark engine; naming polish helps first impressions on the projector.

Related kits and posts

• ▸Hospital Management System — appointments, roles, notes, billing, audit-oriented MERN kit.
• ▸Library Management System — cleaner three-role RBAC sibling for contrast in viva.
• ▸Architecture companions: mern-library-rbac-viva, hotel-booking-system-architecture, jwt-auth-mern-final-year.

Takeaway: Defend hospital RBAC as a four-role matrix with server-side slot uniqueness, clinical read boundaries, and server-priced invoices — the combination Indian B.Tech panels recognize as real system design, not medical-themed CRUD.