3 - NextGenHealth: Refining the Domain Model — From Audit Confusion to Clear Access Control

Learning from the First Iteration

In my previous post, I shared the initial domain model for Patient Management, where I included an entity called AuditLogEntry to represent changes and access events.

While functional, I quickly realized a critical flaw:

❌ I was mixing concerns.

The AuditLogEntry was being used to track both patient data changes and authentication events — two very different contexts in a healthcare system.

This violated a core principle of Clean Architecture: separation of concerns.

So I made a correction — one that reflects real-world healthcare systems:

✅ Different types of audit trails belong to different modules.

Fixing the Model: From AuditLogEntry to AuditLogTrail

In the Patient Management module, I replaced the generic AuditLogEntry with a more precise concept:

AuditLogTrail — a dedicated record of data changes to patient profiles, including:

• Who updated the address

• When the phone number was changed

• What fields were modified

This entity now:

• Lives within the Patient Management domain

• Tracks only patient data lifecycle events

• Supports compliance (LGPD/HIPAA) with clear traceability

• Is not accessible to patients — only to staff and administrators

The key insight:

✅ Not all logs are the same.

Patient data audit ≠ authentication audit.

Fixed Domain Model for Patient Management

Introducing the Authentication Domain Model

With the patient model refined, I moved to Authentication and Access Control — the gatekeeper of the entire system.

Authentication and Access Control Domain Model

So I introduced a new entity:

AuditLogAccess— a dedicated log for authentication events, such as:

• Login success/failure

• Account lockouts

• Session creation and timeout

• Suspicious activity detection

This separation ensures:

• ✅ Security by design: authentication events are isolated and highly protected

• ✅ Compliance: distinct audit trails for access vs. data

• ✅ Scalability: future features like 2FA or SSO can extend this model safely

Why This Matters in Healthcare

In regulated environments like healthcare, auditability isn’t optional — it’s mandatory.

But indiscriminate logging creates noise, not insight.

By modeling:

• AuditLogTrail for patient data

• AuditLogAccess for user access

…I ensure:

🔐 Clear responsibility — each module owns its audit logic

📊 Actionable insights — logs are relevant and searchable

🛡️ Security — sensitive access logs are isolated from clinical data

Stay in the Loop

Want to follow the journey?

🔗 Connect on LinkedIn — I post daily updates on the development process, UML decisions, and architecture insights.

📧 Need expert help on your healthcare project?

Let’s talk: contact@fmbyteshiftsoftware.com

GitHub NextGenHealth Project
Code. Design. Document. Refine.

Next article: Modeling the Appointment Scheduling Domain — Where Real-World Workflows Meet Clean Architecture

About the Author: Fernando Antunes de Magalhães is a Software Architect with over 15 years of experience, including 11 years in 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). He leads FM ByteShift Software, building next-generation systems with precision, compliance, and real-world impact.