OHS Flow | Trust Centre
Trust Centre · Security

Security built into the clinic operating layer.

OHS is built for healthcare operations where sensitive information, staff workflows, connected inboxes, billing requests, and owner visibility all intersect. Security isn’t a bolt-on feature. It’s how OHS handles credentials, separates client environments, limits unnecessary data exposure, supports PHIPA-aligned workflows, and keeps operational activity reviewable.

PHIPA-aligned workflows SOC 2 Type II-audited infrastructure Separate client environments Server-side credential handling
Why this page exists

Clinic security is not just infrastructure. It is workflow control.

In a real clinic, sensitive work doesn’t sit in one system. It moves through inboxes, faxes, documents, billing requests, shared folders, staff handoffs, and patient-facing communication.

The work isn’t going to stop moving. OHS makes sure it moves through controlled channels instead of informal ones.

How OHS thinks about security

Five principles that shape the OHS security posture.

OHS security design starts from a practical reality: clinic work has to move. The goal is not to freeze operations behind heavy process. The goal is to make sensitive workflow movement more controlled, more visible, and easier to govern.

01

Built on SOC 2 Type II-audited infrastructure

OHS is built on SOC 2 Type II-audited infrastructure providers. Clinics should not have to wonder whether the foundation underneath their workflow software is serious.

That foundation matters, but infrastructure alone is not the product. OHS is responsible for how those services are configured, connected, governed, and used inside clinic workflows. The vendor stack provides audited infrastructure. OHS turns that infrastructure into a controlled operating layer for clinic work.

02

PHIPA-aligned workflow design

OHS is designed for healthcare operations where personal health information may be present. That means privacy and security are not treated as separate paperwork exercises. They shape how workflows are designed, how access is granted, how information moves, what is retained, what is escalated, and what requires human review.

The goal is practical PHIPA-aligned workflow design: sensitive clinic work should move through clear, controlled paths instead of informal side channels, buried inbox states, or invisible staff handoffs.

03

Dedicated client environments

Real OHS client deployments run in dedicated client environments. Clinic workflows are not mixed into one shared operational data pool across clients.

That architecture is part of the OHS trust model. It gives each clinic a cleaner operational boundary, simpler review, stronger owner confidence, and a safer foundation as more workflow modules connect around the same clinic.

This is not a premium upgrade path. It is the architecture.

04

OAuth and connected-service control

Connected services such as Gmail, inbox workflows, AI drafting, routing, classification, billing workflows, fax handling, and future integrations should run through controlled OHS access paths, not exposed directly in browser code.

Sensitive credentials, OAuth tokens, connected-service logic, routing rules, AI workflow controls, and automation belong behind that control layer. Staff interact with the workflow. OHS protects the access paths underneath it.

05

Human-accountable workflows

OHS does not remove humans from sensitive clinic workflows just because automation is possible.

Some work should be surfaced, structured, routed, reviewed, approved, escalated, or owned by a person. That is not friction. In healthcare operations, it is governance.

OHS is designed to support human-accountable workflows: AI can assist, systems can classify, queues can prioritise, and dashboards can reveal what is happening — but responsibility remains visible.

The standard

Secure enough to trust. Practical enough to use.

Clinic security cannot live only in policy documents. If the system is too heavy, staff work around it. If the system is too loose, sensitive work spreads through informal channels.

OHS is designed for the balance clinics actually need: PHIPA-aligned workflow design, SOC 2 Type II-audited infrastructure, separate client environments, server-side credential handling, role-aware access, data minimisation, AI oversight, and reviewable workflow activity.

OHS gives clinics the operating layer their EMR never gave them and their inbox was never built to provide.

In practice

What this means for a clinic using OHS.

Security should show up in how the system behaves, not just in what the Trust Centre says.

Audited infrastructure foundation

OHS is built on SOC 2 Type II-audited infrastructure providers, giving the platform a serious foundation for healthcare workflow software.

Controlled client boundaries

Real client deployments run in separate environments, keeping each clinic’s workflows inside its own controlled operating boundary.

Server-side control layer

Sensitive credentials, connected-service logic, tokens, AI workflow controls, and automation are handled server-side. Not as a best practice — as the architecture.

Human review where it matters

OHS keeps people in the loop for sensitive workflows where judgment, approval, escalation, or clinic accountability matters.

Reviewable workflow activity

OHS helps clinics see how operational work moves: what arrived, who handled it, what escalated, what resolved, and where better rules are needed.

EMR-adjacent by design

OHS supports the operational work around the EMR without pretending every sensitive workflow should become an automated chart action.

Security · Trust Centre · Last reviewed May 2026 · v1.0 Questions about this page? → Visit OHS Flow