5 - NextGenHealth: From Patient-Centric to User-Centric — How I Scaled Our Identity Model with Clean Architecture

The Problem with Patient Management

In most healthcare systems, Patient Management is treated as the central domain.

But here’s the truth: patients are just one of many authenticated roles.

Doctors schedule. Nurses update records. Administrators manage access.

Yet, we keep building systems where patient is the only first-class citizen.

At NextGenHealth, I realized this model was broken from the start.

We were duplicating logic:

• Authentication for patients

• Separate auth for staff

• Inconsistent audit trails

• Role checks scattered across code

It wasn’t scalable. It wasn’t secure. And it certainly wasn’t clean.

So I made a bold decision:

🔁 Replace Patient Management with User Management — as the core identity domain.

The New Foundation: One User to Rule Them All

I rebuilt the domain model around a single principle:

✅ All actors in the system are Users.

Their behavior changes based on role, not structure.

The new User Management domain now includes:

✅ 1. User (Base Entity)

• UUID, email, password hash

• First/last name, phone, date of birth

• Status (Active, Locked, Inactive)

• Role (Patient, Nurse, Doctor, Administrator)

This is the single source of truth for identity.

✅ 2. Specialized Profiles (Only When Needed)

Not all users need extra data. So we use extension tables only where justified:

• PatientProfile: emergency contact, insurance info, medical history

• DoctorProfile: specialty, license number, availability schedule

• NurseProfile: certification type, department, shift preferences

➡️ But no AdministratorProfile.

Why? Because an Administrator is just a User with elevated permissions — no additional clinical or operational data required.

This keeps the model lean, secure, and focused.

✅ 3. Unified Authentication

One login flow. One token. One session.

No more "patient portal" vs "staff portal".

Just: You are a User. Here’s what you can do.

✅ 4. Centralized Audit Trail

Every action — registration, profile update, login — goes into AuditLogTrail, tied to the User.

No exceptions. No gaps.

Why This Matters

BEFORE

Scattered role logic

Duplicate credential tables

Inconsistent data models

Risk of privilege escalation

AFTER

RBAC enforced at the domain level

One UserCredentials table

Clean inheritance: User → Patient, User → Doctor

Roles defined at creation, audited on change

And critically:

➡️ Zero code duplication.
➡️ One path for authentication.
➡️ Full auditability by design.

Real-World Impact

This model enables workflows that were impossible before:

• An administrator registers a new patient and assigns them to a doctor — all within one transaction.

• An administrator updates a doctor’s availability without touching their clinical data

• A patient self-registers while the system enforces HIPAA-compliant logging

And yes — it scales:

• Adding a new role like Receptionist? Just define the role and its profile.

• Removing unnecessary complexity? Done. No bloated tables for roles that don’t need them.

Stay in the Loop

Want to follow the journey?

🔗 Connect on LinkedIn — I post daily updates on architecture decisions, UML modeling, and healthcare compliance.

📧 Need expert help on your healthcare project?

Let’s talk: contact@fmbyteshiftsoftware.com

Check the full project changelog:
👉 Change Log

📁 GitHub NextGenHealth Project

Code. Design. Document. Refine.

About the Author: Fernando Antunes de Magalhães is a Software Architect with over 15 years of experience, including 11 years focused on healthcare technology. He holds a Post-Graduate degree in Software Engineering and is the author of “Software Engineering — Essential Principles for Beginners and Professionals” (link). As CEO of FM ByteShift Software, he builds next-generation systems with precision, compliance, and real-world impact.

User Management Use Case Diagram

User Management Domain Model Diagram