05
Integration
A connector catalog — configured, not coded.
FHIR · HL7 · ABDM · DICOM · LIS/RIS · ERP · payments · messaging · devices
Home / Platform
A platform, not an application
Ospia is organised around ten capability platforms rather than a list of modules. Every capability is reusable by every other — which is why the tenth thing we build costs less than the first, and why your tenth requirement should too.
The capability model
Ten platforms, four layers
Modules are how work is organised. Platforms are what the work compounds into. Read it as a stack: the surfaces you touch at the top, the kernel everything stands on at the bottom.
Layer 04
Boundary
Everything that faces outward — people, systems, partners.
08
Developer
Extension points that are documented rather than reverse-engineered.
typed contracts · generated OpenAPI · SDK · published event catalog
09
Marketplace
Every module is an installable package with a manifest.
a store is a storefront over a mechanism that already exists
10
Experience
Thin surfaces over a headless core.
design system · role workspaces · command bar · operations wall
Layer 03
Intelligence
Everything that observes, decides and acts on its own.
04
AI
Intelligence, governed like staff.
agent runtime · memory · model router · decision ledger · governance
06
Analytics
Read-models built from events, and a live digital twin of the hospital.
read-models · digital twin · prediction service · data-lake export
07
Automation
A workflow engine — plus the rules engine everything routes through.
timers · SLAs · escalation · compensation · rules engine
Layer 02
Domain
Everything a hospital actually does, and what it is owed for it.
02
Clinical
One record, one timeline — every point of care writing into the same chronology.
patient · EMR · orders · nursing · ICU · theatre · beds · emergency · lab · imaging · blood bank
03
Financial
A real general ledger underneath the revenue cycle — statutory accounting, not an export.
billing · revenue cycle · insurance · claims · general ledger
Layer 01
Kernel
What all nine of the above stand on.
01
Core
A deliberately tiny kernel with zero business rules.
identity · authorization · tenancy · configuration · crypto · observability
The rule that keeps this honest: platform before features. Before anything is built we answer eight questions — can another feature reuse it, can AI use it, can automation use it, can workflows orchestrate it, can external systems integrate with it, can hospitals configure it, does it add to institutional knowledge, will it still make sense in ten years. Any "no" sends the design back.
Intent & tasks
Tasks are permanent. Screens are temporary.
The most consequential decision in the architecture, and the least visible one: capability does not live in pages.
Every capability is a declared task
Register Patient. Admit Patient. Prepare Theatre. Dispense Medicine. Generate Claim. Each is declared by its module with typed parameters, the permission it demands, the workflow that orchestrates it, and the events it publishes.
typed params · permission · orchestration · emitted events · autonomy level
Six front doors, one implementation
A screen, the command bar, a spoken instruction, the AI copilot, an autonomous agent and a partner's API call are all invokers of the same task. Not six code paths kept in painful agreement — one, with six ways in.
screen · command bar · voice · copilot · agent · external API
Every screen eventually optional
New surfaces — kiosk, ward tablet, smart-TV wall, wearable — are thin clients over a registry that already exists. Adding a channel stops being a project.
intent is the interface · a screen is one representation of it
This is also what makes the AI safe to expand. An agent is handed a permission-scoped subset of the same task registry your staff use, under the same authorization, producing the same audited events. There is no back door because there is no second door.
Configuration
Your rules are data, not our code
The single biggest driver of long-term cost in hospital software is how a hospital-specific rule gets implemented. We made that a first-class engine rather than a development request.
One engine, every rule
Numbering schemes, bed allocation, pricing and discounts, package rules, approval matrices, referral rules, insurance rules, consent requirements, clinical pathways and discharge criteria — all versioned, tenant-scoped data evaluated in one place.
versioned · tenant-scoped · reversible · audited
90%, measured not asserted
Every change request a hospital raises is classified configuration-or-code. A code answer is treated as a design failure worth examining, and the ratio is reported back to you.
target: 90% of requirements met without development
Built by your team
Forms, reports, dashboards, workflows, approvals, letters and certificates authored by hospital staff and validated server-side against a bounded vocabulary.
Phase 4–7 · governed authoring, not free-form scripting
Time & memory
A hospital that remembers everything
Every action publishes an event, and every event is kept permanently. The event log is the hospital's history, not a rolling buffer.
One fact, many listeners
Pharmacy publishes MedicineDispensed and knows nothing about who cares. Inventory decrements, billing posts, analytics counts, audit chains. Adding an eleventh listener later changes nothing that already works.
durable outbox · at-least-once · idempotent consumers · versioned catalog
As-of, not just as-is
Clinically and financially significant records are versioned append-only. "What did this chart show when the drug was prescribed" is a query, not archaeology.
append-only version history · as-of queries · full replay
Context arrives before you ask
Open a patient and the relevant past assembles itself: prior admissions, this doctor's preferences, similar cases and outcomes, previous medications, billing and insurance history.
knowledge graph · memory stores · consent- and permission-gated
Records of clinical and financial significance are versioned rather than overwritten, and every workflow supports undo, rollback and compensation. Nothing important is irreversible — see the architecture for how that is enforced.
Go deeper
The rest of the platform
Architecture
Modular monolith, isolated domains, event backbone and the CI-enforced gates.
AI Workforce
Twenty-one digital employees, the autonomy ladder and the governance model.
Security
Tenant isolation, encryption, access control and the audit chain.
Developers
API, SDK, event catalog, webhooks and extension points.
Related
Read next
Where this fits in the wider argument.
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