OHS uses established infrastructure and service providers to host, secure, connect, process, and support clinic workflows. Provider selection is guided by healthcare privacy realities: PHIPA-aligned workflow design, Canadian privacy expectations, and the practical sensitivity of health identifiers. Sub-processors are not invisible background tools. They are part of the trust architecture: selected deliberately, scoped to the work they perform, and governed through the OHS operating layer.
A platform is only as trustworthy as the systems it depends on. So we chose carefully.
OHS is built on established infrastructure and service providers with serious security and operational controls. That foundation matters because healthcare workflow software cannot sit on fragile systems.
Vendor trust is not just about choosing strong providers. It is about choosing providers with healthcare privacy in mind, limiting what each provider does, understanding what data may flow through each service, and keeping OHS responsible for how those services are configured, connected, monitored, and governed.
OHS does not treat third-party services as interchangeable plug-ins. Each provider has a defined role in the system, a clear reason for being used, and a bounded place inside the OHS operating layer.
OHS uses infrastructure and service providers with SOC 2 Type II-audited controls for core platform operations.
That foundation matters. Clinics can trust that the systems underneath OHS are established, reviewed, and appropriate for sensitive operational workflows.
OHS is designed to avoid sending more information to a provider than the workflow requires. Some providers host infrastructure. Some process workflow data. Some support authentication, messaging, AI processing, payment workflows, OCR, document extraction, or connected-service access.
Each provider’s role stays scoped, intentional, and proportionate to the task. Health information requires this discipline. OHS provider use is shaped by PHIPA-aligned workflow design, Canadian privacy expectations, and the practical sensitivity of health identifiers.
Clinics can understand which providers support the platform and what role they play.
The sub-processor list stays clear enough for clinic owners, privacy reviewers, and due-diligence readers to understand the OHS operating model without needing to reverse-engineer the stack.
The providers below currently support OHS or are planned for specific OHS modules. Provider use is scoped to the role each service performs inside the platform. Certifications shown belong to each provider for its own systems.
OHS chooses infrastructure and service providers deliberately, but the clinic relationship remains with OHS. The platform is responsible for how providers are selected, configured, connected, scoped, monitored, and governed inside clinic workflows.
As OHS adds modules, expands into new workflows, or evaluates better-fit providers, the selection discipline doesn’t move: serious infrastructure, limited data exposure, healthcare-grade privacy thinking, and reviewable vendor use.
Some providers will be replaced. The standard for replacing them will not be.
Sub-processor governance should be visible enough for review and practical enough to support real clinic operations.
Each provider has a defined function inside the OHS platform. No mystery infrastructure, no anonymous third parties handling clinic workflow data.
OHS uses SOC 2 Type II-audited infrastructure and service providers for core platform foundations.
Provider access is tied to the workflow being performed, not treated as broad background access. Each service does its job and nothing more.
The Trust Centre gives clinics and reviewers a clear place to understand which systems support OHS and why.