HIPAA Compliance Effective April 13, 2015

Regarding a Covered Entity or Business Associate

1. Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations.
   
   Implementation specifications:
   1. Risk analysis (Required). 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 or business associate.

      We conduct monthly PB tools analyses and testing of the security and accuracy of the web application. So far, we have conducted one risk analysis that described the PB platform and testing efforts.
   2. Risk management (Required). Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a).

      Our team is constantly looking for ways to improve our security practices. If our risk analyses reveal any potential vulnerabilities, PB’s technology team makes the necessary changes to reduce risks. Our team members use GitHub, a software versioning and source code management system, to track bug reports and respond to issues.
   3. Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity or business associate.

      All of our team members are HIPAA-certified, and they closely follow HIPAA Security and Privacy rules. If any of our members fail to comply, their administrative rights are taken away and administrative accounts are suspended until they re-review the relevant HIPAA training documents. PatientBank uses the Yale School of Medicine training module for HIPAA training.
   4. Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports.

      We use Amazon Web Services (AWS) for data storage and hosting. AWS is built for HIPAA compliance, as described in their white paper, and includes powerful auditing and logging capabilities. Additionally, every object in our database is timestamped with created_at and updated_at values that enable our team to track changes. The application also includes an "Events" system to track actions relevant to ePHI (i.e. uploads, downloads, views, and transfers).
2. Assigned security responsibility. Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart for the covered entity or business associate.

   Feridun Mert Celebi is PB’s security official responsible for the development and implementation of the policies and procedures required by HIPAA.
3. Workforce security. Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information and to prevent those workforce members who do not have access from obtaining access to electronic protected health information.
   
   Implementation specifications:
   1. Authorization and/or supervision (Addressable). Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed.

      Qualified members of the team go through a rigorous onboarding process involving HIPAA training. With successful completion of the training, members receive administrative access to the web application, granted (ii). All activity by administrative users is tracked in the same way that patient and provider user activity is tracked.
   2. Workforce clearance procedure (Addressable). Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.

      Only PB administrators with patient- or provider-facing responsibilities have immediate access to ePHI. Administrative users our easily distinguished based on their team, so this type of delineation is simple. Technology team members who develop the web application may be granted access to our administrative site to ensure the application is functioning properly on production servers.
   3. Termination procedures (Addressable). Implement procedures for terminating access to electronic protected health information when the employment of, or other arrangement with, a workforce member ends or as required by determinations made as specified in paragraph (ii) of this section.

      Our administrative members have the necessary power to grant or terminate access to ePHI through our administrative site.
4. Information access management. Implement policies and procedures for authorizing access to electronic protected health information.
   
   Implementation specifications:
   1. Isolating health care clearinghouse functions (Required). If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.

      Not applicable.
   2. Access authorization (Addressable). Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.

      Qualified members are given accounts only after completing HIPAA training, and they access ePHI through our administrative web application.
   3. Access establishment and modification (Addressable). Implement policies and procedures that, based upon the covered entity's or the business associate's access authorization policies, establish, document, review, and modify a user's right of access to a workstation, transaction, program, or process.

      This is implemented through paragraph (4ii) and (4iii).
5. Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).
   
   Implementation specifications:
   1. Security reminders (Addressable). Periodic security updates.

      We do not have official security reminders. As a small team working on a health care product, we constantly evaluate our security practices.
   2. Protection from malicious software (Addressable). Procedures for guarding against, detecting, and reporting malicious software.

      Our team members protect their work stations with anti-virus software. AWS also implements the necessary precautions to detect malicious software.
   3. Log-in monitoring (Addressable). Procedures for monitoring log-in attempts and reporting discrepancies.

      Any user’s electronic footprint regarding their activity on PB is recorded in logs.
   4. Password management (Addressable). Procedures for creating, changing, and safeguarding passwords.

      All passwords are encrypted. Any user (patient, provider, or admin) has the ability to change or reset his or her password.
6. Security incident procedures. Implement policies and procedures to address security incidents.
   
   Implementation specifications:
   1. Response and reporting (Required). Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes.

      All security incidents are identified and reported to our security officer. The security officer takes the necessary precautions to mitigate the incident and notifies the parties involved in the incident. These incidents are documented internally and available upon request.
7. Contingency plan. Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information.
   
   Implementation specifications:
   1. Data backup plan (Required). Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.

      Data backup is accomplished through AWS. Amazon Relational Database Service (RDS) backs up our database periodically and allows us to retrieve copies of documents stored in Amazon servers.
   2. Disaster recovery plan (Required). Establish (and implement as needed) procedures to restore any loss of data.

      We use AWS Simple Storage Service (S3) for file storage and Amazon Relational Database Service (RDS) for data storage. Both AWS S3 and Amazon RDS provide automatic data backups. These services store backups for a “user-defined period” and “enable point-in-time recovery”, as described online (http://aws.amazon.com/rds/).
   3. Emergency mode operation plan (Required). Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.

      In case of an emergency (i.e. data breach or data loss), AWS provides the necessary tools to retrieve information, block incoming traffic to our servers, and continue the use of PB web applications in a controlled manner.
   4. Testing and revision procedures (Addressable). Implement procedures for periodic testing and revision of contingency plans.

      We do not have specific testing and revision procedures to test emergency scenarios. However, our codebase includes over 600 unit and integration tests that are run before every deployment to ensure application health.
   5. Applications and data criticality analysis (Addressable). Assess the relative criticality of specific applications and data in support of other contingency plan components.

      The security of files stored in S3 and unique user identifiers stored in RDS are of utmost importance. AWS services we utilize (S3 and RDS) to store the sensitive data provide the necessary tools to prevent data loss and store data securely.
8. Evaluation. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity's or business associate's security policies and procedures meet the requirements of this subpart.

   Our team evaluates our security practices informally on a regular basis. We analyzed potential risks and vulnerabilities of our services 6 months ago and have started producing monthly risk analysis reports. In the case that a report reveals a vulnerability, necessary precautions will be taken to reduce exposure to the given risk.

Regarding a Covered Entity or Business Associate

1. Business associate contracts and other arrangements. A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf only if the covered entity obtains satisfactory assurances, in accordance with §164.314(a), that the business associate will appropriately safeguard the information. A covered entity is not required to obtain such satisfactory assurances from a business associate that is a subcontractor.
2. A business associate may permit a business associate that is a subcontractor to create, receive, maintain, or transmit electronic protected health information on its behalf only if the business associate obtains satisfactory assurances, in accordance with §164.314(a), that the subcontractor will appropriately safeguard the information.
   
   Implementation specifications:
   1. Written contract or other arrangement. Document the satisfactory assurances required by paragraph (1) or (2) of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of §164.314(a).

      Currently, we do not have a business associate agreement (BAA) with other entities. We are aware that if we want to partner with hospitals or other health institutions we have to have an approved BAA with them.

1. Facility access controls. Implement policies and procedures to limit physical access to its electronic information systems and the facility or facilities in which they are housed, while ensuring that properly authorized access is allowed.
   
   Implementation specifications:
   1. Contingency operations (Addressable). Establish (and implement as needed) procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency.

      Not applicable. We do not have any facilities.
   2. Facility security plan (Addressable). Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering and theft.

      Not applicable. We do not have any facilities.
   3. Access control and validation procedures (Addressable). Implement procedures to control and validate a person's access to facilities based on their role or function, including visitor control and control of access to software programs for testing and revision.

      Not applicable. We do not have any facilities.
   4. Maintenance records (Addressable). Implement policies and procedures to document repairs and modifications to the physical components of a facility which are related to security (for example, hardware, walls, doors, and locks).

      We do not have any facilities. All our workstations are password-protected and have anti-virus software.
2. Workstation use. Implement policies and procedures that specify the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation or class of workstation that can access electronic protected health information.

   As mentioned previously, all workstations are password-protected and have anti-virus software.
3. Workstation security. Implement physical safeguards for all workstations that access electronic protected health information, to restrict access to authorized users.

   In the future, PatientBank employees will use company computers and no personal devices will be allowed for company work. Currently, the hardware used for development is secured by passwords and encryption.
4. Device and media controls. Implement policies and procedures that govern the receipt and removal of hardware and electronic media that contain electronic protected health information into and out of a facility, and the movement of these items within the facility.
   
   Implementation specifications:
   1. Disposal (Required). Implement policies and procedures to address the final disposition of electronic protected health information, and/or the hardware or electronic media on which it is stored.

      Our team does not store ePHI on electronic media. All our workflows use our web services. For the HIPAA-compliant eFaxing service we use, our team members have to download copies of ePHI. But these files are deleted immediately upon faxing. Any documents received by mail will be stored in a safe.
   2. Media re-use (Required). Implement procedures for removal of electronic protected health information from electronic media before the media are made available for re-use.

      Same as section (i).
   3. Accountability (Addressable). Maintain a record of the movements of hardware and electronic media and any person responsible therefore.

      AWS provides logging capabilities to track the electronic footprints of all our users (patient, provider and admin). Additionally, we have implemented an “Events” system to track actions relevant to ePHI (uploads, downloads, views, transfers).
   4. Data backup and storage (Addressable). Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.

      All health information is stored online in AWS and can be retrieved without movement of equipment.

1. 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.
   
   Implementation specifications:
   1. Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity.

      All our users (patient, provider and admin), requests, access controls and documents have unique user identifiers that are randomly generated and not predictable.
   2. Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.

      In case of an emergency, AWS provides the necessary tools to block incoming traffic to our servers and handle the emergency in a controlled manner. We also always have secure command-line access to AWS servers.
   3. Automatic logoff (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

      We have implemented a timeout system for user sessions.
   4. Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.

      We use 256-bit encryption and SSL to encrypt/decrypt ePHI during transit and at rest.
2. 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.

   AWS provides logging capabilities to track the electronic footprints of all our users (patient, provider and admin). Additionally, we have implemented an “Events” system to track actions relevant to ePHI (uploads, downloads, views, transfers).
3. Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
   
   Implementation specifications:
   1. 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.

      Unauthorized users cannot delete or modify data. Only the creators of ePHI can modify existing data. These creators can be providers or patients. All modifications and deletions are tracked in logs, the “Events” system, and timestamps on database objects.
4. Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.

   We verify the identities of our users via phone calls. After this initial verification, patients and providers use the system via username/password combinations. In the future, PB plans to implement more detailed ID checking features (verifying the identity of the user via health insurance card info).
5. 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.
   
   Implementation specifications:
   1. Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.

      We use 256-bit encryption and SSL to encrypt/decrypt ePHI during transit and at rest. The data is transferred securely and is not prone to modification in transit.
   2. Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.

      Same as section (i).

1. Policies and procedures. Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of this subpart, taking into account those factors. This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements of this subpart. A covered entity or business associate may change its policies and procedures at any time, provided that the changes are documented and are implemented in accordance with this subpart.

   All our security practices and privacy notices are online and documented here.
2. Documentation. Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and if an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment.
   
   Implementation specifications:
   1. Time limit (Required). Retain the documentation for 6 years from the date of its creation or the date when it last was in effect, whichever is later.

      Documents in PatientBank will be stored for at least 6 years.
   2. Availability (Required). Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains.

      This and other security-related documents are available to all members of our team. Our users can also read our privacy and security practices on our user portals.
   3. Updates (Required). Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information.

      Our team follows HIPAA requirements closely to ensure that PatientBank’s security practices remain up-to-date and relevant.

1. Encryption: ePHI is encrypted and securely stored in transit and at rest.

   We use 256-bit encryption and SSL to encrypt/decrypt ePHI during transit and at rest.
2. Backup: ePHI is never lost.

   We can always retrieve data through AWS.
3. Authorization: ePHI is only accessible by authorized personnel

   ePHI is only accessible to qualified administrative users and patients. Patients can grant access to providers or other family members for viewing specific documents.
4. Integrity: ePHI is not altered or destroyed

   Unauthorized users cannot delete or modify data.
5. Disposal: ePHI can be permanently destroyed if deemed necessary

   If the user presents the necessary reasons to destroy his/her records, ePHI can be permanently destroyed.
6. Data storage: Data should be stored on the web servers of a company with whom you have a HIPAA BAA.

   We use AWS for data storage, and AWS provides the right platform to achieve HIPAA-compliance.