One click. That’s all it takes to send an email or message holding a patient’s health card number, date of birth, and other personal health information across the open internet, where it sits in an inbox indefinitely, with no record of who opened it, no record of where it was forwarded, and no way to take it back.
Standard email is a convenient communication channel. But every time it’s used to send information about a patient’s medical care, both the provider and patient are at risk. Fortunately, compliant messaging options are readily available for medical practices, which we’ll cover in this article.
What Standard Email Really Provides (and What It Doesn’t)
Inside a clinic, protected health information (PHI) stays within systems designed to keep it secure, like the EMR and other closed-loop tools. But email is not one of these tools. The moment a message leaves for an outside recipient, it travels across the internet much like an open postcard.
To protect messages in transit, modern email relies on “opportunistic TLS (transport layer security).” Under this protocol, a sending server attempts to negotiate an encrypted connection, but if the receiving server is outdated or badly configured, the system falls back to plain text delivery. This method is sufficient for most businesses, but it’s not ideal for industries subject to compliance requirements, such as healthcare.
Compliance Problems Related to Email
What the law actually requires
Health privacy law in both the United States and Canada covers similar ground regarding email compliance.
In the US, the HIPAA Security Rule requires organizations to protect electronic patient data in transit. It doesn’t mandate encryption in every scenario, but it requires clinics to either encrypt the data or formally document why they didn’t.
Canadian law reaches the same outcome by a different route. PIPEDA’s safeguards principle, along with provincial health-privacy statutes like PHIPA in Ontario and PIPA in BC and Alberta, requires safeguards proportionate to the sensitivity of the information. For personal health information, encryption in transit is the expected standard.
Where standard email falls short
The points below are not aspirational guidelines. They are enforceable legal obligations, and standard email routinely fails to satisfy them on at least four specific grounds:
- Redactability: Both HIPAA’s mitigation standard and Ontario’s health-privacy breach guidance require organizations to contain and mitigate a misdirected disclosure of PHI. Standard email provides no mechanism to retract, correct, or redact a message after delivery. If PHI is sent to the wrong patient or contains a clinical error, the record cannot be recalled — the obligation exists, but the channel has no capability to meet it.
- Transferability: The person entitled to control a record isn’t always whoever holds the email account. A young person mature enough to consent to their own care controls that health information, and may be entitled to keep it confidential from a parent. If the clinic has been emailing a parent’s inbox, there’s no way to shift access to the patient, confirm what was forwarded or kept, or retrieve it.
- Cross-border accountability: Neither HIPAA nor Canadian privacy law requires patient data to stay in a particular country. Both instead hold the clinic responsible for protecting it wherever it’s processed, whether through business-associate safeguards in the US or a comparable-protection standard in Canada. Standard email gives the clinic no control over where a message is routed or stored, leaving it accountable for information it can no longer see or safeguard.
- Least-privilege access: HIPAA’s access control standard requires that systems holding PHI grant access only to those authorized to have it, with encryption as the expected safeguard. Standard email can’t enforce this: under standard configurations the provider controls the encryption keys and can technically read message contents, so a party the clinic never authorized still has access. That access is an architectural property of every major enterprise email platform, not a setting a clinic can switch off.
Why email fails by design
The compliance gaps are a direct consequence of how email is engineered. Three properties of standard email make the problem structural:
- No guaranteed encryption in transit: TLS protects a message only between servers that both support it. Standard email can’t verify that every node along the way is encrypted, so a message can travel protected on one hop and in plain text on the next.
- No audit trail: Once a message leaves the outbox, there’s no reliable record of who opened it, forwarded it, or captured it. Delivery receipts confirm that a server received the message, not that the intended patient did (and read receipts are optional and easily switched off).
- No expiry or central control: A delivered email can persist indefinitely, with no automatic deletion and no record of who accessed it afterward. If a record ever has to be placed on hold or purged, the channel offers no way to do it.
How human error compounds the problems
The risks of standard email in healthcare settings multiply when you add human behaviour to the mix.
A peer-reviewed analysis of voluntarily disclosed HHS data breaches from 2015 to 2020 found that unintentional human error compromised more than twice as many patient records as deliberate external attacks, and that phishing alone accounted for more compromised records, on average, than any other single cause.
These findings show that email’s structural vulnerabilities pose a real-world risk. In practice, the system’s design leaves open gaps that routine human errors often expose.
The Secure Messaging Alternative
Purpose-built secure messaging is designed to solve these problems. Instead of pushing protected information out to a mailbox the clinic can’t control, it keeps the document in place and gives the patient a verified way to reach it.
The notification that gets sent to the patient’s email carries no PHI of its own; it’s a secure link, and the record opens only after the right person confirms who they are. Every open is logged, and the document stays under the clinic’s control long after it’s sent.
Cortico’s Secure Patient Messaging tool is built on exactly this model.
Beyond compliance, standard email also creates a workflow bottleneck that compounds the security risk. Sending a document by email typically requires a staff member to locate the file in the EMR, download it, attach it to an outgoing message, and manually log the interaction — steps that pull the record outside the EMR’s controlled environment at least twice. During that transfer, copies created in the process often stay in download folders, sent items, and local storage without any audit trail.
The secure messenger eliminates those steps because documents are sent directly from the patient’s EMR chart in seconds, without leaving the system, without creating untracked copies, and without a phone call or staff handover.
How Cortico’s Delivery Infrastructure Works
Cortico Secure Messenger is not an open reply channel by default. Two-way messaging is off unless a clinic, provider, or individual patient enables it — a requisition or post-visit instruction can be delivered without phone calls.
When messaging is on, Cortico’s automation handles roughly 80% of common inbound requests from cancellations to form requests, all without staff involvement. The clinic stays in control of who can reply, when, and at what level. That same principle of controlled access governs how every document moves through the platform:
- Asymmetric patient encryption keys: Each patient’s documents are encrypted with a key generated specifically for that patient. There is no shared encryption layer across the patient population. A key compromise for one patient does not expose records for the rest.
- Temporary server storage: Patient documents are not stored permanently on Cortico’s infrastructure during the delivery process. Files are held temporarily and encrypted throughout that window. Once delivered, the record moves into the patient’s own encrypted personal health record (and is retained) for as long as the patient chooses to keep it under their control, not the clinic’s.
- Full audit trail of delivery status and access: Every message carries a complete audit record from delivery confirmation to access timestamp to document status. Clinics have a record of when a patient accessed their results, which isn’t provided in a standard email.
- Instant redactability and recall at any point post-send: If a document was mistakenly sent to the wrong person, has an error, or must be retracted for any administrative reason, Cortico allows the clinic to recall or redact it after delivery. The permanent release problem expected in standard email does not apply.
Compliant Delivery Messaging (HIPAA, PIPEDA, and Provincial Privacy Law)
Cortico is built to meet North American privacy standards — HIPAA in the US, and PIPEDA, PHIPA, and PIPA in Canada. Files travel over TLS 1.3, are end-to-end encrypted, and route directly into the patient’s EMR chart with a full audit trail. The platform holds SOC 2 Type 2 and ISO 27001 certifications, backed by independent Threat Risk (TRA) and Privacy Impact (PIA) assessments from CIPP/C- and CISSP-certified external reviewers.
Identity Verification as a Security Guardrail
A common objection to purpose-built secure messaging platforms is the additional step patients must complete before accessing their records. It is worth noting that the identity verification step is not operational overhead or a friction point to engineer away. It’s what ensures the record opens only for the intended patient, rather than for whoever happens to have access to the inbox.
An email recipient doesn’t require identity verification, so anyone with access to the inbox (the patient, a family member, an employer, or anyone with access to the patient’s device) can open and read the contents of a confidential medical record.
There is no way of knowing that the intended patient is actually the person viewing the record.
To protect PHI sent by email, Cortico requires patients to verify their identity using their Health Card Number and Date of Birth before any single character of that information is available to view.
Patients can only view the document behind a verified secure link with identity verification. The clinic keeps control of access to protected health information. The identity verification is not a product feature layered onto a messaging system. It closes standard email’s core security gap: PHI is accessible only to the person who can verify they are the intended recipient.
Expanding Credential Pathways
Cortico is rolling out Single Sign-On (SSO) options for patient identity verification. The architecture of the security model does not change. PHI is exposed only after confirmed identity. SSO expands the set of credential pathways a patient can use to satisfy that verification requirement. The identity verification contract (no PHI without confirmed identity) remains the structural foundation. Building SSO is an additional way to satisfy that guardrail, not to overstep it.
Healthcare practices typically do not encounter the limitations of standard email during a compliance review. They discover them when there’s already an incident related to a potential breach. Cortico adds a dedicated security layer to every step of that delivery process, ensuring that discovery does not have to come at a patient’s expense. With SSO now part of that, verifying a patient’s identity is faster without giving up any control.
See how Secure Patient Messaging handles document delivery, or book a demo to walk through it with your own workflow. Cortico’s full privacy brief and security architecture is also available.
