10 Truths of Building HIPAA Compliant Software

Care systems are becoming more consumer-centric, forcing more companies to join the trend of providing healthcare outside of the traditional setting of the clinic. Organizations whose success was built on addressing the needs of physicians or healthcare providers are finding it necessary to adapt to the reality of custom care delivery via “connected things.”

Software needs to become a central part of the solutions businesses in healthcare must provide. Web and mobile tools that access patient information or configure and control the healthcare data management settings of connected devices are increasingly essential components of care delivery systems.

Understanding what it means to deliver HIPAA-compliant solutions will determine whether a business sinks or swims in this new reality.

10 Healthcare Data Management Truths Behind HIPAA Compliant Software

1. HIPAA Compliance Means Different Things in Different Contexts

The status of a software application’s HIPAA compliance depends on the context in which it is used to deliver services to patients.

A software application can have all of the important non-functional features required to deliver a HIPAA compliant solution, but will fail to maintain HIPAA-compliance if used improperly within a clinical setting.

Conversely, software that is missing features that would make it easier to maintain HIPAA compliance can be paired with manual processes that actually achieve HIPAA compliance.

2. Scaling Digital Health Solutions Increases Security Challenges

Stand-alone products that store private data locally are technically the most secure, as only those with physical access to the computer or device can access sensitive information. But this isn’t feasible at an organizational level.

But as digital health solutions expand, it is the job of the healthcare provider to protect the privacy of its patients. Delivering secure software solutions is essential to this role.

Hospitals can look to a centralized server to store information for access between rooms or across terminals over a secure network connection. Maintaining servers on the organization’s internal LAN and within its own firewalls is one of the best ways to mitigate security breaches.

Public-facing computers that store sensitive information are risky. In some cases, organizations choose to move them to “dumb” terminals where people can connect to terminal servers. Sensitive information is only stored on the central servers, and is therefore more secure.

3. You Need to Start With a “Secure By Default” Foundation

Data encryption is a key step towards more secure healthcare data management and an important software component of the HIPAA-compliant product.

There are several paths to data encryption — and a secure software foundation — that diminish the risk of failure in your security infrastructure.

By encrypting all data “on the wire” and all data “at rest,” business aren’t burdened by the need to show auditors how the solution encrypts the right data at the right time. In this case, their bases are covered. This approach does affect the performance and cost of the solution.

Some businesses instead opt to dedicate the extra effort involved in handling Personally Identifiable Information (PII) and Protected Health Information (PHI) differently than other data.

Other approaches exist, still:

• Many companies encrypt only the fields that require it, setting up a secure internal data center network that allows servers to communicate over secure, yet unencrypted, connections.
• Some divide data between PHI and non-PHI systems, applying higher security standards only to the PHI systems.
• A conservative approach that makes achieving HIPAA-compliancy easier is to connect all parts of the system over HTTPS/TLS 1.2 (or later) secured connections, regardless of whether they are within your firewall.

Always encrypt all data stored to databases or file systems, whether to your local mobile device or to your relational or NoSQL databases. The major relational and NoSQL databases all support encrypted options, so this is a straightforward solution for product-owners to pursue. There are Crypto APIs in mobile apps teams can use to accomplish the same end.

In terms of browser-based encryption, as of this writing, it is safest to assume TLS 1.2 is available across your customer base. But since TLS 1.3 was recently launched, it is not supported yet by all the major browsers. In time, it should become commonplace, but probably not until 2018.

4. There are Rewards — and Risks — to a Business Associate Agreement

The software applications you want to provide may require signing a Business Associate Agreement (BAA) with each of your clients. This agreement establishes the responsibility and accountability that you share with a client to secure users’ PHI and PII that your system stores.

Security Solutions & BAAs Can Get Complicated

Your solution will likely run on servers that your business either owns or manages. The management, change control, access, and data security practices of your clients need to factor in the hosted infrastructure and data centers that your organization provides.

Will your solution be hosted on a public Infrastructure-as-a-Service (IaaS) cloud or other private managed service other than your own physical data center?

Then you also need to extend that BAA by proxy to include your IaaS vendor and any possible third-party solution providers that manage HIPAA-compliancy on top of a private or public cloud service.

A solution that is installed on premise may not require this step — but this is increasingly uncommon as use of multitenant public cloud systems increases.

5: Don’t Overlook These Security Features in Healthcare Data Management

Too many companies overlook some essential security features that are necessary for optimal healthcare data management when they start to build a product or evaluate third party software solutions.

Must-Have Non-functional Security Features for Healthcare Data Management

• Role-based access control: each user’s role should allow access to only a limited portion of the data in the system. Access to system features depends on the user’s role within the software. This extends to providing granular permissions to features and functions of both the user interfaces (UI) and application programmer interfaces (API) provided by the system.
• Audit all data access: every action that affects the data in the system needs to be tracked (who viewed what information?). This can be implemented at a low level — but still to great effect — in the data access library or object relational mapper (ORM). Improperly executed data access audits can negatively impact system performance.
• Enforce unique user identification: the system should eliminate the possibility of accessing one account from multiple locations or devices at the same time. It should also detect patterns of use that indicate an account is being shared by more than one person.
• Emergency access procedures: if the system contains information that could be useful for providing care to a patient in critical condition, consider providing a way to access information during an emergency situation.
• Automatic logoff: if a screen is left unattended for a period of time, it needs to automatically log off from the system to prevent unauthorized access to sensitive data.

Must-have Functional Security Features for Healthcare Data Management

Aim to build a UI that lets administrators configure access and helps users comply with a variety of typical password policies, like the following:

• Minimum password strength (use metrics such as length or mix of characters)
• Password expiration date
• Prevent password reuse
• Password reset: both support personnel and end users need a UI that allows them to request a password reset; this needs to be done through a confirmed email address.
• Two-factor authentication: if your product is accessible over the public internet, then requiring two factor authentication is the best way to make passwords stronger. With two-factor authentication, the user must enter a password and a unique access code generated by a smartphone or some other device
• Electronic signature: if you have built a system that has all of the features described so far, then you can use the login portal you have already built to implement electronic signatures. The system should re-prompt the user to enter her password at the moment that she signs off on the document or process to help ensure that someone else has not hijacked the session, but the system doesn’t have to prompt for a second factor to be entered. At the time of this writing, the FDA will accept re-entry of the password as the digital signature.

These features will receive extra attention from any auditor who reviews your customers and purveyors of your software for HIPAA compliance. Make sure the written specifications, the test plan, and the test results of each release deployed to your production environment are available for review by the auditor. This is true for both HIPAA and FDA audits.

6: Build Multi-tenancy to Scale Secure Healthcare Data Management

For those used to buying or using on-premise systems, multi-tenancy may be a foreign concept. The fear is based on the idea that sensitive data intermingles with foreign data, making patients’ information inherently less secure.

But this isn’t necessarily true.

In multi-tenant solutions, no one gets direct access to the database in a way that allows someone to query all of the data. In secure approaches to healthcare data management, access to the data through APIs is restricted, which is how the systems guarantee that the data stays segregated.

Establishing multi-tenancy from the start ensures that every table in the database (assuming it is a relational database) has tenant_id as part of the primary key. Every data access method you build includes tenant_id, which determines how the data is filtered. Build the required reports into your solution’s API or into the application itself to get information that is always segregated by tenant.

Businesses that don’t choose a solution with baked-in multi-tenancy may end up paying more for a complicated solution later. They will need to maintain not only separate databases, but complete duplicate environments of redundant web and application servers.

If you have the choice, always build to be multi-tenant.

If absolutely necessary — and you have a client that is willing to pay for it — there are methods for sharing servers while maintaining separate databases, or for deploying the software you have with only one tenant using it.

However, it is never practical to add multi-tenancy later.

7. Track Behavior in Software For Secure Healthcare Data Management

The idea behind “least privilege” in terms of software is that no one should see more PHI than is required to do their job.

An auditor’s job is to prove that an organization is living by this principle. They make sure that every user has the correct role assigned and that each role has the right level of access for seeing or changing PHI. Furthermore, they look to verify that those privileges are not being abused by having people who use their access to view or change information for patients in ways that are unrelated to their immediate job assignments.

It’s impractical to manage assignments of individual patients so that no user of the system can see information for unrelated patients. But it is practical to have policies against abuse of such access, as long as compliance with those policies is trained and can be audited.

Either way, businesses building HIPAA compliant software need to be able to delineate access to audit logs for viewing, either by users or by patients, so that auditors can look for patterns of abuse.

8. The Cloud Can Minimize the Cost of Secure Healthcare Data Management

As healthcare-related software applications have evolved, product-owners have looked to maintaining strict oversight of physical and network security in order to mitigate security breaches of their systems.

But the cost and inconvenience of this approach, not to mention the reality of modern architectures, have necessitated a search for alternative solutions that allow an ease of access that healthcare providers demand and end-users seek.

The factor that will drive businesses to their preferred method of software deployment is simple: they choose what costs the least. Depending on its needs and/or legacy technologies, a business can consider looking to on-premise, public, managed services, or a hybrid cloud option to deliver services in the most cost effective manner.

Those pushing hardest to use public cloud infrastructure are also the businesses creating the safest and most secure solutions that exist, simply because their solutions receive the most scrutiny and have the highest bar to clear.

For too many companies, their internal operations find themselves challenged to keep their operational focus clear and to justify the level of automation that takes out the most error prone part of compliance — the people.

9. DevOps Matters to Effective Healthcare Data Management

Whether your business relies on an internally deployed virtualization environment, one hosted on servers placed in a colocation facility, or a public cloud service, it is important to make sure that the selected vendor provides an API and underlying management services to completely automate the process of provisioning and securing all networking, compute, and storage services.

The industry has started referring to this as “infrastructure as code”.

Until fairly recently, creating and maintaining a secure environment over time was the responsibility of people who documented — or attempted to — their steps in order to define a standard operating procedure (SOP) in advance. Then they would try to document that all steps were performed per the SOP.

But people make mistakes. Even when they do the right things in the correct order, they might fail to document these actions.

Infrastructure as code makes a winning alternative. And secure and scalable healthcare data management practices rely on it.

Automated audits track and log every action that every user might take when he or she makes changes to the overall environment. This exists in the public clouds and in virtualization software provided by companies like VMWare. This solution is practical as long as you are allowed to use or can afford one of these options.

Furthermore, a script that can be executed by a set of management APIs can accomplish the same end result as the SOPs previously designed and executed by people. It might take longer to build and test, but it can be re-executed reliability and quickly to provision and secure a new environment completely from scratch. If you have also automated the deployment process of the application to a clean environment, then you have the ability to completely recreate a production-representative environment in an automated, error-free fashion.

This is a form of insurance for disaster recovery. A failover that is not regularly tested is probably not going to work when it’s really needed. The same is true for an environment build. If your production environment can be routinely rebuilt and deployed, then it is more likely to support more effective development going forward.

This reality is also better for auditors, too.

The scripts themselves become the things that are audited and controlled. They can be reviewed to make sure that they accomplish the desired security goals, and change controlled so that an auditor can just review changes to them since the last audit to confirm that they are correct.

If they have any questions they can still review the audit history for the overall environment mentioned above, but about all they should see are steps taken by automated scripts that are run by people who are by role allowed that level of access.

10. HIPAA Compliance Is a Milestone on the Road to FDA Certification

Achieving FDA certification brings another layer of complexity to launching a connected health device. But significant overlap in the security features demanded by both HIPAA and FDA certifications, including the FDA’s Title 21 CFR Part 11, can come as a relief to many businesses.

Following the advice outlined above puts businesses on track to secure effectively their healthcare data management practices and achieve HIPAA compliance for their software. Furthermore, it helps them to meet the requirements imposed by the FDA, should the software and services also fall under that organization’s purview.

Software that is HIPAA compliant does not guarantee FDA certification, but it does bring businesses closer to that distinction if that is necessary to the viability of their product.

How Businesses With HIPAA Compliant Software Win the Healthcare Data Management Race

Beyond the essential functionality of your digital solution, the investments and partnerships necessary to the build software applications and services for healthcare markets are critical to a product’s long term success.

While many of the components necessary to secure healthcare data management frameworks and ensure HIPAA compliance for the software seem intuitive, knowing them, their benefits, and their costs allows business leaders to weigh the services and expertise offered by potential vendors before signing their name on the dotted line.

Understanding the key to building a HIPAA compliant solution helps business leaders meet their customer’s expectations and remain competitive in this fast moving marketplace.