.avif){kind=small}
How we handle personal health information
Where data lives, who can access it, how we respond to incidents, and how we meet our obligations under PHIPA, PIPEDA and GDPR. This page is written for hospital privacy officers, security teams and procurement. If you need more than what is published here, request our security documentation.
Three rules that apply to every engagement
ZeroOne is a services and integration company. We do not own patient data, we do not aggregate it across clients, and we never use it to train general-purpose models. Access is granted by the hospital, limited to the agreed purpose, and removed when the work ends.
Least privilege
Named individuals, role-based access and multi-factor authentication. Nobody on our team holds standing access to a production clinical system; access is granted per task and reviewed on a schedule.
Purpose limitation
Personal health information is collected, used and disclosed only for the purpose the custodian has authorised in writing. A new purpose means a new authorisation.
Everything is logged
Access to systems holding PHI is logged, retained for the period agreed in the contract and available to the hospital on request, including for breach investigations.
Seven commitments, each with what it means for your hospital
Every statement here describes how we work today. Where a control depends on the engagement, for example the hosting region, it is fixed in the contract and the data processing agreement before any data is accessed.
Our role under the law
In Ontario we work as an agent of the health information custodian under PHIPA. We collect, use and disclose personal health information only as the custodian permits and only for the agreed purpose. For clients in the European Union we act as a data processor under Article 28 of the GDPR, with a written data processing agreement. For personal information outside the health system we follow PIPEDA or the applicable provincial law.
Your organisation stays the custodian or controller. Our obligations are written into the contract, and you can audit them.
Handling personal health information
We work on de-identified data wherever the task allows. Where identifiable data is required, it stays inside the hospital's environment or the hosting region agreed in the contract, is accessed only through approved interfaces, and is deleted or returned at the end of the engagement with written confirmation.
No copies of patient data sit on laptops, in email or in shared drives. Deletion is a documented step, not an assumption.
Technical security
Encryption in transit (TLS 1.2 or higher) and at rest; multi-factor authentication for every account; separate development, test, training and production environments; vulnerability management with defined remediation windows; backups with periodic restore tests; and no direct database access to hospital systems.
Our controls map to the questions in standard hospital security questionnaires, so review is faster and answers are consistent.
Incident response
A named incident owner, a documented response procedure, and notification to the custodian at the first reasonable opportunity if information is stolen, lost, or used or disclosed without authority, as PHIPA requires. For EU clients we report personal data breaches to the controller without undue delay, so that the controller can meet its own 72-hour obligation.
You hear from us first and fast, with the facts your own notification decisions depend on.
Hosting and sub-processors
The hosting region is agreed per engagement; Canadian client data stays in Canadian regions unless the custodian agrees otherwise. We maintain a list of sub-processors, the cloud and tooling providers that may touch data, and share it on request, with notice before any change.
You know where data is and who else can see it before you sign.
Certifications and claims
We state only the certifications we hold and will publish them on this page as they are obtained. Our security controls are aligned with ISO/IEC 27001 practices, and our AI assurance work is aligned with NIST AI RMF and ISO/IEC 42001; alignment is not certification. HIMSS maturity experience is team project experience, not a HIMSS credential.
No surprises in due diligence. What we say on this page is what you will find when you check.
Responsible AI
Patient data is never used to train general-purpose models. AI models that touch clinical workflows are validated locally on the hospital's own data, deployed with a human review point, and monitored after go-live, following our Clinical AI Assurance process.
AI in your hospital is a governed service with a named owner, not a black box.
Four working rules for every integration and support engagement
Approved interfaces only
We connect through the hospital's approved interface engine, APIs and connectors. No direct database access and no undocumented integrations.
Separate environments
Development, test, training and production are kept apart. Nothing reaches production without the change record and approval the hospital's change process requires.
Access reviews and offboarding
Access is reviewed on a schedule and removed the day a team member leaves the engagement. The hospital receives the list of named users on request.
Backups and recovery
Where we operate systems, backups are encrypted, retention is agreed in the contract, and restore procedures are tested on the schedule documented in the runbook.
These rules apply whether we deliver a one-time integration, an advisory engagement or ongoing hospital IT operations support.
Accessibility statement
We aim to meet WCAG 2.0 Level AA on this website, consistent with the Accessibility for Ontarians with Disabilities Act (AODA). If any part of this site is difficult to use, tell us and we will provide the content in an accessible format. The same standard applies to the patient-facing and staff-facing interfaces we build for hospitals.
Documentation available on request
Security Questionnaire Responses
Our standard answers to common hospital security and privacy questionnaires, covering access control, encryption, logging, incident response, business continuity and sub-processors.
Data Processing Agreement
A data processing agreement template for GDPR engagements and an agent agreement template for Ontario custodians, ready for your legal team's review.
Incident Response Summary
How an incident is detected, who owns it, how and when the custodian is notified, and what the post-incident review covers.
Documents are shared under a non-disclosure agreement where required. Contract-specific controls, such as hosting region and retention periods, are confirmed in writing before any data is accessed.
.png)
.png){kind=small}
