Privacy Issues in Email
First, the technology used to communicate via e-mail is extraordinarily analogous to a telephone conversation. Indeed, e-mail is transmitted from one computer to another via telephone communication, either hard line or satellite. We have recognized that “[t]elephone conversations are protected by the Fourth Amendment if there is a reasonable expectation of privacy.” United States v. Sullivan, 42 MJ 360, 363 (1995).
E-mail transmissions are not unlike other forms of modern communication. We can draw parallels from these other mediums. For example, if a sender of first-class mail seals an envelope and addresses it to another person, the sender can reasonably expect the contents to remain private and free from the eyes of the police absent a search warrant founded upon probable cause. Cf. Gouled v. United States, supra. However, once the letter is received and opened, the destiny of the letter then lies in the control of the recipient of the letter, not the sender, absent some legal privilege. See Mil.R.Evid. 501-06, Manual for Courts-Martial, United States, 1984. Cf. Gouled v. United States, 255 U.S. at 302.
The fact that an unauthorized “hacker” might intercept an e-mail message does not diminish the legitimate expectation of privacy in any way. Expectations of privacy in e-mail transmissions depend in large part on the type of e-mail involved and the intended recipient U.S. v Maxwell
Standard Reply from Covered CA
Under the US Health Insurance Portability and Accountability Act (HIPAA), PHI that is linked based on the following list of 18 identifiers must be treated with special care:
- All geographical identifiers smaller than a state, except for the initial three digits of a zip code if, according to the current publicly available data from the Bureau of the Census: the geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and the initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000
- Dates (other than year) directly related to an individual
- Phone numbers
- Fax numbers
- Email addresses
- Social Security numbers
- Medical record numbers
- Health insurance beneficiary numbers
- Account numbers
- Certificate/license numbers
- Vehicle identifiers and serial numbers, including license plate numbers;
- Device identifiers and serial numbers;
- Web Uniform Resource Locators (URLs)
- Internet Protocol (IP) address numbers
- Biometric identifiers, including finger, retinal and voice prints
- Full face photographic images and any comparable images
- Any other unique identifying number, characteristic, or code except the unique code assigned by the investigator to code the data Learn More==> Wikipedia
This is information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other personal or identifying information that is linked or linkable to a specific individual.
Microsoft Trust Center – Explanation of HIPAA and HITECT Act
Currently there is no official certification for HIPAA or HITECH Act compliance. However, those Microsoft services covered under the BAA have undergone audits conducted by accredited independent auditors for the Microsoft ISO/IEC 27001 certification.
How can I learn more about complying with HIPAA and the HITECH Act?
To assist customers with this task, Microsoft has published these guides:
HIPAA/HITECH Act Implementation Guidance for Azure and for Dynamics 365 and Office 365. Written for privacy, security, and compliance officers and others responsible for HIPAA and HITECH Act implementation, they describe concrete steps your organization can take to maintain compliance.
Using a service that claims (at least that reasonably claims) to be HIPAA-compliant could potentially insulate you, to some degree, from liability in the event of a breach. Their Terms (and the included “disclaimer”) leave something to be desired:
“8.2 For breach of the express warranty set forth above, Customer’s exclusive remedy shall be the re-performance of the deficient Services. If Paubox cannot re-perform such deficient Services as warranted, Customer shall be entitled to recover a pro-rata portion of the fees paid to Paubox for such deficient Services, and such refund shall be Paubox’s entire liability.”
Of course, it isn’t unreasonable to believe that a judge might choose to throw out that provision if they were ever hauled into court. After all, claiming to provide a service and then explicitly disclaiming any duty to provide that very service is at least questionable.
I also cannot say that I am fond of section 8.5:
“8.5 Customer shall defend at its expense any Claim brought against Paubox alleging that Customer Data, or Customer’s use of the Services in violation of this Agreement, infringes the intellectual property rights of, or has otherwise harmed, a third party or violates any law or regulation, and Customer shall pay all costs and damages finally awarded against Paubox by a court of competent jurisdiction as a result of any such Claim; provided that Paubox (i) promptly gives written notice of the Claim to Customer; (ii) gives Customer sole control of the defense and settlement of the Claim (provided that Customer may not settle or defend any Claim unless it unconditionally releases Paubox of all liability); and (iii) provides to Customer, at Customer’s cost, all reasonable assistance.”
The foregoing notwithstanding, I am insufficiently familiar with the provisions of HIPAA to know what precisely is required in terms of security, but, again, contracting the services of a reputable company that claims to provide HIPAA compliance is likely insulation against at least a claim that you were negligent in your handling of confidential information.
As for the technology of Paubox, it seems they are simply enforcing SSL/TLS use on their IMAP/SMTP services and additionally providing detection of whether or not the recipient servers do the same. If the recipient servers do not provide SSL/TLS, then a plaintext email is sent instead of the actual email and that plaintext email has a link to the actual email, which will be delivered over a secure link.
From a technology standpoint, this provides no additional benefits. From a legal standpoint, that may not matter. paubox.com/terms
Fundamentally, the problem with using email as a ‘secure’ means of communication is that email was not designed to be secure. Email is, in fact, never secure. You can secure the content of an email, but you cannot secure the email itself.
In general, I would not suggest sending sensitive data via email. There are simply too many security risks (and those risks are ongoing as emails are often retained for weeks, months, or even years after they are sent). A far better solution is to use a secure-messaging system of some kind (for client matters, something hosted on your own site would probably be optimal as that keeps everything under your control and under your brand).
WordPress can serve as a platform for delivering files and such securely. The easiest way to accomplish this would probably be a client portal (e.g., xxx/) and a page for each client (e.g., hxxx). You could then add files to the client page that only the client would be able to access (either via account-based permissions or a simple password), and incorporate an upload form so that the client could securely send you files.
For the sake of completeness:
- Generating and installing a certificate in your email client provides some security, but in order for such a setup to provide encryption, the client would also need to obtain a certificate (and you would need to send an initial email to establish the ability of your clients to communicate using encryption). Another drawback to this setup is that you would need to install the certificate on every device you use and your emails would become inaccessible if you should happen to lose the certificate.
- Encrypting the content prior to transmission (e.g., with GPG) and then sending the encrypted data will secure your information. However, the client will need to have similar facilities to decrypt the information and you will need to provide your public key in advance. Most users are not sufficiently technically savvy for this option to be viable.
Related Pages in Privacy – HIPAA Section