Enterprise
A sovereign tenancy, central policy with local protocol, and a million contacts a month across every site and every clinical system you run — without replacing a single one of them.
One tenancy, mid-morning
Eleven sites live, thirty-four services between them with one more staged, four distinct clinical systems and none of them migrated — governed from one place, with every override still in scope.
What it holds
How it lands
The failure mode of an estate-wide programme is going wide before anything is proven. This is deliberately the other shape: an empty tenancy your DPO can sign off, one service at one site against real traffic, and only then a rollout that inherits everything already working.
A dedicated sovereign environment in your jurisdiction, with identity, retention and residency policy configured before any patient data exists in it. Your DPO signs off on an empty system.
The integration layer is pointed at what each site runs — EHR, interface engine, telephony, identity. Sites on the same system share the work; sites on their own do not hold anyone else up.
One service at one site, against real traffic, with a named clinical owner and a weekly review of every escalation. Nothing widens until that site's numbers are the ones you wanted.
Service by service and site by site, on your change calendar. Each rollout inherits the policy, the protocols and the integrations already proven, so the eleventh site costs a fraction of the first.
Governance and control
None of this is an add-on tier. A tenancy arrives with its identity, its policy and its audit trail already wired, because an estate cannot retrofit governance onto something that is already carrying patient contact.
Escalation thresholds, retention and tone are set once for the estate. A site that needs its own triage rule gets one as a scoped override, and the override is visible from the centre rather than hidden in a config file.
Who can see a transcript, change a protocol or export a report is bound to their role and their site. Provisioning and deprovisioning run from your directory over SCIM, so a leaver loses access with their badge.
SSO over SAML or OIDC against the directory you already run, with SMART on FHIR where a clinician is entering from the chart. No second password and no separate user list to reconcile.
Every contact, decision, override and write-back is logged against a person or a policy, exportable, and retained on your schedule rather than ours. It is built for the review you will eventually be asked for.
A dedicated environment in your jurisdiction — EU by default, with no US CLOUD Act exposure. Nothing you send trains a model, ours or a third party's, and identifiers are scrubbed in memory before anything persists.
A named technical account manager, a clinical safety contact, and severity-based response commitments written into the contract. Escalation reaches a person, not a queue.
How it is bought
No figures here, because any number printed on a page is wrong for most of the people reading it. What is fixed is what each shape includes — and a pilot is a real contract with an end date, not a trial that quietly renews.
One service, one site
One service, every site
Every service, every site
Deployed as
Federally qualified health centers run the widest access mandate in medicine on the tightest margins. This is the front door built for that — multilingual, always open, and reportable against the measures the grant depends on.
See the deploymentEnterprise deployment for multi-site health systems: central governance with local protocols, routing across the whole estate, and a sovereign tenancy that scales past a million calls without a migration.
See the deploymentMulti-specialty groups answer one number for a dozen different clinical services. This routes each caller to the right specialty with the right protocol, and coordinates the patients who are under three of them at once.
See the deploymentFAQ
No, and consolidating first is the most common way these programmes stall. The layer reaches each system as it is — native API where the vendor exposes one, the interface engine where it does not, and a driven session where there is nothing else. Eleven sites on four distinct systems is a normal estate, not an edge case.
In a dedicated tenancy in the jurisdiction you choose, EU by default, with no US CLOUD Act exposure. Access is bound to role and site through your own directory, every read is logged, and retention runs on your schedule. Nothing you send is used to train a model, ours or anyone else's.
Policy is set once for the estate and overridden per site where a service genuinely differs. Overrides are explicit, scoped and visible centrally, which is the difference between local autonomy and eleven systems drifting apart. The console shows how many are in force and whether each is still in scope.
A tenancy in week one, connections through weeks two to four, and a single service live at a single site by week eight with a named clinical owner reviewing every escalation. Nothing widens until that site's numbers are the ones you were promised.
Severity-based response commitments are in the contract, not the brochure. Severity 1 reaches an on-call engineer around the clock, your named technical account manager owns the follow-up, and the status page is the one our own team watches.
Tell us how many sites, how many clinical systems and which one everybody warned you about. We will come back with the tenancy design, the integration map and what the first ninety days actually look like against it.