Abstract
If you are choosing an Application Lifecycle Management (ALM) solution in the Healthcare industry, if you are a ‘covered entity’ an absolute requirement is to make sure the software you choose is HIPAA compliant. HIPAA is the Health Insurance Portability and Accountability Act of 1996. These two rules are otherwise known as the ‘Standards for Privacy of Individually Identifiable Health Information’(Privacy Rule) and the ‘Security Standards for the Protection of Electronic Protected Health Information’(Security Rule).
Because the software is most likely going to be managing sensitive client data, you cannot risk having it in an unsafe or vulnerable system. So, what makes software HIPAA compliant? Read on to find out how SpiraTeam is HIPAA compliant and use this checklist as a guide to ensure that you have implement SpiraTeam in a HIPAA compliant manner.
What does HIPAA Compliant Actually Mean?
Firstly, how do you find a HIPAA-compliant software package? Well technically speaking you can't, because no such thing exists.
It's you, as an organization, that's HIPAA compliant, and no software application is going to magically make you that way. HIPAA defines a large set of policies and procedures, many of which have nothing to do with technology. What the software package can do is provides features suggested by HIPAA guidelines, and implement the necessary HIPAA policies and best practices that your organization has set up to protect your data using these provided features.
HIPAA Requirements
Under HIPAA Security requirements there are specific provisions for administrative safeguards, physical safeguards, and access control.
1. Administrative Safeguards [142.308 (A)]
Administrative safeguards are administrative actions, policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect Protected Health Information (PHI) and to manage the conduct of the Covered Entity's workforce in relation to the protection of that information.
1.1. Security Management Process
The first standard under Administrative Safeguards section is the Security Management Process. This standard requires covered entities to: “Implement policies and procedures to prevent, detect, contain and correct security violations.”
Inflectra has documented Information Security Policies and Processes which have been developed in line with both the PCI-DSS information security standard for credit card payment providers and the AICPA SOC2 industry standard security certification. A copy of our SOC2 security certification, information security policies as well as our ISO 27001 and ISO 9001 audits will be provided to customers upon prior execution of the Inflectra confidentiality agreement. Our security certifications and outlined on the security page of our website.
1.2. Assigned Security Responsibility
The second standard in the Administrative Safeguards section is Assigned Security Responsibility. The purpose of this standard is to identify who will be operationally responsible for assuring that the covered entity complies with the Security Rule.
In most cases Inflectra is not itself handling PHI data but is providing a service or product being used by a covered entity that is. Therefore, the Inflectra quality assurance manager is the responsible person and would work with the appropriate point of contact at the covered entity.
1.3. Workforce Security
The third standard is Workforce Security, which states that covered entities must: “Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under [the Information Access Management standard], and to prevent those workforce members who do not have access under [the Information Access Management standard] from obtaining access to electronic protected health information.”
Inflectra has a documented workforce security set of policies, including the hiring, termination and monitoring of employees and contractors. These policies and procedures are audited annually as part of our SOC2 certification and ISO:27001 / ISO:9001 external vendor audits.
1.4. Information Access Management
The fourth standard in the Administrative Safeguards section is Information Access Management. Covered entities are required to: “Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part [the Privacy Rule].”
Inflectra has a documented process in place for accessing systems that could contain PHI, either customer application instances (hosted only) or support session information (hosted and download). Inflectra has a documented set of policies regarding access to the various Inflectra information systems to ensure a consistent authorization process is in place.
1.5. Security Awareness and Training
Regardless of the Administrative Safeguards a covered entity implements, those safeguards will not protect the PHI if the workforce is unaware of its role in adhering to and enforcing them. Many security risks and vulnerabilities within covered entities are internal. This is why the next standard, Security Awareness and Training, is so important.
Inflectra has implemented the following best practices for security awareness and training: Periodically sending updates and reminders about security and privacy policies to employees/contractors, having procedures for guarding against, detecting, and reporting malicious software, ensuring that there are procedures for creating, changing, and protecting passwords, and monitoring of logins to systems and reporting of discrepancies.
1.6. Security Incident Procedures
The next standard is Security Incident Procedures, which states that covered entities must: “Implement policies and procedures to address security incidents.” The purpose of this standard is to require covered entities to address security incidents within their environment. Addressing security incidents is an integral part of the overall security program. Implementing the Security Rule standards will reduce the type and amount of security incidents a covered entity encounters, but security incidents will occur. Even covered entities with detailed security policies and procedures and advanced technology will have security incidents
Inflectra has a documented Information Security Policies and Process which has been developed in line with the PCI-DSS information security standard for credit card payment providers and the AICPA SOC2 industry standard security certification. A copy of our incident response plan will be provided to customers upon prior execution of the Inflectra confidentiality agreement.
1.7. Contingency Plan
The purpose of contingency planning is to establish strategies for recovering access to EPHI should the organization experience an emergency or other occurrence, such as a power outage and/or disruption of critical business operations. The goal is to ensure that organizations have their EPHI available when it is needed. The Contingency Plan standard requires that covered entities: “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.”
Inflectra has a documented Disaster Recovery Plan for both its office locations and also datacenters where internal and customer data is stored. A copy of this document will be provided to customers upon prior execution of the Inflectra confidentiality agreement.
2. Physical Safeguards [142.308 (b)]
Physical safeguards are physical measures, policies, and procedures to protect a Covered Entity's electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.
For customers hosted in a cloud environment, the physical safeguards cover both the location where the software is hosted and also the company’s support facilities where the employees supporting the service reside.
2.1. Facility Security Plan
Facility security plans must document the use of physical access controls. These controls must ensure that only authorized individuals have access to facilities and equipment that contain PHI. In general, physical access controls allow individuals with legitimate business needs to obtain access to the facility and deny access to those without legitimate business needs. Procedures must also be used to prevent tampering and theft of PHI and related equipment.
Inflectra has a robust Facility Security Plan for both its own office locations (used for both on-premise and hosted customers) and the datacenters that it uses to host its cloud service. The appropriate documentation detailing the safeguards and the security plan can be provided to customers upon execution of the standard Inflectra confidentiality agreement.
2.2. Data Backup and Storage
Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must “create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.”
Inflectra has a robust backup and storage mechanism in place for all its internal corporate data, its customer data, the source code of the applications it supports and the customer instances of its applications (hosted/cloud customers only). The mechanism utilizes industry best practices for backup and archive, with the data stored in a physically remote location from all Inflectra offices and datacenters.
3. Technical Safeguards [142.308 (c)]
Technical safeguards mean technology and the policy and procedures for its use that protect electronic health information and control access to it.
3.1. Unique user identification
All users of the software must have a unique way of being identified so that all changes can be tracked backed to them and to make sure that the application security can be enforced for specific users. Ideally the user management should be centralized by the ‘covered entity’ so that all software applications can use a single set of users, passwords and identifiers. This reduces the likelihood that certain individuals erroneously have access to the data.
SpiraTeam provides a robust user management capability of its own, with each user having a unique ID as well as the ability for administrators to specify password complexity rules and other security parameters. In addition, SpiraTeam provides a single-sign-on capability using either the Lightweight Directory Access Protocol (LDAP) or OAuth 2.x protocols, so that SpiraTeam can delegate the user management and access identification to the covered entity’s existing user management directory.
3.2. Automatic Log off
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.”
As a general practice, users should logoff the system they are working on when their workstation is unattended. However, there will be times when workers may not have the time, or will not remember, to log off a workstation. Automatic logoff is an effective way to prevent unauthorized users from accessing PHI on a workstation when it is left unattended for a period of time.
SpiraTeam, KronoDesk and the Inflectra website all provide an automated logoff facility where the user will be logged-off after predetermined amount of inactivity. In the case of SpiraTeam and KronoDesk, the time interval for this automated logoff is configurable by the covered entity.
3.3. Limiting Access and Use to the Minimum Necessary.
Under the regulations this is described as "covered entity must develop and implement policies and procedures that restrict access and uses of protected health information based on the specific roles of the members of their workforce. These policies and procedures must identify the persons, or classes of persons, in the workforce who need access to protected health information to carry out their duties, the categories of protected health information to which access is needed, and any conditions under which they need the information to do their jobs.”
What this means for ALM software is that it must provide the ability to create access levels and user roles to group employees into so that you can restrict access to PHI that is not necessary for them to do their job.
SpiraTeam facilitates this by providing extensible and powerful role-based security that allows you to define very granular roles rather than having to live with a default set provided by the vendor. SpiraTeam lets you implement these roles per project so that a user only is granted the minimum necessary permissions to perform their tasks on each and every project.
3.3. Encryption / Decryption
HIPAA requires you to secure your data, although it does not explicitly state what methods, algorithms should be used. At a minimum the data transmission between the users and the application should be encrypted and all security information (passwords, security questions/answers) should be one-way hashed and salted. For further protection, the entire database could be encrypted at rest.
By default, SpiraTeam one-way hashes all passwords and other security information using the SHA256 algorithm together with an appropriate SALT. In addition, when you use the Inflectra hosted cloud service, all communications to the service are via. 256-bit SSL/TLS encrypted connections. The data is encrypted at rest using AES-256 encrypted volumes.
For those customers hosting on premise, Inflectra provides recommendations on how to implement the same level of encryption and also provides mechanisms for encrypting the data at rest using SQL Server Transparent Data Encryption (TDE) services.
4. Other Considerations
4.1. Audit Logging & History Tracking
One of the clearest HIPAA requirements is that organizations keep an audit log of who did what in the software package. It's important that your package be able to track which person accessed which record (down to the client level) on what date, and whether he or she viewed it, updated it, or deleted it. (This rule implies that all users need a distinct username and password to access organizational software.)
It's also very desirable to be able to track what each user changed specifically ― for instance, to be able to see the value of a field both before and after he or she changed it ― although experts' opinions vary on whether this is strictly required under the HIPAA guidelines.
SpiraTeam provides a robust history change tracking system out of the box that allows you to view all of the changes made to a specific artifact by all users in the system and also the reverse view, looking at all the changes made by a specific user across all of the artifacts in the system. This functionality is further reinforced in v5.0 of SpiraTeam with the introduction of CFR Part 11 compliant digital signatures.
4.2. Business Associate Agreement
In addition to these software requirements, it's imperative to have a Business Associate Agreement (BAA) with any stakeholder you work with to protect the PHI of the clients you serve. BAAs typically state that the software vendor will uphold the same policies and procedures that your organization does in order to protect the privacy and security of your data.
Inflectra is happy to work with customers to put HIPAA BAAs in place as part of our software support contracts. We have worked with many healthcare customers in the past and where necessary, executed BAAs as required by the covered entity.