If you search for information on testing HIPAA compliant applications, you’ll find a number of overviews on HIPAA, but very little information on how to approach testing software to ensure that it will be HIPAA compliant. Macadamian’s Test Strategy includes HIPAA compliance verification as an important part of its initial sanity testing and full-feature testing. We also ensure that HIPAA compliance defects are clearly indicated in our bug tracking system so their fixes are given high priority.
Note that this section only covers major software testing areas related to ensuring HIPAA compliance, and does not cover other areas such as required physical safeguards like not deploying the software on workstations with publicly viewed screens. Also be aware that testing strategies should depend on the software requirements of the application. Not all testing strategies described in this document are applicable to all applications.
TIP: ￼Defect Tracking
A clear naming convention helps any tracking system. Consider reporting all defects found that relate to HIPAA compliance with the keyword “HIPAA” appended to their titles in your defect tracking system. Any that correspond to high-risk areas (in the Roles Matrix) should be automatically assigned a Critical severity. This ensures that these defects are immediately visible to the Project Leader and are fixed with high priority. Processes like this help reveal issues quickly and allow for easier reporting.
Conduct Initial Sanity Testing
Perform HIPAA-related sanity testing as early as possible in the development cycle to quickly discover any major defects in the application’s HIPAA compliance.
Sanity testing should cover high-level testing in the following areas:
- For each high-risk role / component / operation relationship (as determined in the Roles Matrix), verify the following:
- A user of the specified role is able to authenticate successfully and is granted view, add, modify, delete, or no access to the specified application component operation.
- Each action (user authentication, viewing, modifying, etc.) performed above is recorded in detail in the audit trail.
- Verify encryption in the following areas:
- EPHI (electronic protected health information) in the database.
- Audit trail entries.
Develop a Roles Matrix
Assuming the application makes use of RBA – role-based access (or a similar strategy), the first step in preparing for HIPAA compliance testing is identifying all the roles present in the system and their expected access levels to all components of the application. This identification is done in communication with the customer who then also approves the risk level associated with each role / component / operation relationship.
The risk level is based on information disclosure, frequency of use, chance of error, and impact to the customer if an error occurs in a given component.
The table below is an example of what a roles matrix might look like. In each cell:
“X” indicates that the role has the ability to perform the specified operation (View, Add, Modify, Delete) in the application component. The color indicates the privacy or security risk level if there were a defect in this role / component / operation relationship, where:
RED = HIGH YELLOW = MEDIUM GREEN = LOW