Is PGP still relevant today?

PGP (Pretty Good Privacy) remains relevant for encrypting email and individual files, but it is rarely the right choice for encrypting healthcare images at scale. PGP uses asymmetric key pairs well, but its key management model requires every sender and recipient to maintain and exchange public keys, which becomes operationally difficult in clinical workflows involving many providers and patients. Modern healthcare platforms use AES-256 for at-rest encryption managed through a dedicated key management service, and TLS 1.3 for in-transit encryption. These approaches are better suited to PHIPA compliance because they integrate with audit logging and access controls that PGP does not provide out of the box.

Encrypting Patient Images at Rest and in Transit

Q: What is data encryption in healthcare?

Data encryption in healthcare converts patient records, images, and health information into ciphertext that only authorized parties with the correct decryption key can read. There are two states to protect: data at rest (stored on servers, disks, or cloud buckets) and data in transit (moving across networks between applications). In Canada, PHIPA and PIPEDA require health information custodians to implement reasonable safeguards proportionate to the sensitivity of the data. Dermatology images, which contain both photographic identity and clinical information, sit at the high-sensitivity end. AES-256 for storage and TLS 1.3 for transmission are the accepted standards that satisfy these obligations.

Q: How to keep patient data secure?

Keeping patient data secure in a healthcare platform requires layered controls beyond encryption alone. Start with AES-256 encryption at rest and TLS 1.3 in transit. Add role-based access controls so only treating clinicians can decrypt specific patient records. Maintain immutable audit logs of every access and export event. Run regular vulnerability assessments and penetration tests. Train staff on phishing and physical device security. Under PHIPA, you also need a documented breach response procedure that covers notification to Ontario's Information and Privacy Commissioner within 90 days of discovering a reportable breach. Data minimization matters too: only retain images for as long as clinically necessary.

Q: Does HIPAA require healthcare providers to encrypt all electronic patient data?

HIPAA's Security Rule classifies encryption as an 'addressable' specification, meaning US covered entities must implement it or document an equivalent safeguard. In practice, most healthcare legal counsel treats encryption as required because documenting a justified alternative is difficult to defend after a breach. For Canadian providers, HIPAA does not apply directly. PHIPA (Ontario) and PIPEDA (federal) use a 'reasonable safeguards' standard instead. Because regulators have found organizations non-compliant when encryption was available and not implemented, Canadian healthcare platforms should treat encryption as required rather than optional. Cross-border platforms handling both Canadian and US patient data should satisfy both frameworks.

As of December 24, 2024.

Dermatology clinics and digital health platforms generate substantial volumes of sensitive medical images, photos of skin conditions, lesions, and wounds that are among the most personal files a patient can share. Under the Personal Health Information Protection Act (PHIPA) in Ontario and the Personal Information Protection and Electronic Documents Act (PIPEDA) at the federal level, custodians of that data have a legal obligation to protect it with reasonable technical safeguards. Encryption is the accepted answer for both storage and transmission.

This article explains exactly what encryption means in a healthcare imaging context, which algorithms meet Canadian compliance requirements, and what your technical team needs to implement to satisfy PHIPA encryption obligations.

What is data encryption in healthcare?

Short answer: Encryption converts patient data into ciphertext that only authorized parties with the correct decryption key can read. Two states need protection: data at rest, sitting in databases or cloud storage buckets, and data in transit, moving across networks between applications. In a healthcare context, both expose patients to harm when left unencrypted. Canadian privacy law under PHIPA and PIPEDA requires health information custodians to implement reasonable safeguards proportionate to data sensitivity, and encryption satisfies that standard for electronic personal health information. Dermatology images, which contain photographic identity alongside clinical diagnosis, sit at the high-sensitivity end of that scale.

Data at rest includes servers holding Electronic Medical Records (EMR), cloud buckets containing skin scan images, and local hard drives in clinic workstations. Data in transit covers uploads from a patient's phone to a cloud server, transfers from a clinic's Electronic Health Record (EHR) system to a specialist's inbox, and calls between microservices inside a platform. Both carry risk. A breached storage volume exposes files if they are not encrypted. An intercepted network session exposes transmissions if Transport Layer Security (TLS) is not enforced. The Government of Canada's guidance on digital security and privacy recognizes encryption as the standard control that meets the "reasonable safeguards" bar.

How does PHIPA define encryption requirements?

Short answer: PHIPA does not name a specific algorithm, but it requires health information custodians to protect personal health information against unauthorized access. Ontario's Information and Privacy Commissioner has consistently identified encryption as the minimum expected technical control for electronic personal health information. The federal PIPEDA framework mirrors this under Principle 7 of Schedule 1. When a breach occurs and data was not encrypted, regulators treat that as a failure to implement reasonable safeguards, triggering mandatory breach reporting and potential findings of non-compliance. Health Canada and the Canadian Centre for Cyber Security both recommend encryption as a foundational control for healthcare data.

For platforms storing dermatology images, which contain both photographic likeness and clinical information, the sensitivity level is high enough that encryption should be treated as mandatory rather than optional. Health Canada confirms this expectation through its published guidance on health data management.

For deeper context on how PHIPA and PIPEDA interact on patient data rights, see PHIPA, PIPEDA, and Skin Health Data: What Patients Should Know.

Which encryption algorithms should healthcare teams use?

Short answer: Advanced Encryption Standard 256-bit (AES-256) is the standard for data at rest; TLS 1.3 is the standard for data in transit. Both are endorsed by the National Institute of Standards and Technology (NIST) and are compatible with PHIPA and PIPEDA compliance frameworks. The National Institutes of Health (NIH) and Canadian Centre for Cyber Security recommend these algorithms for protecting health records. For dermatology platforms, AES-256 in GCM mode is preferred because it provides both confidentiality and integrity authentication in a single pass, reducing implementation complexity compared to CBC mode with a separate HMAC.

The table below summarizes the algorithms relevant to medical image security.

Algorithm	Type	Use case	Key length	Notes
AES-256	Symmetric block cipher	Encrypting images and PHI at rest	256-bit	NIST-approved; used by Canadian government for classified data; fast for large files
AES-128	Symmetric block cipher	Lower-overhead storage encryption	128-bit	Acceptable for many healthcare contexts; less future-proof than AES-256
TLS 1.3	Asymmetric handshake + symmetric session	Data in transit (HTTPS, API calls)	Negotiated per session	50% faster handshake than TLS 1.2; removes weak cipher suites by default
TLS 1.2	Asymmetric handshake + symmetric session	Legacy transit encryption	Negotiated per session	Still acceptable but should be migrated to TLS 1.3
RSA-2048	Asymmetric	Key exchange, certificates	2048-bit	Used to establish TLS sessions; RSA-4096 preferred for new deployments
SHA-256	Hashing	Integrity verification of stored images	256-bit output	Not encryption; used alongside encryption to detect tampering

For medical images specifically, AES-256 in GCM (Galois/Counter Mode) is the recommended mode because it provides both confidentiality and integrity authentication in a single pass. CBC mode requires a separate HMAC for integrity, which adds implementation complexity and room for error.

How do you encrypt patient images at rest?

Short answer: Store images in encrypted volumes or object storage buckets with server-side AES-256 encryption, manage keys in a dedicated key management service (KMS) that sits separate from the data it protects, and enforce access controls so decryption only occurs for authorized clinical workflows. Three layers matter here: storage-level encryption, application-level encryption, and key management. Each adds a barrier that a breach must overcome. Most Canadian healthcare platforms satisfy PHIPA's reasonable-safeguards requirement by combining all three. The NIST Special Publication 800-111 guide to storage encryption technologies explains how each layer maps to specific threat scenarios.

The three layers of at-rest encryption for medical images are storage-level, application-level, and key management.

Storage-level encryption means the underlying disk or object store handles encryption transparently. Cloud providers offer this as a default option (often called server-side encryption or SSE). Enabling SSE with AES-256 means that even if someone extracts the raw storage media, the image files are unreadable without the encryption key. For on-premise clinic servers, full-disk encryption tools achieve the same effect.

Application-level encryption adds a second layer. Before an image is written to storage, the application encrypts it using a patient-specific or record-specific key. This means a breach of the storage layer alone does not expose patient data because the application key is stored separately.

Key management is where most implementations fail. Storing an encryption key in the same location as the data it protects defeats the purpose. A dedicated KMS, whether a cloud-native service or a hardware security module (HSM), holds keys separately and enforces policies around who can request decryption. For PHIPA compliance, the key management audit log becomes part of the access record that demonstrates you know who accessed which patient's data and when.

For an overview of how DermaDex implements these controls for Canadian dermatology workflows, see our security and compliance documentation.

How does TLS protect patient images in transit?

Short answer: TLS 1.3 encrypts the connection between a client and a server before any data transfers, so intercepting the network traffic yields only ciphertext that cannot be decrypted without the server's private key. A 2024 review of healthcare data security published in PubMed Central found that encryption in transit combined with proper certificate management is the single most effective control against interception of health data (ref). Under TLS 1.3, the handshake completes in one round trip rather than two, cutting latency and removing several classes of downgrade attacks present in TLS 1.2.

When a clinician uploads a patient's skin scan from a mobile app to a cloud EMR, or when a patient shares images through a telemedicine platform, the transmission crosses networks that neither party controls. TLS establishes an encrypted tunnel by performing a handshake: the client and server authenticate each other using certificates, agree on session keys using an asymmetric algorithm (typically X25519 or RSA), then encrypt all subsequent traffic with a fast symmetric cipher (AES-128-GCM or AES-256-GCM).

For healthcare platforms, three TLS implementation details matter for compliance:

Certificate pinning for mobile apps prevents man-in-the-middle attacks even on compromised Wi-Fi networks in clinics or hospitals.
HSTS (HTTP Strict Transport Security) headers ensure that browsers and clients never fall back to unencrypted HTTP, even if a user types a plain HTTP URL.
Cipher suite restrictions should disable RC4, 3DES, and export-grade ciphers, all of which have known vulnerabilities. TLS 1.3 removes these by default, which is a primary reason to migrate off TLS 1.2.

Does HIPAA require healthcare providers to encrypt all electronic patient data?

Short answer: In the US, HIPAA's Security Rule treats encryption as an "addressable" specification rather than a strict requirement, meaning covered entities must either implement it or document why an equivalent safeguard is in place. In practice, most legal and compliance experts treat encryption as mandatory because a post-breach justification is very difficult to defend. For Canadian providers, PHIPA and PIPEDA apply the "reasonable safeguards" standard instead, and Ontario regulators have found organizations non-compliant when encrypted alternatives were available and not used. Canadian healthcare platforms should treat encryption as required in all cases.

For Canadian healthcare providers and healthtech platforms, HIPAA is a US regulation and does not apply directly. However, many Canadian organizations handling cross-border patient data or using US-based cloud infrastructure must understand both frameworks. Under PHIPA (Ontario) and PIPEDA (federal), there is no "addressable vs. required" distinction: custodians must implement safeguards proportionate to the sensitivity of the data. Because dermatology images combine photographic identity with clinical diagnosis, the sensitivity level is high, and encryption is a proportionate control.

How to keep patient data secure?

Short answer: Encrypting stored and transmitted data is the foundation, but complete patient data security also requires strict access controls, audit logging, regular vulnerability testing, staff training, and an incident response plan that satisfies PHIPA breach notification requirements. Encryption prevents unauthorized parties from reading data they obtain. Access controls prevent them from obtaining it in the first place. Audit logs prove who accessed what and when, which matters both for PHIPA compliance and for breach investigation. A program that combines all four layers substantially reduces both the likelihood and the impact of a breach affecting patient images.

Encryption alone does not prevent all breaches. A clinician with legitimate decryption access who clicks a phishing link can expose data without ever breaking the encryption. A complete healthcare data security program includes:

Role-based access controls so only clinicians treating a specific patient can decrypt their images
Immutable audit logs recording every access, export, and sharing event
Regular penetration testing and vulnerability scanning of the systems holding PHI
Staff training on phishing, physical security of devices, and PHIPA obligations
A documented breach response procedure covering PHIPA's 90-day notification window to the Information and Privacy Commissioner
Data minimization: do not store images longer than clinically necessary

Patients also have rights under PHIPA to request access to their own records and to know who has accessed their information. Building encryption into the system from the start, rather than retrofitting it, makes it far easier to demonstrate compliance when an audit or access request arrives.

Learn more about DermaDex's approach to privacy-first dermatology care.

Sources

Government of Canada. Online Security and Privacy. Government of Canada. canada.ca
Government of Canada. Health Canada. Health Canada. canada.ca
National Library of Medicine. Healthcare data security. PubMed, 2019. ref
National Institute of Standards and Technology. SP 800-111: Guide to Storage Encryption Technologies for End User Devices. NIST. csrc.nist.gov/pubs/sp/800/111/final