Maternity Care Platform: Multi-Tenant SaaS Architecture

Maternity Care: A Strategic Architectural Proposal

Establishing a Scalable, Compliant, and Maintainable Foundation for Growth

Architecture Review Board (ARB) Governance & Approval

Our Platform is Evolving. Our Architecture Must Evolve With It.

FROM: A single-hospital, tightly coupled system

TO: A Multi-tenant SaaS Platform (Tenants + Subscriptions + Integrations)

Key Drivers: Multi-Tenancy (Multiple hospitals) • National Integrations (NHN/DHG) • Future Onboarding • Long-Term Maintainability

A Single Application Cannot Serve Conflicting Responsibilities

Tenant-specific branching → Unmaintainable flows

NHN schema leakage → Polluted data model

Integration-driven changes → Unstable core logic

Release coupling → Delayed production releases

Our Architecture is Guided by a First Principle: One Job, One Owner

Each application exists to answer ONE clear architectural question and nothing more.

1. SaaS / Tenancy

Who is using the system and what are they entitled to?

2. Domain Logic

What is prenatal care as a stable medical domain?

3. Integration

How do we safely connect to external systems?

The Solution: We Will Isolate Responsibilities into Purpose-Built Layers

Four distinct, responsibility-driven layers allowing independent evolution.

Layer 1: The Maternity Care Application

The Multi-Tenant SaaS Entry Point

OWNS:

• Tenant Configuration & Subscriptions • Access Groups & Role Management • UI Composition & Orchestration

EXPLICITLY DOES NOT OWN:

• Clinical logic or data models • Integration payload schemas

Tenants and subscription logic must never pollute the integrity of clinical workflows.

Layer 2: The Prenatal Care Application

The Canonical Domain System of Record

Single Responsibility:

Answers the question: What is prenatal care? It owns the canonical prenatal data model, all case lifecycles, and clinical workflows.

Key Attribute: It is explicitly tenant-neutral and designed for stability and reuse.

The Critical Rule: Clinical Cases MUST Live in the Canonical Domain

All prenatal case types reside in Prenatal Care.

The Maternity Care application never owns healthcare cases.

Rationale: If cases live in the SaaS layer, clinical logic becomes tenant-specific by design. This destroys the medical model integrity.

Layer 3: Integration Boundaries

Acting as Protective Anti-Corruption Layers

Answers the question: How do we safely talk to external systems?

Owns API contracts • Payload mapping • Versioning compliance

True Multi-Tenancy Without Corrupting Core Logic

Architecture Delivers Stability, Scalability, & Speed

Stability

Isolate regulatory change, reducing regression risk on the core platform.

Scalability

Onboard new tenants and integrations without core refactoring.

Speed

Clear ownership boundaries enable parallel development.

Compliance

Improved auditability by isolating national compliance logic.

The Cost of Inaction: Why This Decision is Necessary NOW

Correcting Ownership NOW

Risk: Low. Controlled, technical task.

Correcting Ownership LATER

Risk: High. In-flight cases, data loss, massive compliance overhead.

Answering Key Governance Questions

Are we over-engineering by introducing multiple apps?

No. These are responsibility boundaries preventing costly future refactoring.

Why not handle multi-tenancy with branching logic?

Tenant-branching is unmaintainable and pollutes the medical logic.

Does this align with Pega best practices?

Perfectly. Aligns with Center-Out Architecture and canonical data modeling.

Clear Ownership and Governance

Maternity Care (SaaS Layer)

Delivery Team

Prenatal Care (Domain)

Delivery Team / Domain Owners

DHG (NHN Integration)

Integration / Compliance Team

Platform (PegaHC, Helse)

Platform Team

Decision Required: Approve This Mandatory Foundation

We request formal approval of the proposed application architecture as the mandatory foundation for the Maternity Care platform.

Protecting prenatal care logic from tenant noise.

Protecting tenants from integration churn.

Protecting the platform from regulatory instability.

Without this structure, the system will work — until it doesn’t. With this structure, the system can evolve safely.