Building HIPAA-compliant software - #ONE
Software development organizations that deal with Protected Health Information (PHI) and/or Electronic Protected Health Information (e-PHI) in the US must take time to understand the Health Insurance Portability and Accountability Act (HIPAA). Even if you are not in the US, it still makes sense to understand the asks of this Act as it helps build systems that will be resilient to external threats and worthy of the trust that individuals put in them.
This post focuses on a high-level overview of the Act itself and includes a short reference checklist to understand what you need to know to get started in case you are in scope of this Act's compliance requirements. In a subsequent post, we will cover what a developer needs to keep in mind to ensure that the product they build is compliant.
Overview
HIPAA was enacted in 1996 to protect the privacy and security of patient's health information (PHI) and to ensure that it is properly handled and maintained. The act requires that all entities that handle PHI, including software development houses, comply with a set of standards and requirements known as the HIPAA Privacy, Security, and Breach Notification Rules.
One of the key things that software developers must understand about HIPAA is that it requires that all PHI be kept confidential and secure. As they analyze, design and build systems, and developers must take appropriate steps to protect PHI from unauthorized access, theft, loss, or misuse. This may involve implementing encryption, access controls, audit trails, and other security measures to ensure that PHI is kept secure both in transit and at rest.
Another important aspect of HIPAA that software developers must understand is that it requires that PHI only be used and disclosed for lawful purposes. This means that software developers must understand the types of uses and disclosures of PHI permitted under HIPAA and ensure that their software solutions are designed and implemented in a way that complies with these requirements.
To stay compliant with HIPAA, software developers must also understand the importance of regular security risk assessments and implement appropriate remediation measures in response to identified vulnerabilities. This may involve implementing software patches, updating security policies and procedures, or making other changes to the software solution as needed to maintain compliance with HIPAA.
Reference HIPAA considerations for Architects and Developers - part 1
1) First, determine if the system that you are working on is a “Covered Entity” under HIPAA.
A "Covered Entity" under HIPAA is a type of organization that must comply with the standards and requirements of the Health Insurance Portability and Accountability Act (HIPAA). Covered Entities are defined as:
Health Care Providers: This includes any individual or organization that provides medical or other health services, such as doctors, hospitals, clinics, nursing homes, and mental health facilities.
Health Plans: This includes any individual or organization that provides or pays for the cost of medical care, such as health insurance companies, health maintenance organizations (HMOs), and government programs like Medicare and Medicaid.
Healthcare Clearinghouses: This includes any entity that processes nonstandard health information it receives from another entity into a standard (e.g., electronic) format or vice versa.
2) You have documented Privacy Rule policies and procedures
Summary of the Privacy Rule from HHS: https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html
3) Your system has a Notice of Privacy Practices that you support within the software you are building or has complimentary controls outside the system being built that will provide an equivalent or more compliance.
4) You can attest that your Privacy Rule policies and procedures being followed
What this means is that:
Users receive a Notice of Privacy Practices.
There are means to consider all requests for restrictions
All access and amendment requests are handled in a timely and auditable process
The system has provisions that support the release of only the minimum necessary amount of PHI (Protected Health Information) as-needed unless the patient has authorized the release of the entire record.
5) The Security Rule policies and procedures are documented and enforceable using the system
The Security Rule requires covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting e-PHI.
Specifically, covered entities must:
Ensure the confidentiality, integrity, and availability of all e-PHI they create, receive, maintain or transmit;
Identify and protect against reasonably anticipated threats to the security or integrity of the information;
Protect against reasonably anticipated, impermissible uses or disclosures; and
Ensure compliance by their workforce.
6) Security Rule policies and procedures are enforceable via Administrative, Physical, and Technical Safeguards
During the design of the system that will process PHI data, strongly consider controls that enforce:
Access Control. A covered entity must implement technical policies and procedures that allow only authorized persons to access electronically protected health information (e-PHI),
Audit Controls. A covered entity must implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use e-PHI.
Integrity Controls. A covered entity must implement policies and procedures to ensure that e-PHI is not improperly altered or destroyed. Electronic measures must be implemented to confirm that e-PHI has not been improperly altered or destroyed.
Transmission Security. A covered entity must implement technical security measures that guard against unauthorized access to e-PHI transmitted over an electronic network. Read more: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
We will continue exploring the checklist and what needs to be done to meet the technology safeguards in a followup post.