Encryption at Rest and in Transit for PHI

HIPAA lists encryption at rest and in transit for PHI as addressable, not required, under the Security Rule. Encrypting both is the simpler path, because HHS guidance treats properly encrypted PHI as "secured", which can remove the duty to notify after a loss. Storage, backups, uploads, exports and the keys themselves all need a plan.

Is encryption required by HIPAA or addressable?

Encryption is an addressable implementation specification under the HIPAA Security Rule, which means a covered entity or business associate must assess it and either adopt it or document why not. Two places in 45 CFR 164.312 on eCFR name it: one for stored data and one for data sent over a network.

The access control standard lists "Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information." The transmission security standard lists a second item: "Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate."

"Addressable" has a defined meaning. 45 CFR 164.306 on eCFR says that for an addressable specification an organization must assess whether it is "a reasonable and appropriate safeguard in its environment". If it is, the organization implements it. If it is not, the organization must document why and implement an equivalent alternative measure if that is reasonable and appropriate. Addressable does not mean optional, and it does not mean "skip it if it is hard".

The same section tells organizations what to weigh: their size and capabilities, their technical infrastructure, the cost of the measure, and the probability and criticality of the risks to electronic PHI. For encryption of stored documents and network traffic, the cost has fallen far enough that a written reason not to encrypt is hard to defend.

The stronger reason to encrypt comes from the breach rules. In the HHS breach notification interim final rule in the Federal Register, HHS wrote that a covered entity "may be in compliance with the Security Rule even if it reasonably decides not to encrypt". It then explained that PHI encrypted according to its guidance is not "unsecured", so a breach of that data does not trigger notification. Whether a lost encrypted device counts as a reportable breach is covered in the post on lost encrypted PHI and the reportable breach exception.

Encryption at rest for PHI: disks, databases and backups

Encryption at rest protects PHI that is stored, whether on a laptop disk, in a database, in a file store or on a backup tape. HHS guidance points to NIST Special Publication 800-111 as the reference for data at rest, and every layer that holds a copy of a document or its extracted fields needs its own answer.

HHS defined the scope of "data at rest" in that 2009 rule: data "that resides in databases, file systems, flash drives, memory, and any other structured storage method." For a document workflow, that covers more places than people first list. The scanned PDF sits in a file store. The extracted fields sit in a database. A review queue holds both. Exports land on someone's desktop, and backups copy all of it again.

The 2009 guidance says valid encryption processes for data at rest "are consistent with NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices." The NIST SP 800-111 page on the CSRC site describes three kinds of solution: full disk encryption, volume and virtual disk encryption, and file or folder encryption. As its title says, it was written for end user devices such as laptops, phones and removable media. HHS noted at the time that guidance for enterprise storage would be considered when NIST produced it.

A practical reading for a billing team or a vendor looks like this:

• Laptops and workstations. Full disk encryption on every device that can open a scanned EOB or intake form, including the one at the front desk.
• Removable media. Encrypted volumes, or a rule that PHI never goes onto a USB drive.
• Databases and file stores. Encryption at the storage layer, plus field or file encryption for the most sensitive data where the platform supports it.
• Backups. Encrypted with keys that are kept apart from the backup media, so a stolen tape is unreadable.

Physical media also needs an end of life. 45 CFR 164.310 on eCFR makes disposal and media re-use required specifications, so a decommissioned drive must have its PHI removed or be destroyed.

Encryption in transit for PHI: TLS, SFTP and uploads

Encryption in transit protects PHI while it moves over a network: a browser upload, a file transfer between systems, an API call or an email. HHS guidance names NIST SP 800-52, the NIST guidance on Transport Layer Security (TLS), among the references for data in motion, and every hop a document or extracted field takes needs encryption.

The 2009 rule says "data in motion" includes data moving through a network, "including wireless transmission, whether by e-mail or structured electronic interchange". Its guidance lists valid processes as those that comply, as appropriate, with NIST Special Publications 800-52 for TLS, 800-77 for IPsec VPNs, or 800-113 for SSL VPNs, or others which are FIPS 140-2 validated.

The current version is SP 800-52 Revision 2. The NIST SP 800-52 Rev. 2 page on the CSRC site says it requires TLS 1.2 configured with FIPS-based cipher suites on all government TLS servers and clients, and support for TLS 1.3 by January 1, 2024. Those requirements apply to federal systems, but they give a private organization a clear, published baseline to configure against.

For a document workflow, the hops are usually these:

• Upload. A scanner, fax server or person sends files to a processing service over HTTPS.
• System to system. Files move by SFTP or over an API protected by TLS.
• Review. A reviewer's browser loads the page image and the extracted fields over HTTPS.
• Export. Results go back to a billing system or EHR, again over an encrypted channel.

Integrity matters on the same hops. The transmission security standard in 164.312 also lists integrity controls as addressable, so a team should be able to tell when a file changed on the way.

Where PHI sits and moves, with a way to check each one

This table is an example worksheet for one billing office. The methods are common choices, not requirements, and each team should fill in its own.

Schema Care's homepage compliance list gives the status of its encryption item as "In the design", covering "All files and extracted fields, including review queues and exports."

Who holds the encryption keys for PHI?

Encryption keys decide who can turn stored PHI back into readable text, so key ownership matters as much as the cipher. HHS guidance says encrypted PHI counts as secured only if the key has not been breached, and it advises keeping decryption tools on a device or at a location separate from the data.

The exact wording in the 2009 rule is that the "confidential process or key that might enable decryption" must not have been breached, and that "these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt." A laptop with full disk encryption and the password on a sticky note fails this test. So does a backup drive stored in the same bag as the key file.

For software services, key questions fall into three groups:

• Where the keys live. In a separate key management service, in hardware security modules, or beside the data.
• Who can use them. Which staff and which systems can request decryption, and whether each use is logged.
• How they rotate and retire. What happens to old keys, and whether destroying a key is part of deleting data.

Data isolation for health data is the other half of key ownership. When one company runs several products, PHI should sit in storage that the other products cannot reach, ideally encrypted with keys of its own. A compromise of one product then does not hand over the keys to another. Schema Care's homepage lists "Isolated storage for health data" with the status "In the design" and the detail that Schema Care data "lives apart from our tax and accounting products, with its own keys."

Keys also connect to access control. Encryption at rest only protects data from people who do not hold a key or a session that can use one. Who gets those sessions is the subject of the post on access controls for PHI, and recording each use belongs to audit logs under HIPAA.

PHI in email and fax: where encryption in transit breaks down

Email and fax are the two channels where encryption in transit for PHI most often lapses, because the sender rarely controls every hop. A message can be encrypted from your server to the next one and still travel in plain text later, and a fax can land on a shared machine in an open office.

Email is in scope. The HHS rule names e-mail as data in motion, so the transmission security standard applies to it. A secure message portal, where the recipient signs in to read the message over HTTPS, keeps the content on one encrypted path. Whatever method a team chooses, it should write down why that method is reasonable for the PHI it sends.

Fax is harder to describe in encryption terms. A traditional fax travels over the phone network and prints on paper, so the risks are a wrong number and an unattended tray rather than an unencrypted packet. An eFax service turns the fax into an image that is stored and delivered over the internet, which brings it back under encryption at rest and in transit. The differences between the two setups are covered in eFax vs a fax server in healthcare.

A few habits close most of the gaps:

• Send PHI by secure portal or encrypted message rather than ordinary email when the recipient's setup is unknown.
• Send only the pages the recipient needs.
• Treat each eFax mailbox as a data store with its own encryption and access settings.
• Delete local copies of attachments and fax images after they are filed.

Each of these is a judgment the Security Rule leaves to the organization, so the written risk analysis should record the choice and the reason for it.