HIPAA Compliance for Health Tech Companies

To help protect patient privacy and protect personal identifiable information from fraud and theft, Congress created the Health Insurance Portability and Accountability Act (HIPAA) in 1996. The HIPAA Security Rule, published by the Department of Health and Human Services, places standards on covered entities, which include health care providers, health plans, and health care clearinghouses.

These regulations also expand to independent contractors of a covered entity—known as business associates—via a business associate agreement. Failure to comply with the HIPAA privacy and security rules could subject an organization to fines from the Office for Civil Rights (OCR).

This article provides a broad overview of the HIPAA Security Rule compliance for health tech companies, including best practices and suggestions on how to implement security standards, and their implementation specifications that address administrative, physical, and technical safeguards required to protect patient privacy under the law.

SECURITY STANDARDS & IMPLEMENTATION SPECIFICATIONS

The Security Rule has 22 security standards divided into the categories of administrative safeguards, physical safeguards, technical safeguards, organizational requirements, policies and procedures, and documentation requirements. These standards may contain one or more implementation specifications which are detailed instructions for a standard. These implementations are either required or addressable.

In this article, required implementations are denoted by an (R) next to them, meaning the covered entity must implement it. Addressable standards, denoted by an (A) next to them, must be assessed by the covered entity if it's appropriate. If the covered entity does not think the addressable standard is a reasonable safeguard, it must document their decision and potentially implement an equivalent measure.

ADMINISTRATIVE SAFEGUARDS - § 164.308

Security Management Process - § 164.308(a)(1)

Risk Analysis (R). A risk analysis must be performed to determine potential security risks, the probability of them occurring, and the severity. To do this, all electronic protected health information (ePHI) must be identified in the organization's systems.

One suggestion is to standardize the information in a Word document that the management team, operation team, and development team can all reference. This ensures everyone is on the same page and the legal team can sign-off on it. It's especially helpful since developers new to health care—and even some experienced executives—don't realize protected health information (PHI) is quite broad.

PHI is defined in §160.103 as individually identifiable health information that relates to:

• Demographic data

• An individual's past, present or future physical/mental condition

• The provision of health care to the individual

• Any past, present, or future payment for the provision of health care to the individual

For example, this means things such as cell phone numbers and email addresses are considered PHI when used by a covered entity as it identifies the individual.

Risk Management (R). While the previous implementation specification says a risk analysis must be performed, here the covered entity must make decisions to proactively manage these risks. While risks cannot be fully eliminated, the goal is to lower the chance of a breach to an acceptable level. For example, many covered entities require third-party administrators to access their system with provisioned emails—this is a security measure that would slot under risk management.

Sanction Policy (R). Covered entities must have sanctions in place for workforce members who fail to comply with security policies and procedures. A sanction could be a letter of reprimand written to the employee, unpaid suspension, termination, etc. It's up to the covered entity to decide what the appropriate procedures are and how they escalate for repeat infractions.

Information System Activity Review (R). Covered entities must have sanctions in place for workforce members who fail to comply with security policies and procedures. A sanction could be a letter of reprimand written to the employee, unpaid suspension, termination, etc. It's up to the covered entity to decide what the appropriate procedures are and how they escalate for repeat infractions.

This implementation specification is for the actual procedure. The more technical aspects are addressed under Information Access Management. See § 164.308(a)(4).

Assigned Security Responsibility - § 164.308(a)(2)

An individual, called the Security Official, needs to be assigned the responsibility of ensuring the covered entity or the business associate complies with the Security Rule. This person can be the same as the Privacy Official, as outlined in the HIPAA Privacy Rule. See §164.530(a)(1).

The role can be assigned to a technical leader in the organization, usually a CIO or CTO. The individual should be someone high enough in the company to push back against other executives, as sometimes security procedures can slow down operations, but are necessary to protect against a breach. Depending on the size of the organization, it might also be assigned to a third-party contractor.

Workforce Security - § 164.308(a)(3)

Authorization and/or Supervision (A). There must be procedures to ensure that workforce members who access PHI have been authorized to do so and have proper supervision. In software terms, this is accomplished by setting up role-based access to various systems that follows the Principle of Least Privilege. This means people are only given access to information required to complete their job, and nothing more. Thus, if a breach happens on an account, the overall impact is limited.

Workforce Clearance Procedure (A). Usually, this is lumped into the previous implementation specification.

Termination Procedures (A).Covered entities need to implement procedures that remove some or all employee access to PHI when necessary. While this mostly relates to a person leaving or being fired, it can also result from someone receiving a promotion. For example, someone can be promoted and no longer need access to PHI to perform their job.

The main problem with this specification is with covered entities communicating the access change to their IT department. As such, it is suggested that covered entities create an action item in their IT ticketing platform that communicates access changes to the IT department and creates a record.

Information Access Management - § 164.308(a)(4)

Isolating Health Care Clearinghouse Functions (R). A health care clearinghouse takes nonstandard data elements of health information and translates it into standard data elements. This implementation specification states that health care clearinghouses must put in place policies and procedures to ensure the rest of the health care organization cannot access it.

In technical terms, the health care clearinghouse usually sets up its infrastructure as if it were a separate company. This means implementing firewalls, networks, and procedures that separates the clearinghouse from the rest of the organization. This only applies to those massive organizations that own a health care clearinghouse.

Access Authorization (A) and Access Establishment and Modification (A). These are almost always covered by the procedures and policies defined in a workforce security standard. See § 164.308(a)(3).

Security Awareness and Training - § 164.308(a)(5)

Security Reminders (A). Covered entities need periodic security updates. One suggestion is to have a monthly meeting led by the security official along with relevant parts of the IT department.

Protection from Malicious Software (A). Covered entities need a procedure to protect against malicious software. While ransomware is a large threat to companies, it's relatively rare. It is more common for employees to download viruses from interacting with the internet or through email. As such, a best practice is for all employee workstations to have antivirus software installed even if they don't interact with ePHI.

Log-In Monitoring (A). All IT systems should have an audit log of access to the system. On top of this, it's good practice that if a user fails to login after a certain number of attempts, they are locked out in increasing time increments. This helps protect IT systems against brute force attacks. Any suspicious activity should be automatically flagged and then reviewed via the Information System Activity Review Standard. See § 164.308(a)(1)(ii)(D).

Password Management (A). Covered entities must have good procedures for creating, changing, and safeguarding passwords. For example, do not allow employees to keep sticky notes with their passwords written down.

On the IT side, it's a common misconception that organizations need to force users to update passwords every month. This is not the case—it makes systems less secure, not more. The National Institute of Standards and Technology (NIST), which develops federal information processing standards that all federal agencies must follow, realized in 2021 that password rotation wasn't necessary and thus dropped the requirement.

It's critically important to design passwords correctly. One suggestion is that developers follow best practices for passwords set by the Open Web Application Security Project (OWASP), as it is considered the gold standard for security. Some of their requirements include:

• The password must be at least eight characters long

• Setting a maximum password length, usually 64 characters due to limits in certain hashing algorithms

• Allow usage of all characters including Unicode and spaces

Security Incident Procedures - § 164.308(a)(6)

Response and reporting (R). Covered entities need procedures to address security incidents and report them to the appropriate person. The Security Rule defines a security incident as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an informative system. Anytime a security incident happens it needs to be documented and mitigated according to the procedure defined in this specification.

Contingency Plan - § 164.308(a)(7)

Data Backup Plan (R). Organizations need the ability to retrieve data backups. This is very easy to do in modern software, sometimes with only a couple of clicks. However, health care organizations hit with ransomware attacks are often forced to pay to recover their data. Why? Because developers commonly make two critical mistakes with backups.

The first is that developers don't test whether the backup works. It's one thing to have a backup, it's another to have a backup that can be deployed into production. The second is that developers don't put the backup on a separate network along with its own unique credentials. If the backup is on the same network as production, then a ransomware attack that compromises production will also compromise the backup.

For extra security, covered entities could follow the 3-2-1 backup strategy where there are three data copies: two onsite— i.e., cloud, and one offsite —i.e., physical. While it may be less than ideal to have a physical copy if it contains PHI—which adds lots of physical safeguards required by HIPAA—it's sometimes necessary for critical systems

Disaster Recovery Plan (R).If done right, the previous implementation standard will cover this.

Emergency Mode Operation Plan (R). Covered entities need a plan of action due to a technical failure, power outage, or an environmental issue like an earthquake.

Testing and Revision Procedures (A). Covered entities need to review procedures and contingency plans periodically. This is covered by the Evaluation standard. See § 164.308(a)(8).

Application and Data Criticality Analysis (A). In a critical failure the covered entity must have a plan on what systems to restore first.

Evaluation - § 164.308(a)(8)

Covered entities and their business associates need to perform a technical and nontechnical evaluation on these HIPAA standards—a Security Risk Assessment (SRA)—which should be performed on a yearly basis. To do this, covered entities and their business associates can use the tool created by the Office of the National Coordinator for Health Information Technology (ONC), an SaaS platform, or do it themselves on a spreadsheet.

Most software development firms that have a business associate agreement signed with a covered entity forget to have a yearly SRA performed. Covered entities that fail to perform their SRAs on a timely basis risk falling out of compliance with HIPAA.

Business Associate Contracts & Other Arrangements - § 164.308(b)(1)

Written Contract or Other Arrangement (R). A business associate agreement is required for every third-party vendor or subcontractor to deal with ePHI from a covered entity. While that part is straightforward, most business associate agreements struggle with failing to secure a corresponding business associate agreement with their vendors or subcontractors.

Think of PHI as a chain of custody: the covered entity is responsible for a business associate agreement with their vendor, then it's the vendor's responsibility to ensure their own business associate agreements are properly in place with their own vendors. These are known as downstream business associate agreements.

It is therefore especially important to have a software development firm that specializes in health care development. It takes a lot of rigor to ensure that anywhere PHI touches in a system, it is properly covered by a business associate agreement and to know which vendors have it. For example, some business messaging apps will not sign a business associate agreement unless the customer upgrades their account to a high enough service tier and the program is correctly configured.

PHYSICAL SAFEGUARDS - § 164.310

Covered entities must implement physical measures and policies to protect their PHI. When software and data is located on-site, these safeguards are primarily implemented by the covered entity. When software and data is hosted on the cloud, the cloud vendor does most of the heavy lifting. Major cloud providers have most of these physical safeguards built in. Though most cloud vendors don't provide HIPAA-compliance out of the gate, they do publish whitepapers on how to do so.

Facility Access Controls - § 164.310(a)(1)

Contingency Operations (A). During an Emergency Mode Operation Plan there needs to be a procedure in place to allow an authorized person to come in and restore the systems with ePHI. See § 164.308(a)(7)(ii)(C).

Facility Security Plan (A). Covered entities need policies to prevent unauthorized access to facilities and equipment. These policies commonly manifest themselves in the form of self-locking doors, surveillance cameras, alarm systems, personnel being required to always wear a badge, and private security guards.

Access Control and Validation Procedures (A). Covered entities need polices to validate a person's access to the facilities. These policies usually involve a picture ID being verified before visitors are given access to the building. For example, an on-site visitor would be signed in, given a special badge, and escorted by an authorized person. This is similar to the Workforce Security standard, albeit in the physical realm. See § 164.308(a)(3).

Maintenance Records (A). Covered entities need documentation on when physical safeguards change. For example, when an individual has left the organization, their keycard access needs to be revoked.

Workstation Use & Security - § 164.310(b) & § 164.310(c)

Covered entities need policies related to workstation use. For example, it's a good practice to have workstations protected by a PIN, auto-logout after a set inactivity time, and antivirus software installed on machines. Due to the prevalence of remote work, most workstations use a virtual private network (VPN) to access company systems. This reduces risk substantially as getting PHI on a local machine results in a myriad of compliance issues and makes the data harder to track.

Device & Media Controls - § 164.310(d)(1)

Disposal (R). Policies must be put in place to dispose of hardware that once stored PHI. It is highly suggested that all covered entities never allow PHI on local machines and only stores such data with reputable cloud vendors.

Media Re-Use (R). Policies must be put in place to remove ePHI before workstations are available for reuse. If covered entities do have physical infrastructure storing PHI, it needs to be completely wiped before repurposing.

Accountability (A). Covered entities need to keep track of the location of all hardware containing ePHI.

Data Backup and Storage (A). Covered via the Data Backup Plan implementation specification. See (§ 164.308(a)(7)(ii)(A).

TECHNICAL SAFEGUARDS - § 164.312

Access Control - § 164.312(a)(1)

Unique User Identification (R). Each user that accesses the system must have a unique identifier—usually in the form of a username or email—and the activity needs to be logged in the system. It's best practice to record the user identifier, IP address, action performed, and sign-off for a full capture of what actions a user has performed.

Emergency Access Procedure (R). Covered by Emergency Mode Operation Plan implementation specification. See § 164.308(a)(7)(ii)(C).

Automatic Logoff (A). All systems with access to PHI must auto-logout after a set time of inactivity. This includes mobile apps and websites that access PHI. The actual timeframe is up to the company to decide.

Encryption and Decryption (A). ePHI needs to be properly encrypted. There are two types of encryption every system should have: encryption at rest and encryption at transit.

Encryption at rest means the data is encrypted on the drive. On cloud platforms, it's usually one click. This means even if someone gets the original hardware, they won't be able to access it by scanning the device without the decryption key.

Encryption at transit means that data is always transmitted in an encrypted form. This protects from public Wi-Fi or man-in- the-middle attacks.

On top of this, ensure that passwords are always encrypted. Developers should never store p in plain text—passwords must always be salted and hashed. Technically this only matters if the infrastructure has a breach. Failing to encrypt passwords on a database is inviting trouble.

Audit Controls - § 164.312(b)

There needs to be hardware, software, and physical mechanisms to examine activity in systems that have ePHI. This standard has been implemented in other various implementation specifications and is reviewed as part of the Information System Activity Review implementation specification. See § 164.308(a)(1)(ii)(D).

Integrity - § 164.312(c)(1)

Mechanism to Authenticate Electronic Protected Health Information (A). This implementation specification says ePHI may not be altered or destroyed in an unauthorized manner. This usually happens by accidental corruption when copying large amounts of data between systems. As such, a checksum can be performed to guarantee that the content was not accidentally modified.

Person or Entity Authentication - § 164.312(d)

To access a system the user must use something unique to them, such as an ID card, password, PIN, or biometric.

Transmission Security - § 164.312(e)(1)

Integrity Controls (A). Covered by the Encryption and Decryption implementation specification. See § 164.312(a)(2)(iv).

Encryption (A). At first glance, this looks like it's covered by the Encryption and Decryption implementation specification by encrypting data in transit via always forcing HTTPS. However, it's slightly different. This specification is about implementing encryption on any ePHI when deemed appropriate. For example, the organization can choose to use encrypted email services if it thinks it will lower overall risk.

Hopefully, the above guide provides a kick-start on a conversation with your clients to ensure they implement steps to become HIPAA-compliant. If they have developers with no health care expertise, work with generalist software firms, or use offshore development, they probably are not compliant and are running a substantial risk.