Drew Miller

I will eventually return to my long overdue series regarding custom membership providers, but here’s something else in the meantime:

Working on a project at work, I ran into an issue where if you scrolled down on the page the AJAX postback wouldn’t return the focus to the top of the next page. This blog post offered a quick solution that solved my problem quite nicely.

<script type="text/javascript" language="javascript">
Sys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequestEventHandler);
function EndRequestEventHandler(sender, args)
{
    scrollTo(0,0)
}
</script>

Every once in a while, the company I work for encounters a potential client whose project requires that it maintain HIPAA Compliance. We have, for one reason or another, never taken one of these such projects…until now. After considerable research on my part, I have figured out (as far as I can tell) the exact implications of a HIPAA Compliant site to me, the site’s developer. Below are my findings.

What is HIPAA?
In short, HIPAA is a congressional act that governs how electronic information pertaining to medicare/medicaid must be handled: including submission, storage, and retrieval. Detailed information regarding HIPAA can be found at this wikipedia article, or the website for the Centers for Medicare & Medicaid Services. The specific part that effects me, as a developer, is The Security Rule section. Moreover, since my concern is just with the design and development of the application and associated database, but NOT hosting, I have focused on the Technical Safeguards sub-section.

Technical Safeguards

Technical Safeguards - controlling access to computer systems and enabling covered entities to protect communications containing PHI transmitted electronically over open networks from being intercepted by anyone other than the intended recipient.

• Information systems housing PHI must be protected from intrusion. When information flows over open networks, some form of encryption must be utilized. If closed systems/networks are utilized, existing access controls are considered sufficient and encryption is optional.
• Each covered entity is responsible for ensuring that the data within its systems has not been changed or erased in an unauthorized manner.
• Data corroboration, including the use of check sum, double-keying, message authentication, and digital signature may be used to ensure data integrity.
• Covered entities must also authenticate entities it communicates with. Authentication consists of corroborating that an entity is who it claims to be. Examples of corroboration include: password systems, two or three-way handshakes, telephone callback, and token systems.
• Covered entities must make documentation of their HIPAA practices available to the government to determine compliance.
• In addition to policies and procedures and access records, information technology documentation should also include a written record of all configuration settings on the components of the network because these components are complex, configurable, and always changing.
• Documented risk analysis and risk management programs are required. Covered entities must carefully consider the risks of their operations as they implement systems to comply with the act. (The requirement of risk analysis and risk management implies that the act’s security requirements are a minimum standard and places responsibility on covered entities to take all reasonable precautions necessary to prevent PHI from being used for non-health purposes.)

Let’s address these points individually.

Information systems housing PHI must be protected from intrusion. When information flows over open networks, some form of encryption must be utilized. If closed systems/networks are utilized, existing access controls are considered sufficient and encryption is optional.

What does this mean? SSL! Requiring a 128-bit encrypted SSL connection in your IIS configuration should be more than enough to satisfy this constraint.

Each covered entity is responsible for ensuring that the data within its systems has not been changed or erased in an unauthorized manner.

This section is certainly a little vague, but as far as I can tell this is stipulating extensive database logs. You will need to record any patient data being added, edited, or deleted; the user who executed this change; and the time at which it was executed. There are a variety of third-party tools for DB auditing, but I’ve not seen any that I would like for this task. Instead, I would make sure that all SQL is executed via stored procedures (a good standard to follow for any project) and that any sproc handling sensitive data take in an @modifiedBy property. Using this and GETDATE(), you should be able to capture all important changes to the database occurring through your application.

Additionally, any password stored in the database should be hashed and salted. A nice article about encrypting passwords can be found here. I will also be posting another blog later which will dive a little further into password encryption.

Data corroboration, including the use of check sum, double-keying, message authentication, and digital signature may be used to ensure data integrity.

From what I can tell, this is one of the “Addressable” items, rather than “Required”. (See the Implementation Specifications section in this Security Series for a definition of addressable vs required) It would seem logical to me that being logged into a secure system would be enough to ensure the integrity of data being submitted from a user. However, one additional security measure that I would implement here would be an automatic session logoff.

Covered entities must also authenticate entities it communicates with. Authentication consists of corroborating that an entity is who it claims to be. Examples of corroboration include: password systems, two or three-way handshakes, telephone callback, and token systems.

This section is one of the harder parts about developing a HIPAA Compliant web app. Your atypical SqlMembershipProvider is not going to be good enough to really fulfill this section. Instead, I would recommend implementing your own MembershipProvider and ensuring that it follows Microsoft’s Strong Password Guidelines. That means:

• Seven characters or more
• Contains at least one uppercase, lowercase, number, and symbol
• Cannot be a repeat of a past password over the course of X changes (X being somewhat up for interpretation - general consensus seems to be about 3)
• Password must be changed every X days (generally 45)
• Password cannot be changed more than once every X days (generally 3)

An additional constraint with HIPAA compliant apps is that you cannot use an automated Forgot Password control. Rather, users should be given a phone number to call where the operator can verify their identity and reset their password for them.

A co-worker, Joshua Arnold, and I are actually working on implementing an extended membership provider that not only cuts out all the excess that comes with the default implementation, but also meets all the above requirements. Additionally, we will create a custom Login control that will allow for more robust error handling, and address some of the existing problems with the default Login control. I’ll be writing another blog or two shortly about all of that. =)

• Covered entities must make documentation of their HIPAA practices available to the government to determine compliance.
• In addition to policies and procedures and access records, information technology documentation should also include a written record of all configuration settings on the components of the network because these components are complex, configurable, and always changing.
• Documented risk analysis and risk management programs are required. Covered entities must carefully consider the risks of their operations as they implement systems to comply with the act. (The requirement of risk analysis and risk management implies that the act’s security requirements are a minimum standard and places responsibility on covered entities to take all reasonable precautions necessary to prevent PHI from being used for non-health purposes.)

These sections don’t effect the development of a project, however they are arguably the most important requirements of any HIPAA Compliant application. Any business thinking about creating a project under the purview of HIPAA will want to do extensive research into what documentation is required before they dive into development.

Summary
I conclusion, if you work for a small consulting firm such as myself, I would make sure that you have done extensive research into what is required of you when developing a HIPAA Compliant application. My blog merely skims the surface, and is by no means an official guide - merely my initial interpretation of the guidelines that I’ve seen. If, however, you are going to do development on a HIPAA app, stay tuned for my upcoming blog(s) regarding custom membership providers, strong passwords, and encryption.

Also, if anyone out there has some wisdom regarding HIPAA regulations that I’m missing, please fill me in!