Security and data practices: How CuboidOS protects hospital information

Hospitals need software that improves care and operations without making patient information broadly available. That requires more than a login screen. It requires clear boundaries around who can access a hospital, what information a workflow needs, where data is stored, how integrations are verified, and when a support or engineering intervention is justified.

This report describes the security and data-protection practices built into CuboidOS, together with the operating principles that govern access to hospital information. It is written in plain language for hospital leaders, clinicians, administrators, and technology teams evaluating the platform.

A hospital’s data is separated from every other hospital’s data

CuboidOS is designed around hospital-level tenant separation. Each hospital operates in its own application context, with its own corresponding database and authentication endpoint. Patient documents and clinical attachments are stored under hospital-specific namespaces, and requests are resolved to the hospital identified in the agreed deployment context.

This means one hospital does not browse another hospital’s patient records, staff records, documents, results, billing information, or operational data through the application. A user’s access is evaluated within the hospital they belong to; being a CuboidOS user does not grant access to every hospital on the platform.

The separation is reinforced at the application layer. Hospital staff access requires an authenticated identity and a matching active Staff record for that hospital. Unknown or inactive staff records are rejected, and permissions are checked for sensitive areas such as patient information, clinical records, orders, billing, staff administration, settings, and audit activity.

Access is tied to active staff membership and role

Authentication answers “who is signing in?” Staff binding answers “are they an active member of this hospital?” Both are relevant before a person can use hospital workflows.

Hospital administrators can also choose whether a password change is required when a new staff account is first used. This gives each facility a practical onboarding control: it can require a new staff member to replace a temporary or administrator-issued password before continuing, according to the hospital’s own access policy.

CuboidOS does not enable open public staff registration through its application authentication route. Staff access is provisioned through the hospital’s administrative workflow, where the facility can control who should have an account and which role or permissions they receive.

AI features follow data minimisation and de-identification principles

CuboidOS uses AI-assisted documentation workflows in selected parts of the product, including conversational assistance, safety checks on AI requests, and clinical documentation support. All prompts and data sent to AI workflows follow two core privacy principles:

• Data minimisation: send only the minimum context required to complete the specific task—not an entire patient chart or hospital database by default.
• De-identification: remove or transform direct patient identifiers and unnecessary identifying details before information is sent for AI processing.

The purpose of these controls is to reduce the amount of sensitive information leaving the immediate workflow and to limit the consequences of any individual request. A request for help with a clinical note, for example, should carry only the relevant context needed for that task rather than unrelated demographics, historical records, or other patients’ information.

AI requests also pass through application safety controls before processing. Those controls are designed to identify unsafe or disallowed content and to keep the AI workflow within its intended product boundary. The application does not treat an AI feature as permission to expose all information available to the signed-in user.

Hospitals should still configure AI-enabled workflows according to their clinical governance, patient-consent, and internal privacy policies. AI assistance does not replace professional judgement, access controls, or the hospital’s responsibility to review generated output.

Secure cloud storage and database architecture

CuboidOS uses managed cloud database and object-storage services for hospital application data and files. The application keeps storage paths hospital-specific, uses private storage patterns for protected documents, and issues temporary access links for files when an object store is configured rather than relying on permanent public URLs.

The application also supports controls such as soft deletion for patient records and configurable limits for document size, count, and storage use. File names are sanitised and stored with generated identifiers, reducing dependence on user-supplied names.

Cloud security is a shared responsibility. Hospital data protection also depends on the production provider configuration: encryption settings, identity and access management, network controls, backups, retention, recovery testing, and monitoring. Those controls should be confirmed as part of a hospital’s deployment review rather than assumed from application code alone.

Documents and clinical attachments are checked at multiple points

Patient-document uploads enforce configured file-size and count limits, allowed types, and filename rules. Lab attachments add checks around the direct-upload process: the upload URL is short-lived, the hospital and order path are verified, and object metadata is checked again before an attachment is recorded in the database.

When a protected file is retrieved through the application, access is permission-gated. Temporary read links and private, no-store responses are used in the protected result-sharing and document flows to reduce accidental caching or unintended reuse.

These controls address access scope and predictable storage behaviour. They should not be confused with malware scanning or full content inspection; hospitals with specialised file-safety requirements should include those controls in their infrastructure and operational review.

Results can be shared without making them public

Laboratory and imaging result links use random, expiring tokens. The recipient must complete an additional verification step using information such as a patient date of birth or hospital number before the result is revealed.

After verification, the browser receives a short-lived HTTP-only verification cookie. The result document is returned through a purpose-built route that checks the signed payload, expiry, order identity, and hospital context. This creates a narrower sharing path than publishing a permanent, guessable document URL.

Hospitals should still share links carefully. The application evidence does not establish unlimited protection against repeated verification attempts, so rate limiting and monitoring should be included in the wider deployment review.

Integrations use signed requests and secure payment boundaries

CuboidOS verifies signatures on payment webhook requests before processing them. Payments and financial workflows are handled through Paystack’s payment architecture: sensitive payment credentials remain server-side, the client uses only the public configuration intended for browser use, and server-side webhook verification is used to confirm events received from the payment provider.

The same signed-request principle is used for the WhatsApp integration. Public-result payloads are signed and checked for type, order identity, expiry, and hospital context before a document is returned.

These boundaries keep payment-card handling and provider callbacks within their intended integration paths. Hospitals should separately confirm the provider account, settlement, refund, and reconciliation procedures used for their deployment.

Audit events support accountability

CuboidOS includes tenant-scoped audit-event delivery for operationally important activity. Events can include the hospital, actor, target, timestamp, outcome, request context, and an idempotency key. The application defines event categories covering areas such as access, clinical work, billing, staff changes, settings, and data operations.

Audit settings include retention options, and the application prevents retention from being reduced through the settings flow. Some audit helpers are intentionally non-blocking: if an external audit delivery service is temporarily unavailable, the primary hospital operation can continue while the delivery failure is recorded for follow-up.

The accurate claim is that CuboidOS provides an audit-event integration and defined instrumented actions. It is not accurate to claim that every possible user action is guaranteed to be logged or that an audit event can never be delayed or lost.

Support access is exceptional, scoped, and permission-based

Cuboid’s normal operating model is not to browse hospital data casually or use it for unrelated purposes. The team does not access hospital data outside the hospital and access scope agreed with that facility. Product-level internal statistics—such as staff counts, patient counts, and usage measures needed to improve the service—are limited to what is necessary for those purposes.

If a serious support, data-analysis, or bug-investigation issue requires direct database access, Cuboid staff may need to access the affected hospital’s database. That is an exceptional intervention: it should be necessary for the task, limited to the relevant hospital and data, and performed only with the hospital’s explicit permission under the agreed support process.

Enhanced support should therefore be understood as a controlled service arrangement, not unrestricted access. Hospitals should confirm the named contacts, approval path, scope, duration, and record of any exceptional support access in their agreement.

Secrets and selected integration credentials are protected

Sensitive configuration—such as database URLs, storage credentials, payment secrets, email credentials, API keys, and encryption keys—is intended to remain server-side. The application rejects some unsafe configuration, including a missing or too-short Auth cookie secret.

Selected integration credentials are encrypted before they are persisted. Tenant WhatsApp access tokens, for example, use authenticated encryption with a server-only key before storage.

This is not a claim that every database, backup, object, or log is encrypted in the same way. Encryption at rest, key rotation, deployment-secret storage, and provider controls should be confirmed for the production environment.

What this report supports

The practices described here support the following public claims:

• hospital data is separated by tenant so one hospital does not see another hospital’s records through the application;
• access requires an authenticated identity and an active Staff binding for the relevant hospital;
• permissions govern major clinical and operational areas;
• hospitals can require password changes for newly created staff accounts;
• AI workflows follow data minimisation and de-identification principles and send only task-relevant context;
• documents and attachments are subject to size, type, naming, path, and access checks;
• shared results use random, expiring tokens and an additional verification step;
• payment and messaging webhooks use signature verification;
• selected integration secrets are encrypted before being stored;
• tenant-scoped audit events and retention settings are part of the application;
• exceptional support access is limited to a necessary hospital context and requires explicit permission.

This report does not by itself establish HIPAA, GDPR, ISO 27001, or any other certification or regulatory status. It also does not replace confirmation of production TLS, encryption-at-rest settings, backups, disaster recovery, network controls, vulnerability testing, malware scanning, rate limiting, security monitoring, or hospital-specific governance procedures.

Security is both a product capability and an operating practice. CuboidOS provides application boundaries designed for hospital work; each deployment should pair those controls with clear permissions, support terms, clinical governance, and independently verified cloud and operational safeguards.