The term HIPAA compliant software is a little misleading inasmuch as no software by itself is HIPAA compliant. Compliance with HIPAA is determined by how software is configured and used, and other factors such as the vendor of the software entering into a Business Associate Agreement if the software is going to be used to create, use, store, or transmit PHI.
When vendors advertise software as HIPAA compliant, it is most often the case that the software has been developed with the necessary mechanisms to support HIPAA compliance. These mechanisms usually include access controls, audit logs, and encryption to comply with the Technical Safeguards of the Security Rule. Some software also includes automatic logoff.
However, these capabilities alone do not make software HIPAA compliant. Most often, the capabilities have to be activated or configured to comply with the Technical Safeguards, or the software has to be deployed on a device with other mechanisms in place to be compliant – as is often the case when “HIPAA compliant software” lacks an automatic logoff option.
Additionally, although software is advertised as HIPAA compliant, it does not guarantee HIPAA violations will not occur – for example, if login credentials are shared to bypass access controls. This issue is not attributable to the software and is something the end user organization should control. Nonetheless, advertising software as HIPAA compliant can lead to a false sense of security.
5 Tips for Developing & Marketing HIPAA Compliant Software
To counter allegations that software developed and marketed as HIPAA compliant software is not HIPAA compliant, vendors should take the following five tips into account.
1. Understand the Security Rule in its entirety
Some organizations consider the Security Rule to consist only of the Administrative, Physical, and Technical Safeguards. However, these Safeguards only account for around half of the “Security Standards for the Protection of Electronic Protected Health Information” (45 CFR Part 164, Subpart C), and it is important that software vendors understand the Security Rule in its entirety.
2. Develop software that is simple to configure and use
One of the reasons why software might not be configured and used compliantly is that it is too complicated to understand. Developers and vendors need to be aware that not every end user organization has an IT team with the skills to understand the workings of the software and pass that knowledge onto end users. In this respect, human technical support is essential.
3. Add mechanisms to prevent circumnavigation
In addition to developing software that is simple to configure and use, developers should integrate mechanisms that make it difficult to circumnavigate compliance controls. It is sometimes the case that end users try to take non-compliant short cuts “to get the job done”, and develops need to build in capabilities that prevent shortcuts or alert system administrators when they happen.
4. Be alert to proposed HIPAA changes
Although it has been some time since a major update to HIPAA, there are several significant HIPAA changes in the pipeline. For example, the proposed “attested” category of uses and disclosures could affect access to some types of PHI, while the proposed changes to allow patients to access PHI by an app of their choice could create compatibility and security challenges for some existing applications.
5. Make it clear compliance is subject to compliant use
HIPAA Covered Entities and Business Associates have multiple rules and regulations to comply with in addition to HIPAA, and not all have the time to investigate every claim made by every software vendor. Software vendors that make it clear their HIPAA compliant software is only compliant when it is configured and used compliantly will mitigate avoidable complaints and negative reviews.
The Importance of Understanding Business Associates’ Obligations
Vendors of HIPAA compliant software qualify as Business Associates, even if they have no access to PHI created, used, stored, or transmitted by the software (per HHS guidance). Therefore, a vendor that develops and markets HIPAA compliant software must itself comply with the Security and Breach Notification Rules, as well as any Privacy Rule standards included in a Business Associate Agreement between the vendor and the end user organization.
Entering into a Business Associate Agreement is essential, as the end user organization will itself be in violation of HIPAA if it fails to do so. It is also important all security incidents are reported to the end user organization (per §164.314) – including those that do not result in a data breach – and that any disclosures of PHI to subcontractors (i.e., cloud storage services) are also covered by a Business Associate Agreement.
Since 2013, Business Associates have been directly liable for violations of HIPAA. HHS’ Office for Civil Rights has the authority to impose civil monetary penalties and enforce corrective action plans on non-compliant Business Associates. State Attorneys General and – in some cases – the Federal Trade Commission can also pursue financial penalties for HIPAA violations attributable to non-compliance by Business Associates.
Therefore, it is in a software vendor’s best interests to understand Business Associates’ compliance obligations and seek professional compliance advice if they are unsure about which obligations apply – certainly before developing solutions that will be marketed as HIPAA compliant software.