Building applications for healthcare can be daunting. There are so many stories about patient data breaches, cyberattacks, and ransomware that can destroy the business behind an application. You certainly don’t want those headlines to involve your data as a patient, or your business as an application developer!
Moreover, building applications for healthcare that are HIPAA compliant can be incredibly challenging. It requires coordinated work between your business, legal, healthcare, and technology teams, as well as the support of vendors and contractors that you work with.
Fortunately, there are many Communication Platform as a Service (CPaaS) solutions that provide a platform upon which we can build HIPAA compliant healthcare video applications. This includes options like Vonage and Twilio, who both offer video solutions that can be incorporated into your application as a video solution that is already capable of being used in a HIPAA compliant application.
Alternatively, if you don’t mind managing your own infrastructure, you can use open source media servers and implement them in a HIPAA compliant manner. Either way, there are some basics about HIPAA compliance that you need to know.
In this post, we’ll explore some of the basics of HIPAA compliance in video applications.
Here are the key areas we’ll cover:
- A little background on HIPAA compliance
- Subcontractor and vendor agreements
- Data encryption requirements
- Application security and access controls
- Video specific concerns
- Breach notification processes
- Conducting regular audits
Some of these items are technical in nature. Other items touch on business processes outside of your application code that you’ll need to address in order to refer to your application as HIPAA compliant.
Note that HIPAA compliance and healthcare data security are complex topics and care must be taken in your individual situation. This post will give you a solid starting point, but it is simply based on our experience as a software development company building healthcare video applications for multiple clients and use cases.
We strongly recommend working with a legal team with specific experience in telehealth applications to understand the nuances of your particular situation. This blog post is not a substitute for professional legal advice, nor is it intended to be a comprehensive listing of all aspects of HIPAA compliance. This post is only a starting point to help you think through issues that may come up as you build your telehealth application.
This information is also available as a WebRTC Tips by WebRTC.ventures video:
Background on HIPAA
HIPAA compliance is not a single box you check at the beginning of your software development life cycle. It’s also not a certification that you hang on the office wall. In fact, there’s no central certification authority that officially determines you are HIPAA compliant.
HIPAA compliance refers to applications that meet the rules and regulations of the 1996 US law called the Health Insurance Portability and Accountability Act. If 1996 sounds like a long time ago to you in internet terms, it certainly was, and that’s one of the biggest challenges with HIPAA compliance. We’re talking about guidelines that were written with good intentions, but don’t line up directly with modern technology or programming languages. That means there is no simple answer on how to be HIPAA compliant, and the law does not provide an easy checklist to follow.
When you say that you are HIPAA compliant, it’s essentially a self-certification that your company has done everything to build your application in line with HIPAA guidelines. If you leave something out, and that results in data breaches, then you can face business losses and fines. It’s not something to be taken lightly.
Covered Entities
HIPAA compliance refers to something called “Covered Entities,” which means those entities who are required to adhere to HIPAA rules. Consult with legal counsel on whether your organization meets the definition of a covered entity. Typically, a covered entity refers to more than just the actual medical organizations and medical professionals using your application. Anyone who is storing patient data or working with patient data is likely also a covered entity.
Business Associate Agreements (BAA) must be signed by all organizations or individuals who work with the data. This means you may need any development company you’re working with or server hosting business to also sign BAA’s as a subcontractor or vendor to you, in order to call your application HIPAA compliant. Depending on the advice of your legal counsel, you may also need this with cloud providers you are using or engineers you hire to build your app.
Business Associate Agreements and Architectural Considerations
If you’re working with a CPaaS, you’ll want to talk with their sales teams about HIPAA compliance to see which offerings you need to purchase in order to have them put a BAA in place with you.
Not all CPaaS products are necessarily eligible for HIPAA related work. Twilio offers this list of their HIPAA Eligible Products and Services from Twilio. Vonage also has a page about their HIPAA Compliant SMS and Video options. They offer an Enterprise plan to better ensure support for larger clients and HIPAA applications. For more details, contact their sales teams directly.
Assuming you have a BAA in place with your CPaaS and you are using the correct services following their guidelines, then you can say that the Video portion of your application is HIPAA compliant. However, that doesn’t make your overall application compliant. Application security in general, and HIPAA compliance specifically, is an area where the old adage applies that “a chain is only as strong as its weakest link.” The following tips cover other items you need to keep in mind around your use of the APIs provided by your CPaaS.
Protected Health Information & Data Encryption
Protected Health Information (PHI) is an important concept in HIPAA compliance. Basically, your application architecture needs to ensure that you don’t share information that can be used to identify individual patients. An obvious application of this concept is to never publicly share a listing of patients or their data (patient data can only be shared with relevant medical professionals). But it goes deeper than that into your application design. What if a hacker accesses your database? Could they access patient information?
Data encryption at rest
All data should be encrypted in the database so that even if someone accesses lower level systems, they cannot easily gather patient data.
All data that can be used to identify patients should be “encrypted at rest” in your data store. This includes, but is not limited to, items like social security numbers, addresses, and phone numbers.
Data encryption in transit
Data is vulnerable not just in your database, but also as it traverses through your application. The most common way to protect patient data as it travels over the internet is to use HTTPS connections so the connection is encrypted using SSL protocols. Using HTTPS is not only necessary for HIPAA compliance, but a good technical practice for any application.
Beyond HTTPS, there are other things you should consider about the data you share in your application. For instance, it’s not a good idea to use unencrypted data in query strings or in signaling requests to set up your video call. If you need to pass something like a patient ID or name in order to set up a video conversation, encrypt that data first.
Application Security and Access Controls
This is a very important area to consider: who has access to your application and for what purposes?
All application users should have their own uniquely identified user accounts with passwords following strong rules and requiring users to regularly update their passwords. You can also consider Two Factor Authentication (2FA) to provide extra assurance the user is who they claim to be.
It’s also best practice to design a roles and responsibilities model into your application. If all users have the same privileges, your application will be at higher risk of PHI data breaches. Make sure users only have access to the patient data that they are authorized to see, and cannot modify that data without a record of those changes being made into a system log. This is also referred to as the “Principle of Least Privilege,” which says that a user should only be given enough privileges to complete the task at hand and nothing more.
Video Specific HIPAA Concerns
When the HIPAA rules were initially conceived in 1996, there was no such thing as live video on the internet. We have come a long way since then! So, while the rules don’t explicitly discuss video content, they can be extrapolated to see how video should be treated.
First, like any other form of data, video should be encrypted both in transit and at rest. The “in transit” part is relatively easy because it’s built into HTTPS protocols and the WebRTC standard itself. All video, audio, and data exchanged on the peer-to-peer channels of the WebRTC standard are encrypted by default, which is a key reason why healthcare has long been an early adopter of WebRTC based video technologies.
Many WebRTC applications also use media servers to handle much of your video traffic, allowing for features such as group chats and recording which are not possible in peer-to-peer WebRTC connections. Because those media servers will be in between the participants of a video call, it’s important those media servers are also HIPAA compliant. That is one of the big benefits of using a CPaaS in your HIPAA compliant application: they are agreeing to keep their media servers compliant when they sign a BAA with you.
That covers video data in transit, but what about at rest? In many video use cases, you are not storing any video data and so there’s nothing to be concerned about. But if you use features such as call recording, then you also need to consider how you store those recordings once you retrieve them from the CPaaS servers. If you will be retaining those recordings in cloud services such as Amazon S3 buckets, make sure you put access policies on those recording files to restrict who can access them.
It’s not sufficient to assume that a long GUID style filename creates enough obfuscation to make your video recording secure. Just like any other data, you must protect your video recordings with strict application security and access control policies.
Breach Notification Processes
Some of the most important aspects of HIPAA compliance are not technical at all, but more paperwork and policy driven. This includes having set policies for how you notify application users of a data breach.
Unfortunately even HIPAA compliant apps have data breaches, and so it’s very important that you have policies defined up front for how to handle that. Appoint an Information Security Officer, which is someone who anyone in your company will notify when they detect a data breach. In addition, you must have specific policies in place for how you will notify customers in short order.
There are specific rules defining what constitutes a data breach, and who you notify based on the size of that data breach. A data breach can be the result of someone hacking your application, or an employee not following proper procedures. Based on their understanding of the rules, the medical organization or other covered entity must decide if the event requires notification. But ultimately the US Department of Health and Human Services can overrule a company’s decision if the breach requires notification or not, as in this recent example where an employee accidentally shared patient data with a personal google drive account. Consult the HIPAA Breach Notification rules for further details.
Regular Audits
HIPAA compliance is something you need to revisit on a regular basis. Your company should have an Information Security Officer who regularly audits your systems, improves the security processes, and keeps all documentation about security procedures, audits conducted, and notification processes up to date.
Outside firms can be engaged to audit your systems regularly, but you still need to have internal technology professionals dedicated to internal audits as well, and who are involved in ongoing application decisions so that an application update doesn’t introduce a new vulnerability. In short, HIPAA compliance is just one part of your security procedures, and as such is a never ending process.
HITRUST
You may have noticed that not everything about HIPAA compliance is cut and dry, which is understandable when it’s governed by a law written before widespread adoption of the internet in healthcare. Subsequent enhancements to the HIPAA rules, including a 2009 law referred to as HITECH, have changed how covered entities must handle the notifications and increased associated fines. But there is still no single way to certify you are HIPAA compliant.
If you want to go a step further than HIPAA compliance, and if you would like to have an actual certificate to hang on a wall, then look into HITRUST certification. There are many consulting companies that can audit your IT systems and applications to certify you according to this private industry alliance’s standards. The standards covered by HITRUST include HIPAA, as well as other broader security standards such as the PCI standard necessary for those processing credit card information.
The primary advantage of HITRUST is that this alliance has compiled more specific advice on how to implement HIPAA compliance and so can give you more up to date and actionable advice than reading the HIPAA regulations can provide on their own.
It’s worth pointing out that even obtaining a HITRUST certification does not mean you are exempted from any HIPAA notification rules, nor that you are done with HIPAA compliance. This will still be an ongoing process.
Conclusion
HIPAA compliance is not simple, and it’s more than just a technology problem. It will require coordinated work between your business, legal, healthcare and technology teams, as well as the support of vendors and contractors that you work with. Thankfully, WebRTC based video solutions allow you to build high quality video into your healthcare application while meeting HIPAA guidelines.
Way back when our team began to specialize in web real-time communications, one of the more popular use cases to knock on our door was telehealth. We built on our deep experience building custom telehealth solutions to create the SimplyDoc Telehealth Starter Kit which reduces your cost and time to market by starting farther down the development cycle. Looking for a completely custom telehealth application that is truly your own? We can do that, too, using WebRTC open-source projects like Jitsi, or Janus, or on top of a CPaaS platform. Contact WebRTC.ventures today!
