Skip to main content

HIPAA compliance

Prepare your deployment of Piiano Vault for HIPAA (Health Insurance Portability and Accountability Act of 1996)​

Background​

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a United States federal law. It required the creation of national standards to protect sensitive patient health information from being disclosed without the patient's consent or knowledge.

The Privacy Rule standards set out in the act address the use and disclosure of individuals' health information (known as protected health information or PHI) by entities subject to the Privacy Rule.

The Privacy Rule also contains standards for individuals' rights to understand and control how their health information is used. A major goal of the Privacy Rule is to ensure that individuals' health information is properly protected while allowing the flow of health information needed to provide and promote high-quality healthcare and to protect the public's health and well-being.

Piiano Vault and HIPAA​

Piiano Vault is designed to provide for the privacy and security requirements of sensitive data. As such, Vault can implement the security and privacy requirements of HIPAA. Therefore, Piiano Vault can help your organization minimize the effort needed to achieve compliance.

Deployment guide for Vault to comply with HIPAA​

Here are the main steps for planning HIPAA compliance with Piiano Vault. Throughout these steps, remember to document your progress and work according to your risk analysis. After each step, test your setup before proceeding to the next step.

  1. Analyze what data should be protected health information (PHI).
  2. Deploy Vault, starting with a blank schema.
  3. Design your data schema in Vault to support the PHI you intend to store. Create appropriate collections with the relevant properties.
  4. Understand the use cases for your PHI, and build appropriate controls:
    1. Which user will access the data?
    2. What are the access limitations for each collection and property?
    3. Consider access reasons for each use case, and build the policies accordingly.
    4. Build an IAM policy for data access.
    5. Plan for data de-identification using Vault's tokens and masks for relevant properties (e.g., Social Security Number).
  5. Collect Vault's audit log and store it according to your compliance requirements.
  6. Secure your installation of Vault.
  7. Start connecting your application to Vault's REST API.
  8. Monitor your installation of Vault using industry best practices, such as an application performance monitoring (APM) tool.

Technical requirements of HIPAA where Vault is applicable​

This section lists the HIPAA technical requirements and details how Piiano Vault helps your organization meet those requirements.

Security and privacy of data stored​

§ 164.312 safeguards. A covered entity or business associate must, in accordance with § 164.306: (a)(1) Standard: Access control. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4). (2) Implementation specifications: (i) Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity.

Vault implements a secure identifier for every person whose data is stored in Vault. This secure identifier is designed to not leak private data about that individual. This identifier can be used as a token in another database to reference the person's data in Vault.

(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information. and (e)(1) Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

Vault encrypts all private data by default and provides for transparent encryption and decryption by the application. Data is encrypted at rest and in transit.

Integrity of data and anti-tampering​

(c)(1) Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction. (2) Implementation specification: Mechanism to authenticate electronic protected health information (Addressable). Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.

Vault has built-in data signatures to verify that data has not been corrupted or altered. For example, if someone gained access to Vault's backing storage (e.g., AWS RDS) and changed a cell in a column, that modification would be detected by Vault and trigger an alert. A more extreme example: if someone exchanged the value of two cells, both independently valid but incorrect for their new records (e.g., switching the SSN of two patients), Vault would detect that modification.

Audit log requirements​

(b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

Vault provides an audit log. This log records all access to private data with all the details required by HIPAA. The audit log itself does NOT contain any private data. You can export the audit log in a standard format.

Disclosure of data​

§ 164.502 Uses and disclosures of protected health information: General rules.

This section of the act includes limitations on use of protected health infromation. Specifically, some uses and disclosures are allowed (e.g., for research purposes or when requires by a relevant government entity), while other uses are constrained, such as marketing or selling of data. Vault enables the reason for access to be specified in all API calls and included in the related audit log entry.

(f) Standard: Disclosures for law enforcement purposes. A covered entity may disclose protected health information for a law enforcement purpose to a law enforcement official if the conditions in paragraphs (f)(1) through (f)(6) of this section are met, as applicable. [...] (i) The covered entity may disclose only the following information: (A) Name and address; (B) Date and place of birth; (C) Social security number; (D) ABO blood type and rh factor; (E) Type of injury; (F) Date and time of treatment; (G) Date and time of death, if applicable; and (H) A description of distinguishing physical characteristics, including height, weight, gender, race, hair and eye color, presence or absence of facial hair (beard or moustache), scars, and tattoos. (ii) Except as permitted by paragraph (f)(2)(i) of this section, the covered entity may not disclose for the purposes of identification or location under paragraph (f)(2) of this section any protected health information related to the individual's DNA or DNA analysis, dental records, or typing, samples or analysis of body fluids or tissue.

Vault enables the reason for data access to be specified as part of all API requests. Vault identity and access management (IAM) provides for policies that control access to data types (e.g., blood type, SSN) based on the reason for accessing that data.

Data Minimization and de-identification​

(b) Standard: Minimum necessary (1) Minimum necessary applies. When using or disclosing protected health information or when requesting protected health information from another covered entity or business associate, a covered entity or business associate must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request.

and

(d) Standard: Uses and disclosures of de-identified protected health information. (1) Uses and disclosures to create de-identified information. A covered entity may use protected health information to create information that is not individually identifiable health information or disclose protected health information only to a business associate for such purpose, whether or not the de-identified information is to be used by the covered entity.

Vault assists in data minimization and de-identification with features that:

  • tokenize and mask (transform) data according to built-in or customizable rules.
  • limit data access using IAM policies. These policies can, for example, specify that users or uses are only allowed access to tokenized or transformed data. This means that Vault can guarantee that data access by a user or application is always a de-identified version of the data.

Also, Vault's audit log means that the organization's CISO or privacy officer can review any access to protected health information.

§ 164.514 Other requirements relating to uses and disclosures of protected health information. (a) Standard: De-identification of protected health information. Health information that does not identify an individual and with respect to which there is no reasonable basis to believe that the information can be used to identify an individual is not individually identifiable health information. [...] (2)(i) The following identifiers of the individual or of relatives, employers, or household members of the individual, are removed: [...] (A) Names

(B) All geographic subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except [...]

(C) All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; [...]

(D) Telephone numbers;

(E) Fax numbers;

(F) Electronic mail addresses;

(G) Social security numbers;

(H) Medical record numbers;

(I) Health plan beneficiary numbers;

(J) Account numbers;

(K) Certificate/license numbers;

(L) Vehicle identifiers and serial numbers, including license plate numbers;

(M) Device identifiers and serial numbers;

(N) Web Universal Resource Locators (URLs);

(O) Internet Protocol (IP) address numbers;

(P) Biometric identifiers, including finger and voice prints;

(Q) Full face photographic images and any comparable images; and

(R) Any other unique identifying number, characteristic, or code, except as permitted by paragraph (c) of this section;

Vault specifies the data type of each object property and, for each data type, the appropriate method for its tokenization, masking (transformation), anonymization, etc., to comply with HIPAA's requirements for de-identification.

Data ownership​

(g)(1) Standard: Personal representatives. As specified in this paragraph, a covered entity must, except as provided in paragraphs (g)(3) and (g)(5) of this section, treat a personal representative as the individual for purposes of this subchapter.

(b) Standard: Consent for uses and disclosures permitted. (1) A covered entity may obtain consent of the individual to use or disclose protected health information to carry out treatment, payment, or health care operations. (2) Consent, under paragraph (b) of this section, shall not be effective to permit a use or disclosure of protected health information when an authorization, under § 164.508, is required or when another condition must be met for such use or disclosure to be permissible under this subpart.

Coming soon 🎁: Vault stores consent as a part of its design, providing for:

  • access to data for a reason or purpose only with the relevant consent.
  • collecting ad-hoc consent from a person (e.g., using SMS). For example, customer support requesting permission to access patient information.

Data subject rights​

§ 164.524 Access of individuals to protected health information. (a) Standard: Access to protected health information. (1) Right of access. Except as otherwise provided in paragraph (a)(2) or (a)(3) of this section, an individual has a right of access to inspect and obtain a copy of protected health information about the individual in a designated record set, for as long as the protected health information is maintained in the designated record set

Vault supports various individual rights for data access, including data deletion and access. All data records in Vault can have an ownership relationship to a Person record. This means that extracting all related records is simple and straightforward when a person asks for their data. As Vault is designed with an API-first approach, the data is easily available in a machine-readable format.

For data deletion, using Vault's API to delete the record for a person deletes all the data owned by them. Together with Vault's life cycle and retention management, a compliant solution is easy to implement.

§ 164.526 Amendment of protected health information. (a) Standard: Right to amend. (1) Right to amend. An individual has the right to have a covered entity amend protected health information or a record about the individual in a designated record set for as long as the protected health information is maintained in the designated record set.

Similar to right of access, supporting the right to amend is straightforward. This is because Vault stores all of an individual's data centrally, where, with the appropriate permissions, it's easy to modify.

§ 164.528 Accounting of disclosures of protected health information. (a) Standard: Right to an accounting of disclosures of protected health information. (1) An individual has a right to receive an accounting of disclosures of protected health information made by a covered entity in the six years prior to the date on which the accounting is requested, except for disclosures:

Vault generates an audit log for all data access. This log includes the ID of the accessed data, the ID of the accessing entity, and the access reason (e.g., disclosure). To simplify querying this audit log, consider storing it in an indexed data store, such as elasticsearch.

On this page