Skip to content

Deployment and boundary

Platform

On-prem at the facility by default. Adapter profiles for country specifics. A public site that does not sit inside the clinical boundary.

Figure 6. The facility is the trust boundary. Staff web, patient web, and the API sit on the edge. Stores stay inside. Optional egress is dashed.

Beys runs on the facility's own servers by default. GPU is optional. Cloud is a secondary variant. Data residency is a feature.

What faces the network

Ingress exposes the API, the staff web, and the patient web.

Stores stay inside the boundary: the event log, the database, object storage, and imaging.

This public site is a separate origin. It does not proxy GraphQL. It does not read charts. It does not share a cookie jar with the clinical apps.

Adapters, not hardcodes

Country specifics are adapter profiles:

  • payer
  • identity document
  • language
  • guideline pack
  • notifiable-disease reporting

A worked payer profile is not the market. The product is global, with a Malaysia and emerging-high-growth-nation lead.

Operability

The clinical record is event-sourced. Rebuilds are an operations path, not a myth.

The IT administrator bootstraps an organization, a facility, and the first administrator. That role has no PHI by construction.

Optional council or note-generation APIs can egress if the facility configures them. On-prem sets egress near zero. It is not an absolute "PHI never leaves the building" slogan. Do not say that sentence.

Read facility deployment