PERSONA GUIDE · PRIVACY OFFICER · 8 min
Privacy Officer's Guide to Evaluating Healthcare AI Vendors
The CMIO cares about clinical workflow. The CIO cares about integration. The CFO cares about the contract value. The privacy officer cares about something different — the data flow, the subprocessor chain, the breach notification clock, and the artifacts a regulator can ask for two years after deployment. This is the evaluation framework that produces those artifacts, written for the reviewer the rest of the procurement committee usually defers to too late.
Seven specific documents a defensible privacy review produces. Each is a regulatory exhibit before it is a procurement input.
The map of every third party with access to PHI is where most contractual residency commitments fail. The disclosed-subprocessor list is rarely complete.
PIPEDA / CPPA amendments now distinguish consent for AI training from consent for service delivery. Most patient consent forms predate the distinction.
Privacy reviews that produce three or more contractual red flags should reach the steering committee as a veto recommendation, not as a "concerns" footnote.
The seven artifacts a defensible review produces
Privacy reviews fail not because the reviewer missed something but because the review did not produce the documents a regulator can read. The artifacts below are what makes the review defensible two years later when the IPC or CAI asks how the deployment was assessed:
- check1. Data-flow diagram. Every place PHI moves through the vendor's system, every region it lands in, every subprocessor that touches it. Hand-drawn on a whiteboard during the demo, then formalized. The vendor that cannot walk this diagram without consulting documentation is the vendor whose data flow is not under day-to-day operational control.
- check2. Reviewed and red-lined BAA. Annotated by the privacy officer with specific clauses flagged: audio retention, audit access, breach notification, subprocessor change rights, indemnification scope, residency commitments. Vendor responses to redlines are themselves an artifact.
- check3. Subprocessor map. Named list of every third party with PHI access. Includes the cloud provider, the speech-to-text layer if separate, any model API the vendor calls, any analytics service. Each subprocessor with a documented geography. The most-missed exhibit; the one that breaks residency commitments most often.
- check4. Privacy Impact Assessment (PIA). Required under Quebec Law 25 for tech processing personal information; strongly recommended under PHIPA, HIA, and BC FIPPA. Completed against the specific vendor and deployment configuration, not against the abstract category.
- check5. Patient consent update. The 2026 PIPEDA / CPPA amendments distinguish AI training consent from service-delivery consent. Quebec Law 25 Section 12 adds the algorithmic-transparency disclosure requirement. The hospital's consent forms need updating before the pilot, not as a follow-up.
- check6. Audit-log artifact sample. Not a marketing slide — an actual exportable audit-log file the vendor has produced for a similar customer. Reviewed for completeness against PHIPA Section 12, HIA Section 60, and analogous expectations.
- check7. Breach-response playbook. The contractually-binding timeline (24-72 hours typical under provincial regimes), the named vendor contact, the escalation path, the patient-notification language template. Drafted before signature; not the post-incident artifact.
The questions the privacy officer specifically owns
The procurement committee shares many questions across roles; the privacy officer owns these. They should appear in the privacy officer's own review memo, regardless of where else they show up in the broader RFP:
Specific cloud regions named in the contract. "Our cloud" is not an answer. Cross-border-transfer documentation if any PHI leaves the province. Verify against the data-flow diagram.
Audio retention default + customer-configurable override. Transcript retention. Generated-note retention. Audit-log retention. Each with a specific window and customer-controlled deletion path.
Customer PHI in training: yes / no / opt-in / opt-out. De-identification process if any. Whether de-identified outputs ever combine with re-identifying side information.
Vendor-side access controls. Privileged-access logging. Subprocessor access. Background-check requirements. Geographic distribution of vendor staff with PHI access.
The vendor's breach definition (which can be narrower than yours). The notification trigger (which can be slower than your policy). The contractual minimum vs the regulator's expectation. Reconcile in writing.
Notification commitments for: subprocessor changes, region changes, default-setting changes, ownership changes. Acquisition risk is real — see Augmedix → Commure.
Vendor attestation vs contractual commitment
The single most common procurement pattern that produces compliance failure is mistaking a vendor attestation for a contractual commitment. They are different artifacts with different legal weight:
| Artifact | What it is | What it isn't |
|---|---|---|
| Trust Center claim | The vendor's published policy posture at a moment in time. | A binding commitment. Defaults change; the page changes. |
| SOC 2 / HITRUST report | Third-party audit confirming controls existed during the audit window. | Evidence of current operation, or proof that the vendor will maintain controls. |
| BAA | Binding contract; defines PHI handling obligations. | A description of operational reality — only of the obligation the vendor has signed up to. |
| SLA / service description | Operational commitments that may be revised on notice. | Locked terms — most are revisable per the master agreement. |
| Vendor email reply | An opinion of the person who wrote it. | A binding commitment of the vendor. Treat as informational. |
The privacy officer's posture is: only the BAA and the master agreement bind in court. Everything else is helpful context that should be reconciled into the contract before signature.
The Canadian-specific overlay
For Canadian hospitals operating under PHIPA, Quebec Law 25, Alberta HIA, BC PIPA / FIPPA, or analogous statutes, the privacy review adds steps that U.S. equivalents do not require. The full landscape is in the Canadian compliance hub; the privacy-officer-specific extras:
- checkCross-border-transfer documentation. Every Canadian regime treats out-of-province PHI flow as a question that needs a written answer. PIPEDA Article 4.1.3 sets the federal floor; provincial regimes are typically stricter. The documentation has to live in the contract.
- checkSection 12 algorithmic transparency (Quebec). The hospital owes patients an explanation of how automated decision-making works. The vendor's model card, system card, and any explainability artifacts feed into the patient-facing explanation.
- checkCustodian / agent accountability (PHIPA, HIA). The hospital remains legally accountable as the health-information custodian. Contractual indemnification helps but does not transfer the underlying obligation. The privacy officer's review confirms the custodian/agent framework is correctly papered.
- checkProvincial breach-notification timeline. The contract must default to the strictest applicable timeline — typically the province's, not PIPEDA's federal 60-day floor.
The three veto patterns
The privacy review can recommend a veto. Three patterns that, when they appear together or in serious combination, warrant a veto-with-explanation rather than a "concerns" memo:
- closePattern 1: undisclosed subprocessor PHI access. The vendor's disclosed subprocessor list is incomplete or shifts without notification. The data-flow diagram contains "etc." or "various." Discovered during demo, ignored under time pressure. Almost always becomes the breach-disclosure story two years later.
- closePattern 2: BAA terms that conflict with provincial regime. Vendor's standard BAA has 60-day breach notification (HIPAA floor); applicable provincial regime requires 72 hours. Vendor unwilling to redline. The hospital signs anyway because "we'll handle it operationally." The contract is the controlling document; operational handling is not a defense.
- closePattern 3: training-on-customer-data with vague de-identification. Vendor reserves training rights "subject to de-identification." De-identification process is not specified. No customer opt-out. Acceptable in 2023; specifically problematic under PIPEDA 2026 amendments and Quebec Law 25 algorithmic-transparency rules.
What "good" looks like — vendor patterns to favor
Three patterns that consistently produce defensible privacy reviews. The privacy officer's recommendation aligns with these even when the CMIO has a different preference:
- checkData-minimal default. Audio deleted after note generation (Freed, Nabla). Training-on-customer-data off by default. Minimum-necessary access controls. The fewer things the vendor retains by default, the smaller the breach surface.
- checkPublic trust center with version history. The vendor publishes its data-handling policies in a Trust Center, with dated revisions. The history shows whether defaults have shifted opportunistically.
- checkRegion-specific contractual residency. Vendor commits to a specific cloud region in writing, not "our cloud." For Canadian customers, a Canadian region is named in the contract.
Where this fits in the WalledCare directory
This guide pairs with the broader RFP-questions checklist (covering privacy as one of six question categories) and the Canadian compliance hub (for the regulatory layer). The privacy-first adoption framework covers the pre-procurement choreography that makes this review possible. The vendor side-by-side includes residency posture and pricing transparency, both privacy-officer-relevant filters.