What a clinic or health technology vendor actually has to get right
A small clinic has a practice management system it did not build, a handful of staff who all need access to records, a cloud backup somebody set up years ago, and no security budget. The reassuring part is that a short list of controls carries most of the risk. The uncomfortable part is that the list is shorter than most clinics think and almost none of it is technology.
Which privacy instrument reaches you?
It depends on what the organization is and where the information flows, which is a question for your counsel rather than one a web page can settle. A BC private clinic is generally looking at BC PIPA; an organization handling personal information in commercial activity across provincial or national borders is generally looking at PIPEDA.
The instruments themselves are public. The Personal Information Protection and Electronic Documents Act is the federal private-sector Act; BC’s Personal Information Protection Act is the British Columbia private-sector Act, and its Part 9 requires the protection and the retention of personal information as distinct duties. Health-sector rules may sit on top of either. We walk through which is which in which Canadian privacy law applies, and the control-by-control mapping is in the statute-to-control map.
The question comes first because it changes the breach obligations, and because a clinic that has bought a compliance programme aimed at the wrong Act has bought a programme that answers questions nobody will ask.
Access control, and the shared-login problem
Role-based access is the control that carries the most risk in a clinic, and it is usually the weakest. The practice management system almost certainly supports roles; the question is whether anyone has configured them, or whether every account is an administrator because that was quicker on the day the system went in.
A shared login makes the audit log useless, because it records that “reception” opened a record and not which person did. Every individual gets their own account, without exception, including locums and students. The reason to care is not tidiness. When a patient asks who looked at their file — and they do ask — a shared account means the answer is that you do not know, and “we do not know” is the answer that turns an incident into a complaint.
The practical list: an individual account per person; roles that reflect what each role actually needs; a documented process for removing access the day somebody leaves; multi-factor authentication on anything reachable from outside the clinic; and a quarterly read of who still has access. The last one takes an hour and finds something almost every time. The wider workplace picture is in identity and workplace security.
What does your audit log actually record?
An audit log here means the ordinary engineering thing: a record of who accessed which record, when, and what they did with it. Most practice management systems produce one. Fewer clinics know whether theirs is turned on, how long it retains, whether anyone can read it without calling the vendor, and whether it can be altered.
Four questions to put to your system, in writing, and to keep the answers:
- Does it record read access, or only changes? Reads are the ones that matter for curiosity browsing.
- How long are audit logs retained, and is that under your control?
- Who can access them, and can that access itself be seen in the log?
- Can you export them, or are you dependent on the vendor to answer a question about your own patients?
The last is the one that hurts during an incident, when the vendor’s support queue is between you and a question you need answered today.
Vendor and practice-management terms
Most health data in a small clinic is held by somebody else: the practice management vendor, the backup provider, the transcription service, the billing service, the appointment-reminder service. Each of those is an organization your obligations flow through, and each contract is where the flow is either controlled or not.
What to look for: where the data is stored and processed; whether the vendor uses it for anything beyond providing the service, including training models; who at the vendor can read it; what they commit to on notifying you of a breach, and how quickly; what happens to your data when the contract ends; and whether they subcontract, to whom, and under what terms.
Ask for those in writing before signing, and ask again at renewal. A vendor who cannot answer where the data sits is telling you something about how they run the rest of it.
Retention, and destroying what you no longer need
Records you do not hold cannot be stolen. Health records carry statutory and professional retention periods that pull in the other direction, which is exactly why the schedule has to be written down rather than assumed: how long each category is kept, what triggers the clock, and what happens at the end.
The material that is easiest to over-retain is not the clinical record at all. It is the exports — the spreadsheet somebody pulled for a report in 2019, the mailbox holding fifteen years of referrals, the old backup on a drive in a drawer, the decommissioned server nobody wiped. Those hold the same information with none of the controls, and they are what an attacker finds.
Devices, endpoints and email
The clinic environment has its own shape: shared workstations at reception, a laptop that goes home, a phone with the clinical application on it, a fax line that still receives referrals, and a printer holding scanned documents in memory.
The short list that matters: full-disk encryption on every device that holds or reaches records; automatic screen lock measured in minutes; supported operating systems with updates applied; a known process for a lost or stolen device; and no clinical data on personal devices unless the clinic manages them.
Email deserves separate attention, because it is the most common route in. The realistic controls are multi-factor authentication on every mailbox, a verification step for any change to payment details that arrives by email, and domain authentication so that messages claiming to come from the clinic can be rejected — the staged path for that is in SPF, DKIM and DMARC to enforcement. Where patient information genuinely has to travel by email, decide once how, write it down, and train to it.
A breach process that runs at five on a Friday
The test of a breach process is whether the person who discovers the problem knows what to do in the first ten minutes, without looking anything up. That means one printed page: who to call first, what not to do, and what to write down.
Decisions about notification belong to your counsel and, where the Act applies, follow the statutory test rather than anybody’s judgement of how bad it feels. The clinic’s job on day one is to preserve the ability to make that decision well: stop the loss, keep the evidence, and record what was known and when. The order of operations is set out in the first 24 hours of an incident, and building the plan in advance is incident response readiness.
What a US customer means by HIPAA readiness
A Canadian health technology vendor selling into the United States will be asked about HIPAA. The obligations live in the rules made under it, published as 45 CFR Part 164, and what a customer is usually asking is whether you can operate as a business associate under their agreement: access control, encryption, logging, breach notification to them within their timeline, and subcontractor flow-down.
No. There is no HIPAA certificate, and no United States federal body issues one. A vendor selling you a badge is selling a private opinion, which is not the same thing as the state a regulator would look for. What exists instead is an evidence position — controls in place, documented, demonstrable — which is the same work by a less satisfying name. Sector-specific preparation of that kind is regulated sector readiness, and the Canadian side of it is Canadian privacy readiness.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Is there a HIPAA certificate?
No. There is no HIPAA certificate, and no United States federal body issues one. A vendor selling you a badge is selling a private opinion, which is not the same thing as the state a regulator would look for.
Does BC PIPA or PIPEDA apply to a clinic?
It depends on what the organization is and where the information flows, which is a question for your counsel rather than one a web page can settle. A BC private clinic is generally looking at BC PIPA; an organization handling personal information in commercial activity across provincial or national borders is generally looking at PIPEDA.
Do we need a privacy impact assessment?
A privacy impact assessment is required of public bodies in British Columbia and is good practice for everyone else, and a short one written before a new system goes in is worth more than a long one written afterwards.
Can staff share a login at reception?
A shared login makes the audit log useless, because it records that “reception” opened a record and not which person did. Every individual gets their own account, without exception, including locums and students.
Nothing on this page is clinical, medical or legal advice. Which obligations reach a particular practice is a question for that practice’s counsel and its regulatory college.
Starting with the short list
Describe the practice management system, who has access and where the backups go. The reply names the two controls worth fixing first. More of our writing is indexed at writing.