Enterprise Software

Ignore the HIPAA security rules at your own considerable risk

Federal regulations involving protected health information are complicated, convoluted, and fraught with potential liability for application developers. Protect yourself by becoming intimately familiar with HIPAA and its security rules.

Few laws have a direct impact on software application development like the protected health information (PHI) security provisions of the Health Insurance Portability and Accountability Act (HIPAA). If you are developing any application that deals even remotely with health care providers, health insurance carriers, personal student information, or human resources, you may very well be required to comply with the provisions of HIPAA. And, if you are required to follow those rules, and fail to do so, you are opening yourself up to extensive liability.

If you are trying to determine whether your current project is subject to the HIPAA Security Rules, the best place to start is with the definition of protected health information. PHI is defined by HIPAA regulations as "any information, whether oral or recorded in any form or medium" that:
  • "Is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse."
  • "Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual."

The key point to remember when considering this extensive list of HIPAA applicable situations is that the information must be tied to an individual. Aggregate information does not fall under the HIPAA jurisdiction.

The security safeguards outlined in the HIPAA regulations have been placed into three categories: administrative, physical, and technical. Within each category, there are provisions that are required and others that are addressable. Addressable, means that an organization is required to perform a risk assessment to determine if that provision itself is applicable. So while the addressable safeguard may not be required the analysis that led to that conclusion is required.

The safeguard called for under the administrative category is also the easiest one to implement. Someone must be designated as the person responsible for securing PHI in the organization. This person is responsible for setting the workforce authorizations, and supervisions, as well as contingency plans.

If you are the developer of PHI-related applications, this is likely to be the person providing the specifications. Policies regarding access play a major role in this category.

The physical safeguards revolve around procedures and policies limiting access to electronic information systems and the facilities in which they are kept. Covered entities are required to formulate policies and procedures for workstation use that include authorization, encryption, virus protection, e-mail guidelines, and software licensing policies.

For application developers, the encryption and authorization safeguards will be the most likely to come into play, especially if you are designing the software for alarm systems, employee access systems, etc. However, there are also addressable safeguards concerning data backup and storage, and the reuse of media that may be a consideration when you are designing your application and the manner in which it will function.

The technical safeguards standard is the standard developers will have to deal with directly the most often. The law requires the covered entity: "Implement technical policies and procedures for electronic information systems that maintain electronic PHI to allow access only to those persons or software programs that have been granted access rights as specified."

That is definitely an all-encompassing statement. The required safeguards deal with unique user identifications, emergency access procedures, and audit controls. The addressable safeguards relate to automatic logoffs and encryption mechanisms.

The emergency access procedures requirement is intriguing for its contradictory nature when compared to normal access controls in other industries. Basically, as a developer, you will be putting a sanctioned back door to the protected information. All emergency access will have to be monitored and reported, which are aspects that will have to be considered at the time of application design.

The audit controls will be the greatest point of contention and liability. Audit controls could include:
  • User access
  • System resources
  • Data integrity
  • Log in reports

The capability to ensure the integrity of the data is of paramount concern. Not only must access to the data be restricted and protected, any unauthorized access must be discovered, monitored, and reported. This is a significant challenge for any application especially when the security implementation can be corrupted by malicious users. In such a situation, determining ultimate liability could boil down to lengthy and costly litigation.

This very brief overview is only the tip of the iceberg when it comes to the underlying regulations associated with HIPAA and PHI. And like an iceberg, those underlying and unseen parts can sink you and your organization. Developing applications or even Web services that access any system related to the health care industry requires the utmost care and due diligence to ensure compliance with HIPAA's provisions. If you fail to take a very serious approach to such an application, you could find yourself embroiled in some nasty litigation.

Additional information
Delve deeper into the HIPAA regulations at these links:

With that sobering fact in mind, it occurs to me that developers should take steps to make application development for this industry a little less problematic. Perhaps you have experience in this area and have some tools you used to make sure your applications were compliant with HIPAA regulations. Or perhaps you have some policy statements that could help members gauge the influence of this law on application development.

Submit a tool
If you have a HIPAA compliance tool that you would like to share with Builder.com, just send it to me an e-mail with HIPAA Tool in the subject line.

If you have such a tool or policy designed to be an aid toward HIPAA compliance, Builder would like to invite you to submit it for the benefit of all the members. If we publish your tool (checklists, guidelines, etc.) we'll send you a Builder/TechRepublic book of your choice. If you have a pertinent experience that you'd like to share, I encourage you to add it to the article discussion forum.

About Mark Kaelin

Mark W. Kaelin has been writing and editing stories about the IT industry, gadgets, finance, accounting, and tech-life for more than 25 years. Most recently, he has been a regular contributor to BreakingModern.com, aNewDomain.net, and TechRepublic.

Editor's Picks

Free Newsletters, In your Inbox