Home / Platform / Architecture

Boundaries a code review can't be talked out of

One deployment, one codebase, one database per hospital — divided internally into fully isolated domains, each owning its own data. This is the part that keeps the promises true in year five.

Book your hospital simulation Explore the platform

The shape

A modular monolith, extractable by construction

Microservices are a deployment option we keep available, not a starting position. Every boundary rule exists so any module could later be lifted into its own service without changing a line anywhere else.

Surfaces webmobilekiosksmart TVvoicewearablespartner API— thin, replaceable, never a home for logic

Tasks & contracts task registryservice contractsevent catalogpermissionsAI toolsflags

Modules patientemrordersnursingicuotbedsemergencylabradiologyblood bankpharmacyinventorybillinginsurancefinancehrqualityportaltelemedicineworkflowaisearchanalyticsinteropaudit— one schema each; no module reads another's tables, ever

Event backbone durable outboxdispatcherpermanent retentionwebhooksstreaming

Kernel authRBAC + ABACtenancyconfig & flagscryptotelemetryHTTP conventions— zero business rules, by gate

Enforcement

Six gates, run on every commit

Rules that live in documents decay. These live in the build pipeline, and a change that violates one does not merge.

Boundary gate

A module may import itself, the contracts package, and the kernel. Anything else fails the build.

SQL ownership gate

A repository referencing a table outside its own schema fails the build. No allow-list, no exceptions.

Layering gate

Domain logic may not import infrastructure, presentation, or any I/O library. Purity is checked, not requested.

Kernel purity gate

The kernel may not depend on any module or contract. A "utility" naming a domain noun belongs in that domain.

Contract discipline gate

Contracts carry no runtime dependencies; breaking changes to types or event schemas are caught on every pull request.

Registry completeness gate

A module ships with its tasks, permissions, events, AI tools, flags and seven documents registered — or it does not ship.

Alongside these run the ordinary ones — strict types, both-ways migrations, coverage floors, contract tests, an authorization matrix, accessibility scans, performance budgets, dependency and secret scanning. The ladder only ever grows. Ask any vendor to show you theirs.

Why it matters to you

What these rules buy a hospital

Architecture is only worth discussing if it changes what you experience. Here is the translation.

Isolation

One module's problem stays one module's problem

Because no module can read another's tables, a defect or a bad deployment in billing cannot corrupt clinical data. Blast radius is a design property, not a hope.

one schema per module · enforced by CI, not convention

Longevity

Capability is added, not migrated to

New modules install against published contracts. That is why we can claim you will not face another hospital-wide replacement — the architecture is what makes it true.

module manifest · versioned contracts · additive by default

Portability

Your data stays yours

One physical database per hospital, self-hosted if you prefer, with an open FHIR R4 API and a permanent event history that belongs to you.

export · FHIR R4 · event history · no lock-in by design

Next step

See your hospital running on Ospia

An executive demonstration takes forty-five minutes. We seed a hospital with synthetic data shaped like yours, put the digital workforce on duty, and answer the hard questions with the architecture open.

Book your hospital simulation Architecture deep-dive

synthetic data · zero real patients
self-hosted or managed cloud
one database per hospital