Back to Systems

Medical Case Tracker

A clinic operations platform for patient records, appointment workflows, medical cases, images, role-based access, audit events, and patient portal account linking.

June 15, 2026
Spring BootAngularRBACHealthcare WorkflowsAudit Trails
GitHub

The Problem

Clinics need to coordinate doctors, front desk staff, administrators, and patients without exposing private records to the wrong role or losing the history behind case updates.

The Solution

Medical Case Tracker models clinic work as role-aware workflows for patients, appointments, cases, images, audit events, verified patient portal linking, and administrative backup controls.

What It Solves

  • Separates admin, doctor, front desk, and patient permissions with JWT and RBAC.
  • Gives patients a verified portal path without exposing records by email alone.
  • Adds audit events and backups so operational changes can be reviewed and recovered.

Architecture

  • Spring Boot 3 backend with Java 17, Spring Security, JWT, JPA, Flyway, and layered services.
  • Angular 19 frontend with route guards, role-specific dashboards, localization, and patient portal flows.
  • CI, tests, migrations, and environment templates support repeatable local and deployment workflows.

Trade-Offs

  • Role-specific screens reduce accidental access but require more frontend route and guard coverage.
  • Verified patient linking is stricter than simple email lookup but protects record ownership.
  • Backup and restore controls add admin responsibility but improve operational recovery.

The Problem In One Sentence

Clinic software is risky when it treats every user as a generic account. Doctors, front desk staff, administrators, and patients all touch the same operational process, but they should not see or mutate the same records.

Medical Case Tracker is built around that boundary problem: how to move patient care work forward while keeping identity, access, history, and recovery explicit.

Workflow Boundaries

The application separates clinic responsibilities into different surfaces:

| Role | Product responsibility | | --- | --- | | Administrator | Manage users, backups, audit visibility, and clinic-level controls | | Doctor | Review assigned patients, appointments, medical cases, and case images | | Front desk | Coordinate appointment and patient intake workflows | | Patient | Access a verified portal view of their own linked record |

That separation is the core product decision. The app is not only a CRUD interface for patients and cases; it is a workflow system where each role has a constrained view of the clinic.

Patient Portal Linking

Patient access is intentionally stricter than a simple email match. A patient account must be linked to a patient record through a verification flow before the portal exposes medical information.

That protects against a common privacy failure: assuming that an account email alone is enough to prove ownership of a clinic record.

Architecture Decision

The backend is a Spring Boot application with layered services, DTO boundaries, Flyway migrations, JWT authentication, and role-based authorization. The frontend is an Angular application with route guards, role-specific dashboards, shared services, and English/French localization.

The stack is intentionally conventional. Healthcare workflow software benefits from boring, inspectable architecture: clear controllers, explicit service rules, migrations that explain schema changes, and tests that protect permission behavior.

Operational Recovery

The administrative backup flow is included because clinic systems are operational systems. Data changes need recovery paths, not only validation at the time of entry.

The backup feature is not framed as a replacement for production database operations. It demonstrates the product concern: admins need a controlled recovery workflow, and engineering should treat that as part of the application boundary.

Security And Privacy Model

The privacy model is based on explicit roles and constrained portal access:

  • JWT authentication identifies the user session.
  • RBAC controls which workflows each role can access.
  • Patient portal linking verifies ownership before exposing patient data.
  • Audit events preserve a reviewable history of important actions.
  • Environment templates keep secrets out of source control.

The important design point is that privacy is not a paragraph in the README. It appears in route guards, backend authorization checks, service rules, tests, and operational documentation.

What This Case Study Demonstrates

Medical Case Tracker demonstrates applied product engineering in a regulated-style domain:

  • Modeling multi-role operational workflows.
  • Designing secure patient access around verified record ownership.
  • Combining Spring Boot and Angular in a full-stack product.
  • Using migrations, tests, CI, audit events, and backups to support operational reliability.
  • Treating privacy and recovery as first-class product requirements.

The project is valuable in the portfolio because it shows a different kind of complexity than COD, logistics, or algorithmic reconciliation. It is about sensitive data, role boundaries, and the discipline needed when the product is close to real people and real records.