Domino and HIPAA: How they interact

Last month, I presented summaries of the federal HIPAA healthcare law ( What Is HIPAA) and the portion of the law related to computer security ( Conducting a HIPAA Security Audit). I also mentioned some of the ways the security rules overlap with Domino/Notes and I included a downloadable tool to perform HIPAA security audits. The tool is a Notes database that contains each line item of the HIPAA security rules. If you expect to have any involvement with the healthcare industry over the next two years, I encourage you to skim the default view of this database.

This month, I drill down within the security rules to examine them in more detail, with further discussion about implementing them in Domino/Notes systems. (And I promise that next month's tip won't be about HIPAA!)

As I mentioned before, the HIPAA security regulations are divided into five sections:

• Administrative
• Physical
• Technical
• Organizational
• Policies, Procedures, and Documentation

Four of these sections are independent of the computer system being discussed. In other words, the rules don't care if we are talking about a VisualBasic application running on WinXP or Domino running on Linux. The Administrative rules discuss management activities such as naming a security officer, performing risk analysis, and various personnel procedures. The Physical rules are concerned with where computers are located, how they are locked, and how backup media is handled. Organizational rules discuss contracts and relationships with business partners, and Policy rules govern documentation and retention of security procedures.

Only the Technical section of the HIPAA security rules actually addresses what is normally thought of as "computer security." The detailed line items of this section, with the actual language from the law, are:

1. Access Controls / Unique User Identification -- Assign a unique name and/ or number for identifying and tracking user identity.
2. Access Controls / Emergency Access Procedures -- Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
3. Access Controls / Automatic Logoff -- Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
4. Access Controls / Data Encryption -- Implement a mechanism to encrypt and decrypt electronic protected health information.
5. 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.
6. Data Integrity -- Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.
7. Person and Entity Authentication -- Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
8. Transmission Security / Integrity -- Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
9. Transmission Security / Encryption -- Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.

The first thing to notice about the technical security rules is that they say nothing about how any of these items should be implemented. For example, there is no requirement that an organization use SSL (supported by Domino) to satisfy #9, or a public/private key ID system (such as Notes) for #7. On the other hand, the Domino/Notes solutions to these line items are perfectly acceptable, since they meet the stated requirements. This lack of specificity is one of the major changes from the draft version of the rules to their final wording.

Also important for SearchDomino readers is the fact that Domino and/or Notes contain built-in mechanisms to easily meet each of the technical security line items. Here is a look at each one:

1. Notes ID files and Internet accounts in the NAB provide unique identification of each person using the system. The only requirement is to not assign generic IDs (such as TempEmployee1) that are shared by more than one person.
2. The goal of #2 is to make sure that security rules do not get in the way of good patient care. So there should always be a method to get around security restrictions, if such access is needed to deliver good medical care. Domino/Notes can accomplish this in a variety of ways, including special IDs that are only for emergency use, with a method for tracking when they are used.
3. This mechanism is built into the security preferences for the Notes workstation software.
4. This requirement can be satisfied with encrypted fields in a database or by whole-database encryption. Again, both mechanisms are built into Domino and Notes.
5. Domino/Notes provide audit trails via server log files (LOG.NSF), web log files (DOMLOG.NSF), per-database user activity records, transaction logging, and custom event records.
6. Electronic signatures achieve data integrity within Notes through public/private key pairs, which has been a part of Notes security for at least a decade.
7. Both Notes ID files and Domino web accounts ensure positive identification of each user. Of course, it is important to keep in mind the caveats that no method is perfect and that username/password pairs must be implemented correctly to be effective.
8. SSL and Notes port encryption satisfy both #8 and #9.

In summary, Domino and Notes have no inherent problem meeting the HIPAA security requirements. Of course, like any tool, Domino/Notes must be used correctly in order to achieve the HIPAA goals. And an organization must also meet the other (significant) non-technical security requirements.

Chuck Connell is president of CHC-3 Consulting, which helps organizations with all aspects of Domino and Notes. He also helps healthcare organizations meet the HIPAA security rules through his web site HipaaSecurityExperts.com.