Introducing the architecture for Agentic Care

Every clinic runs on next steps. Most of them live in someone’s head and in several different tools. Bookings live in one tool, consent forms in another, clinical notes and photos in a third, payments and packages somewhere else. Each one describes the same patient, and none of them can see the others.

Sovica is one system for the whole clinic: online booking, consent and medical history, notes with photos, checkout, packages and memberships, marketing and recalls, stock and reports, with an assistant that can read all of it. The aim is the clinic that doesn’t drop anything. This post explains how it is put together, and why.

One record for the whole clinic

Sovica is a modular monolith. Each part of the clinic (bookings, clients, clinical records, payments, stock, marketing, workflows) is its own module with its own tables, and modules talk to each other through the services they export and the events they publish, never by reading each other’s tables.

That keeps one patient record at the centre without turning the code into one tangle. A booking can follow its service’s deposit rule, a treatment can draw down stock and a missed visit can start a recall, and each module still owns its own rules.

Isolation you cannot forget to apply

Every clinic shares one Postgres database, and every row carries the clinic it belongs to. Postgres row level security is switched on and forced for every table the application can touch, so a query only ever sees the current clinic’s rows, whatever its WHERE clause says. A test fails the build if a new table forgets. Our engineers wrote up how it works.

AI that works from the record

Ask Sovica answers questions about your clinic by building and running reports with the permissions of the person asking. The same records feed client summaries, dashboard briefs and campaign drafts. Every AI call goes through one service with a named feature, and each use records the model and the prompt version that produced it.

Messages wait for the work to finish

Emails, texts and webhooks are never sent in the middle of a request. They are queued inside the same database transaction as the change that caused them, so a booking that fails to save never sends a confirmation. Queued jobs carry ids and encrypted tokens only, never patient details.

Your data stays in its region

Sovica is designed to run in regional cells, each with its own database, storage and email, in the cloud region the clinic’s records belong to. UK records are hosted in London. The thin control layer between cells holds no patient data.

What’s next

We are opening Sovica to independent clinics and specialty practices. The same promise reaches further out from there: insurers, labs, referrers and hospitals are each a hand-off where a clinic waits on someone else. If you run a clinic and want to see it on Sovica, talk to us.