Inflectra Corporation
8121 Georgia Ave, Suite 504
Silver Spring. MD 20910-4957
+1 202.558.6885
www.inflectra.com
SpiraTeam HIPAA Compliance Checklist
Health Insurance Portability and Accountability Act
May 25th, 2015
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 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. A copy of this
document will be provided to customers upon prior execution of the Inflectra confidentiality agreement.
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.
© Copyright 2015, Inflectra Corporation
Page 2 of 7
This document contains Inflectra proprietary information
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.
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. A copy of this
document 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,
© Copyright 2015, Inflectra Corporation
Page 3 of 7
This document contains Inflectra proprietary information
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.
© Copyright 2015, Inflectra Corporation
Page 4 of 7
This document contains Inflectra proprietary information
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.
© Copyright 2015, Inflectra Corporation
Page 5 of 7
This document contains Inflectra proprietary information
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 the Lightweight Directory
Access Protocol (LDAP) 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
© Copyright 2015, Inflectra Corporation
Page 6 of 7
This document contains Inflectra proprietary information
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 SHA1
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. 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.
© Copyright 2015, Inflectra Corporation
Page 7 of 7
This document contains Inflectra proprietary information