Home / Resources
Everything your team will want to read
Written for the people who have to evaluate this properly — architects, CIOs, finance leads and clinical directors — rather than for a brochure.
Library
Papers, guides and documentation
Documents are released as the corresponding capability completes. Request any of them and we will send what exists today and tell you plainly what does not.
The Hospital Operating System
Why hospitals need a platform layer rather than another application, and what changes when they have one.
Request a copy →Modular monolith for healthcare
The full architectural argument: isolated domains, contracts, event backbone and the extraction path.
Request a copy →Hospital modernization guide
A practical sequence for moving from fragmented systems to a platform, without a big-bang programme.
Request a copy →Implementation guide
What an Ospia implementation involves, phase by phase, with the responsibilities on both sides.
Request a copy →Migration guide
Data migration, parallel running, verification and cutover — the detailed method.
Request a copy →Security documentation
Controls, architecture, key management, incident response and the security programme.
Request a copy →API documentation
REST API reference, authentication, idempotency, pagination and error handling.
Request a copy →AI documentation
The explainability envelope, decision ledger, model router and agent governance model.
Request a copy →Product video library
Recorded walkthroughs of the workspaces, the task bar, the workforce console and decision replay.
Request a copy →Product updates
What shipped, what is next, and what moved — published against the phase plan.
Request a copy →Tools
Build your own business case
We would rather you arrive at your own numbers than accept ours. The leakage calculator below is live now — no email, no form, nothing gated. The rest are in build; ask and we will run any of them with you directly in the meantime.
Revenue leakage calculator
Your beds, occupancy and rejection rate against the two leaks that account for most of it: charges never billed, and rejections never recovered. Every assumption is visible and yours to change.
Open the calculator →ROI calculator
Model recovery from reduced billing leakage, fewer claim rejections and shorter length of stay against your actual volumes.
Request it run for your hospital →AI readiness assessment
Where your data, processes and governance stand today, and which agents would be safe to run first.
Request an assessment →Digital maturity assessment
An honest benchmark of your current systems against where comparable hospitals are heading.
Request a benchmark →Implementation readiness
What has to be true — data, people, process — before a cutover is safe to schedule.
Request a readiness review →Migration complexity calculator
Scope the move from your current system: data volumes, integrations, custom rules and realistic timeline.
Request a scoping call →Architecture deep-dive
A session for your IT leadership and architects: the platform, the gates, the security model, and your hardest questions.
Book a deep-dive →Questions
What committees actually ask
Every vendor says they're "AI-powered". Why is this different?
Ask three questions and the difference resolves itself. One: can you replay a decision the AI made four months ago — the exact model, prompt version, inputs and output? Two: can you set how far automation goes for one specific task, and show the audit record of who changed it? Three: can you switch AI provider without a project? Most systems answer no, no and no — because the AI was added to an architecture that had already been decided.
What can the AI never do?
Act outside the task registry, or act above the autonomy level you configured. Agents invoke the same permission-checked tasks your staff do, under the same authorization, producing the same audited events. Above L2, execution requires a named human. At L4, it requires a policy you approved — and every run still lands in the decision ledger, replayable.
What happens when the AI model is down — or we want a different provider?
The hospital keeps running. Ospia is a complete system with no external AI configured at all; deterministic fallbacks cover the assistive paths. AI adds speed and foresight; it is never a dependency. And because no provider is named anywhere outside the model router, switching providers — or routing sensitive task classes to a private model — is configuration.
We have unusual requirements. How much gets customised?
The target is that 90% of what a hospital asks for is configuration, not code — and it is measured rather than asserted: every change request gets classified config-or-code, and a code answer is treated as a design failure worth examining.
Can we integrate our LIS, PACS and ERP?
Yes, through a connector catalog rather than a project: FHIR R4 and HL7v2, DICOM/PACS, LIS/RIS, ERP and accounting, HRMS, government portals, payment gateways, WhatsApp/SMS/email and device feeds. Each connector declares its own configuration schema. Outbound, every domain event can be subscribed to as a signed webhook.
How do we move off what we're running now?
As an engineering programme, not your problem to solve: migration tooling with checksum verification, then a parallel run reconciled every morning, then a per-hospital cutover with a rollback path. We do not cut anyone over on optimism.
Who owns our data?
You do, in the plainest sense. Each hospital runs on its own physical database — self-hosted if you prefer. Everything is exportable, the FHIR R4 API is open to you, and the permanent event log is yours as much as the tables are.
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.
synthetic data · zero real patients
self-hosted or managed cloud
one database per hospital