Security model
Security is a property of the architecture.
Occentra protects occupational health data through architectural isolation, explicit access control and secure application design. Boundaries are built into the system, not added afterwards.
Tenant isolation
Dedicated database schema per occupational health provider
Least privilege
Role-based access so users see only what they are authorised to see
Auditability
Actions recorded so governance can explain what happened
Secure defaults
Configuration and platform behaviour designed to start closed
Security principles
Boundaries first, not bolt-on controls.
Occupational health systems hold medical information, employment context and operational records. Those records serve different people for different purposes. Occentra treats those boundaries as part of the domain model, not as permissions added at the end.
- Sensitive data is only presented to authorised users
- Employers, clinicians and operational users are separated by role
- Strong tenant isolation is a core architectural principle
- The platform prefers configuration over bespoke behaviour that is harder to reason about
Multi-tenant architecture
One provider, one database schema.
Occentra is multi-tenant. Each occupational health provider runs as a tenant with a dedicated database schema. Provider data is segregated at the database layer so isolation is an architectural property, not only an application convention.
Database
Provider A
schema_a
- Cases
- Assessments
- Documents
Provider B
schema_b
- Cases
- Assessments
- Documents
Provider C
schema_c
- Cases
- Assessments
- Documents
Clinical data protection
Different roles, different views of the same case.
A referral, case and report are not the same record to every participant. Employers initiate and receive what their role requires. Clinicians work with clinical detail. Operational users support the service without automatic access to medical information they do not need.
- Role-based access control determines what each participant can see and do
- Least privilege guides which fields and documents are presented
- Sensitive medical information remains visible only to authorised users
Case flow
Authentication and access control
Authorisation is part of the product model.
Access is organised around roles. Employers, clinicians and operational users receive capabilities appropriate to their work. Sensitive information is only presented to authorised users. The principle of least privilege shapes what the interface exposes, not only what the API permits.
| Role | Typical visibility |
|---|---|
| Employer | Referral context, case status and released reports appropriate to their role |
| Clinician | Clinical detail, assessments and records required for care and reporting |
| Operations | Operational workflow and administration without blanket clinical access |
Audit trail
Actions recorded where governance needs them.
Occentra records actions so teams can explain what happened across configuration and case activity. Auditability supports operational review and institutional accountability without claiming that every event is cryptographically immutable.
Configuration changes
Changes to templates, pathways and governed settings can be traced over time.
Case progression
Meaningful case events help explain how a referral moved from intake to report.
Access-relevant activity
Authorised actions leave a record that supports internal review.
Infrastructure and development
Secure defaults and modern application practices.
Data in transit is protected with HTTPS/TLS. The platform is built with modern web application security practices. Configuration is preferred to bespoke behaviour so security-relevant paths stay visible and maintainable. Secure-by-default design means the platform starts closed and opens access through explicit authorisation.
Scope
What this page explains, and what it does not.
This page explains
- How multi-tenant isolation is structured with dedicated database schemas
- How role separation shapes access to referrals, cases and reports
- How TLS, RBAC, least privilege and auditability fit the architecture
- How secure defaults and modern web application practices inform development
This page does not
- Replace your organisation's compliance programme or risk assessments
- Assert certifications or standards that are not listed here
- Describe every hosting or operational control in full detail
- Guarantee absolute security of any system connected to the internet
For contractual terms and website data practices, see the Privacy Policy and Terms of Use.
Frequently asked questions
Common questions from security and IT reviews.
How are occupational health providers isolated from each other?
- Occentra is multi-tenant. Each provider has a dedicated database schema. Strong tenant isolation is a core architectural principle, so provider data is segregated at the database layer.
Who can see sensitive medical information?
- Sensitive data is only presented to authorised users. Employers, clinicians and operational users are separated by role. Role-based access control and least privilege determine what each participant can see.
Is data encrypted in transit?
- Yes. Data in transit is protected with HTTPS/TLS.
Does Occentra keep an audit trail?
- Actions are recorded where governance needs them, including configuration and case activity, so teams can explain what happened.
What application security practices does Occentra follow?
- Occentra is built with modern web application security practices, prefers configuration over bespoke behaviour, and aims for secure-by-default design.
How do we ask deeper security questions?
- Register your interest or contact us. For website privacy questions, use the contact details on the Privacy Policy.
Talk to us about Occentra.
If you lead an occupational health service and want to explore the platform, register your interest and we will be in touch.