HIPAA Support
DISCLAIMER: The
platform does not guarantee HIPAA compliance. It is up to each developer to create and deploy applications that adhere to any applicable regulatory requirements like HIPAA. Below are some suggested steps for configuring with HIPAA in mind. These suggestions are not intended to be complete nor represented to be up to date. Users should refer to the latest standards provided by the U.S. Department of Health & Human Services.
Developers should have adequate test plans to confirm that all features required for HIPAA compliance, e.g., auditing/logging, function correctly within their specific deployment environment.
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a US federal law that governs many aspects of health insurance portability and health data exchange. One component of the law, the Administrative Simplification portion (under Title II) is broken down into several rules, including the Privacy Rule and the Security Rule, which describe how we limit Protected Health Information (PHI) from a privacy and security perspective.
The HHS.gov page for Professionals has the standards for the HIPAA Privacy and Security Rules that need to be followed by covered entities and business associates. The Privacy Rule protects all "individually identifiable health information" held or transmitted by a covered entity or its business associate, in any form or media, whether electronic, paper, or oral. The Security Rule requires covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting electronic PHI (ePHI). These restrictions do not apply to de-identified health information.
Any covered entity deploying the
Risk Analysis (§ 164.308(a)(1)(ii)(A))
The Risk Analysis implementation specification requires covered entities to "Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity."
In order to fulfill the Risk Analysis HIPAA requirement, the
Technical Safeguards (§ 164.312)
The Security Rule defines technical safeguards in § 164.304 as "the technology and the policy and procedures for its use that protect electronic protected health information and control access to it."
ACCESS CONTROLS (§ 164.312(a)(1))
The Security Rule defines access in § 164.304 as "the ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource. (This definition applies to "access" as used in this subpart, not as used in subpart E of this part [the HIPAA Privacy Rule])." Access controls provide users with rights and/or privileges to access and perform functions using information systems, applications, programs, or files. Access controls should enable authorized users to access the minimum necessary information needed to perform job functions.
The Minimum Necessary Requirement is meant to limit unnecessary or inappropriate access to and disclosure of protected health information.
The principle of least privilege needs to be applied to both the application and the PHI stored by theUNIQUE USER IDENTIFICATION (Required) - (§ 164.312(a)(2)(i))
The Unique User Identification implementation specification states that a covered entity must: "Assign a unique name and/or number for identifying and tracking user identity."
The
Access control to microservices can be configured using the
EMERGENCY ACCESS PROCEDURE (Required) - (§ 164.312(a)(2)(ii))
This implementation specification requires a covered entity to: "Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency."
A covered entity needs to define emergency procedures covering applications built using
AUTOMATIC LOGOFF (Addressable) - (§ 164.312(a)(2)(iii))
Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must: "Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity."
Any application user interface built using
ENCRYPTION AND DECRYPTION (Addressable) - (§ 164.312(a)(2)(iv))
Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must: "Implement a mechanism to encrypt and decrypt electronic protected health information."
PHI data at rest needs to be encrypted and retained following the covered entity's data retention requirements. There is no HIPAA data retention requirement, but each covered entity and business associate needs to minimally follow their jurisdiction's data retention requirements.
AUDIT CONTROLS (§ 164.312(b))
The Audit Controls standard requires a covered entity to: "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."
Applications, including those implemented using
For access to patient data stored in internal databases:
Existing audit standards include the IHE-ATNA Audit record definitions, originally from RFC 3881, and now managed by DICOM (see DICOM Part 15 Annex A5).
Additional info can be found in HL7's Security and Audit Tutorial.
ASTM E2147 – Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems. This is deprecated but contains a good summary of data considered standard for audit events.
- Audit Log Content
7.1 Audit log content is determined by regulatory initiatives, accreditation standards, and principles and organizational needs. Information is needed to adequately understand and oversee access to patient identifiable data in health information systems in order to perform security oversight tasks responsibly.
Logs must contain the following minimum data elements:
7.2 Date and Time of Event
7.3 Patient Identification
7.4 User Identification
7.5 Access Device (optional)
7.6 Type of Action (additions, deletions, changes, queries, print, copy)
7.7 Identification of the Patient Data that is Accessed(optional)
7.8 Source of Access (optional unless the log is combined from multiple systems or can be indisputably inferred)
7.9 Reason for Access (optional)
7.10 If capability exists, there should be recognition that both an electronic "copy" operation and a paper "print" operation are qualitatively different from other actions.
See http://build.fhir.org/auditevent.html for a data model.
INTEGRITY (§ 164.312(c)(1))
The Integrity standard requires a covered entity to: "Implement policies and procedures to protect electronic protected health information from improper alteration or destruction."
MECHANISM TO AUTHENTICATE ELECTRONIC PROTECTED HEALTH INFORMATION (Addressable) - (§ 164.312(c)(2))
Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must: "Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner."
PERSON OR ENTITY AUTHENTICATION (§ 164.312(d))
This standard requires a covered entity to: "Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed."
TRANSMISSION SECURITY (§ 164.312(e)(1))
This standard requires a covered entity to: "Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network."
Any application built using
INTEGRITY CONTROLS (Addressable) - (§ 164.312(e)(2)(i))
Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must: "Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of."
ENCRYPTION (Addressable) - (§ 164.312(e)(2)(ii))
Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must: "Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate."