Idealware is a small nonprofit that helps other nonprofits make smart decisions about technology. For more information, visit Idealware's website.
The U.S. Health Insurance Portability and Accountability Act of 1996, much better known by its acronym, HIPAA, provides a set of instructions and guidelines for the encoding, privacy, security, integrity, and availability of patient health data. HIPAA covers a huge amount of ground, from paper records and electronic transactions to casual elevator conversations. One area where HIPAA also provides guidance is in the selection and implementation of software packages for tracking client data.
But HIPAA doesn't provide an easy checklist of requirements a software package must fulfill in order to be compliant. Instead, it offers a set of principles that you should strive for, advising readers to take "reasonable steps" or to disclose the "minimum necessary" information. This language provides organizations with a lot of leeway to define processes and systems that make sense for them, but it can also be confusing, as different readers can easily come away with different interpretations of the same text.
That being the case, how do you go about understanding what you should look for to ensure that a software package will help you to comply with the HIPAA standards? We asked a number of experts on HIPAA and software packages, and rounded up their answers.
Before we dive into software considerations, how do you know if you need to pay attention to HIPAA guidelines? HIPAA applies to any organization that transmits any electronic billing information (such as invoices, or information needed to look up insurance information) to any health insurance company, including Medicare or Medicaid. This means that HIPAA typically regulates organizations involved in healthcare, including organizations providing counseling, therapy, or other services that need to bill insurance companies.
If you bill or conduct any billing-related electronic communications with insurance companies, no matter how minimal, your entire organization is a "covered entity." This means that all your data, processes, and systems throughout the organization are subject to the HIPAA guidelines, even if you only bill for one program or a few patients.
If you conduct all your communications in paper form, rather than electronically, you're technically not required to follow HIPAA guidelines. This could be an "out" if you only need to bill on rare occasions a couple times a year, and otherwise track very little health-related data. In general, however, HIPAA only describes a sensible set of practices and processes to handle client data. If you work in health services, counseling, or any field where you might bill for medical or healthcare services, it likely makes sense to ensure that your software won't preclude you from being compliant if that becomes important down the road.
How, then, do you find a HIPAA-compliant software package? 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. Instead of searching for a "HIPAA-approved" label, you should be looking for software that provides the (few) features suggested by HIPAA guidelines, and that additionally helps to support the policies and best practices that your organization has set up to protect your data.
With that said, what should you be looking for in a software package? For the most part, vendors that support healthcare nonprofits have already given HIPAA considerations a lot of thought, so in most cases you should simply be able to confirm that they support the key features you'll need:
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.
HIPAA specifies that each employee at your organization should only see the "minimum necessary" information to do his or her job. Like most of the guidelines, this one is open to interpretation. However, most consider this a requirement for organizations to define what level of access each employee has to the organization's software, based on both the employee's role within the organization as well as on the outside clients he or she has permission to access.
For example, a case worker at your organization would need access to data about the clients he works with. However, because he probably doesn't work with every client your organization serves, it might be useful under HIPAA's guidelines to restrict his access to only the client data within the specific program he works in, or even to his own particular caseload.
Alternatively, someone in your accounting department may require information like address and billing procedures for every client your organization bills. But she doesn't need other details, such as the case notes. In this case, it can be useful to have the ability to restrict the accountant's access so that she can view only specific information about each client.
Note that this rule applies to fundraisers at your organization as well. HIPAA precludes giving out any information about diagnosis for marketing purposes — even general information like which program a patient was enrolled in. Most interpret this to mean that fundraisers and marketing staff shouldn't have access to any information beyond basic demographics (like name and address) for previous or current patients.
For instance, a fundraising team may be given access to the name and address of a previous patient in order to send him a fundraising letter, but they can't gain access to what he was diagnosed with, or what program he was enrolled in. If the fact that you provided services to someone implies information in of itself (for instance, you only provide treatment to victims of sexual assault, or HIV/AIDS), you may need to limit access to client data even further.
From a system perspective, all of this means that it is useful to be able to define quite specific roles and access levels in your software package and to have the ability to customize them to meet your needs.
The more complex your roles get, however, the more useful it can be to also have an "emergency override" function that allows appropriate people to access whatever data they need in an emergency function. For instance, there might be a software function that will allow any patient-facing staff member to access any information in the system — but only by engaging a mechanism that will automatically email several other staff members, log everything that staff member does, and kick off a review process. HIPAA certainly doesn't preclude such an override feature; indeed, it specifically states that the measures asked for should never get in the way of appropriate patient care.
Note that HIPAA doesn't specify what roles and access levels you should have at your organization, simply that you have a written policy that defines "reasonable" handling of data to ensure privacy, and that you then follow through on it. In fact, your software doesn't have to help enforce your policy — you could simply define that people shouldn't access data they don't need, and keep an access log to show they didn't — as long as this policy is "reasonable" for your organization. (Who decides what's "reasonable"? A court, eventually, if there are complaints about the way you handle data.)
HIPAA also requires you to secure your data. For example, the application should be secured behind a firewall, and with solid password protection for user accounts.
Bear in mind that this guideline shouldn't impact a decision as to whether to use an installed system or one that's hosted over the Internet. The datacenters provided by vendors with Internet-based solutions often have security and monitoring features that far surpasses what an organization can practically provide for itself.
The American Recovery and Reinvestment Act of 2009 included a specific act — called the HITECH Act (or the Health Information Technology for Economic and Clinical Health Act) — that encourages you to encrypt your data. If you experience a security breach (for instance, your data is stolen), the new requirements specify that you must contact every affected client and report the breach to the government … unless you have encrypted your data. Under HITECH, this includes the data in your database, the data sent over the Internet or via another electronic method, and any deleted data.
Although it's almost ubiquitous in business these days, email is not a secure way to send information. For this reason, it's important to encrypt any email that might have patient information, which can be done without a lot of expense by third-party systems. These encryption methods are typically separate from your client-tracking system, and integrate without a problem, but you'd want to make sure that any emails sent directly through the system will be caught and encrypted.
It can also be useful to look for software that has an internal messaging system. This type of functionality might, for instance, send an email to a staff member saying simply that she had received an email, and make it easy for her to log into the system to access it. As the information itself never leaves the protected environment of your software package, it's as secure as the package is itself.
HIPAA provides a number of guidelines about operational processes and procedures, including a requirement that patients sign an authorization form that allows your organization to use their information for their care. These authorization forms must include both what you'll use the data for, and an expiration date. While it's not required, system functionality to help track these authorization forms — for instance the date and person signing, or even a scan of the form — can be very useful. In particular, this type of tracking functionality could help you manage expiration dates and re-authorizations for those in continuing care.
One of the first pieces of HIPAA to be enacted was the definition of a specific code set and transaction specifications to help standardize the transmission of billing information. If you're looking for a system that handles billing as well as client tracking, you certainly should ensure that your system supports these HIPAA standards, but you're very unlikely to come across a system that doesn't.
HIPAA requires that organizations ensure that patient data is available to those who need to see it, including the patients themselves. You can provide that access in any way you like, including on paper, but the availability requirement implies that your system is functional on an ongoing basis and that your data is reliably backed up. Even if you have a fire or other disaster, you need to be able to produce old data should a client request it.
This requires an understanding of what mechanisms are in place to preclude the loss of data. If a vendor will be hosting your system, what do they have in place to back up your data and ensure the continuity of the system? If you're going to host the system on your own servers, what are your backup procedures and emergency plans?
Finally, keep in mind that all the people who will see your data — including vendors or consultants involved in a data migration — need to sign a "Business Associate" contract, which states that they'll uphold the same policies and procedures that your organization does in order to protect the privacy and security of your data.
The HIPAA regulations continue to evolve. For example, the HITECH Act strengthens enforcement of the HIPAA requirements and provides new recommendations on data security, particularly on encryption.
So what's a busy nonprofit to do to keep on top of possible new regulations? It's unlikely that you'll be required to make a dramatic short-term shift in policy, or that there will be severe penalties if you don't implement changes immediately.
You'll certainly want to keep an eye out for changes to the HIPAA regulations, but it probably makes sense to put the burden on your vendor to monitor the laws carefully. Ask your vendor how it keeps abreast of changes to the regulations, and what its action plan is to say abreast of them. Ask it what percentage of its clients must be HIPAA compliant. If the vast majority of your vendor's client base is covered by HIPAA, it will need to be able to make required changes or go out of business.
In general, HIPAA provides a set of solid guidelines for protecting your patients' confidentiality and data. Most software systems that do business with health organizations have already given a lot of thought to the best way to support these guidelines, so your focus in this area should be mostly that of confirmation. With just a little bit of work, you should be able to verify that the system you're interested in will help you pave the way to a HIPAA-compliant future.
Very useful summary of the provisions of the HITECH Act by the Center for Democracy and Technology.
Many thanks to the experts who contributed their time and expertise:
Image: sergign / Shutterstock
Join today to access donations and discounts for your nonprofit or library.
Already a member?