GUIDE

What is a HIPAA-Compliant App?

So you’re looking to enter the healthcare market with a new, innovative app to transform an industry ripe for disruption? Well, you’ve come to the right place.

App development for building and launching healthcare applications is different from other industries. Why? Compliance and security. Any app that handles electronic Protected Health Information (ePHI) in any way is highly regulated, and for good reason.

Healthcare data breaches continue to grow, which can lead to lawsuits, revenue loss, and brand damage. More than 39 million individuals have been impacted by healthcare data breaches reported in the first half of 2023 alone. The US Department of Health and Human Services reports more than 900 data breaches affecting at least 500 people have occurred in the last 24 months. In fact, according to the 2019 Web Applications Security Statistics Report, 43% of healthcare organizations’ applications were rated “always vulnerable.”

And with this guide, we hope to set you up for success to ensure you’re not in the 50% “always vulnerable” group. HIPAA compliance is a great place to start, which we’ll cover in this guide.

We assume in building your application, you won’t be building everything from scratch but rather utilizing several different APIs, IaaS, PaaS, and SaaS products and vendors.

Healthcare terminology

Before we set in, let’s define the terms we’ll use throughout this guide.

HIPAA

HIPAA, an acronym for Health Insurance Portability and Accountability Act, is a law passed by the US Congress in 1996 with two primary purposes: one, to enable American workers to retain health insurance coverage when changing or losing their job (the portability part), and two, to ensure the protection and confidentiality of health information (the accountability part).

To achieve accountability among healthcare providers (e.g., doctors, dentists, etc.), health plan and health insurance organizations, and their associates (e.g., clearinghouses and cloud billing/storage providers), HIPAA regulations define four key rules1:
  • The Standards for Privacy of Individually Identifiable Health Information (“Privacy Rule”) gives patients key rights regarding their ePHI and identifies proper use and disclosure of PHI for patient care and other purposes.

  • The Security Standards for the Protection of Electronic Protected Health Information (“Security Rule”) outlines the physical, technical, and administrative safeguards for securing ePHI. As such, it is extremely relevant to data stream networks and will be the primary focus of this post.

  • The Enforcement Rule is, as the name implies, concerned with enforcing HIPAA. It deals with compliance, investigations, penalties for violations, and procedures for hearings.

  • The Breach Notification Rule requires “HIPAA-covered entities and their business associates to provide notification following a breach of unsecured protected health information.”

ePHI

PHI stands for “Protected Health Information” and includes any patient data that can be linked back to that specific individual. Any PHI data created, transmitted, received, or stored electronically is called Electronic PHI (ePHI) and must be handled with the appropriate security controls in compliance with HIPAA Security Rule requirements.

Unauthorized use or disclosure of PHI or ePHI by Covered Entities (e.g., hospitals, doctors, health insurance companies) and Business Associates (third parties such as cloud billing services) brings the risk of severe civil and criminal penalties.

For reference, the 18 types of patient information that are classified as ePHI are:

  1. Name

  2. Address

  3. Dates (of appointments, payments, etc.)

  4. Telephone number

  5. Fax number

  6. Email address

  7. Social Security number

  8. Medical record number

  9. Health plan/insurance beneficiary number

  10. Account number

  11. Certificate/license number

  12. Any vehicle identifiers (e.g., license plate number)

  13. Device identifiers and serial numbers

  14. Web URLs (Links)

  15. Internet Protocol (IP) address

  16. Biometric identifiers (finger / retinal / voice)

  17. Photographic images

  18. Any other characteristic that may be used to identify the individual uniquely 

Business Associate Agreement (BAA)

Business Associate Agreement (BAA) is a contract between a HIPAA-covered entity (the organization that is delivering the product) and HIPAA business associates (the organization or vendor working with the entity to store, transmit, or process PHI). It’s an agreement between you (the entity) and the technology and services (the business associate) you choose to power your app.

The BAA is a legal contract outlining how the business associate complies with HIPAA and the responsibilities and risks the business associate is taking on. BAAs include:

  • Services the business associate provides

  • Types of data they are interacting with 

HIPAA and Why It Matters

In a nutshell, HIPAA helps protect your PHI and holds those handling it liable. HIPAA sets rigorous and comprehensive guidelines for how PHI should be handled—setting minimum security measures to ensure privacy and fend off malicious parties.

Equally important, in choosing services and vendors that strictly adhere to HIPAA, you can focus on building a world-class healthcare product rather than spending substantial engineering resources on HIPAA compliance for your app. It follows the classic build vs. buy calculation: Why do it yourself when there are several solid vendors out there whose job is to do it for you? 

How HIPAA fits in infrastructure and the application itself

Whether you’re looking to build a HIPAA-compliant app using vendors and services or a HIPAA-compliant service of your own, you need to understand and implement controls on both the infrastructure and application levels. This section will discuss the controls needed for each level and areas to implement these controls. 

Controls to implement

  • End-to-end encryption with Transport Layer Security (TLS) for in/outbound packets and AES for packets.

  • Support for fine-grained, token-based access control. Token-based access control allows you to grant and revoke access to any messaging channel.

  • Purchase a TLS certificate; Distribute and manage the certificate securely.

  • Protect channels and topics (not covered by TLS)

  • Build an authorization system for users.

  • Consider AES and/or RSA encryption for payloads (not covered by TLS).

Now that you know better the controls necessary to comply with HIPAA rules, we’ll look at the different levels and where HIPAA fits in. 

Infrastructure

Infrastructure vendors need to implement reliability and security controls across their organizations. Here are the most important controls to achieve compliance:

  • Twelve-factor methodology.

  • Secure provisioning for multiple environments (like Kubernetes).

  • Set up service management, system monitoring, and ops alerting.

  • Create a load balancing scheme (like Nginx or HAProxy)

  • Segment data by channels or topics with encryption.

  • Find a store-and-forward solution for signal recovery, i.e., in-memory caching.

  • Implement a method to detect which data center and port to connect a client.

  • Figure which channels/topics to send/receive for a client.

  • Decide which platforms and languages you’ll support.

  • Create universal data serialization (JSON)

  • Detect data uplink that works across device types.

  • Determine Quality of Service and level of loss. Develop a data recovery scheme (or settle for “fire and forget”).

  • Decide APIs and capabilities you’ll need, then build them (i.e., presence detection).

As you can see, ensuring HIPAA compliance at the infrastructure level is a challenge that requires both expertise and significant maintenance. This is why many entities choose business associates to handle the infrastructure layer rather than manage it themselves. 

Application

The entity and business associate may more likely share responsibility for achieving compliance at the application level. Compliance on the application level is all about how the entity constructs and builds the app to interface with its end-user rather than the infrastructure behind the scenes powering it.

More robust HIPAA-compliant apps often provide APIs, SDKs, and professional services to help entities architect their applications to comply with HIPAA. 

Access management and authorization schemes

Token-based access control is essential at the application level. It allows you to handle your application's end users and devices and the channels they’re communicating over. Access management delivers fine-grained access control over who and what can transmit and receive data.

For example, take a publish/subscribe paradigm. The app can distribute tokens granting read or write access to specific data channels. This approach enables fine-grained control over which tokens are created, which devices receive those tokens, and to which data those tokens grant access. It also enables centralized control over when and how tokens are revoked, cutting off data stream access from non-paying customers or invalid users.

In doing so, the network effectively serves as a traffic cop, both authorizing device access and managing which devices can speak and listen on the network based on the tokens the network distributes. 

Secure Provisioning

When devices running your application start up, they’ll need a process to securely provision software and firmware upgrades. This keeps your entire system immunized from exploits as they’re patched out.

One common but unexpected security vulnerability: around 11 percent of users have turned off auto-updates on their phone and may not install updates if the app seems to function well when it’s initially set up. Often, users only opt to install firmware updates if something goes wrong. This leaves them vulnerable to security exploits, even if a fix is available. 

A publish/subscribe paradigm that uses the standard outbound ports 80 and 443 makes it easy to set up and provision healthcare apps securely. For example, when an app is active, it can subscribe to a designated announce channel and announce itself to the data delivery network. The server would return a private channel to communicate the device and server. The server can then set access rules on the channel and provision from there. All of this happens immediately, retaining the consumer’s expected plug-and-play experience.

Secure firmware updates

Once a mobile app is set up and provisioned, it’s also important to implement a way to securely and automatically update firmware for that app. If consumers have responsibility for downloading and installing firmware updates, there’s a chance they will not download critical updates.

Users may be vulnerable to malicious updates from unauthorized sources without a secure channel. To counter this eventuality, organizations should use the device’s secure publish/subscribe channels to instruct the app to download and install firmware updates when they become available.

The design model for real-time firmware updates in the field begins with the server broadcasting a firmware alert message on a channel that all devices can read securely. The master server then instructs the devices how to access and install the update: 

Considerations for choosing the right vendors and technologies

Before researching various services, frameworks, and vendors in mobile app development, ask yourself a couple of questions. These will help you decide how much of your app you want to build versus how much you want to buy out of the box.

  • Do you run your service or utilize a hosted service?

  • How much does it cost upfront? How much will it eventually cost at scale?

  • Is the hosted service reliable, secure, and scalable?

  • How mission-critical is uptime to my healthcare app?

  • Who on my team will maintain the infrastructure? Do they have the skills to make it scalable and secure?

  • Where does the service store the data, and who can access it?

These considerations expose how many resources are required to operate an in-house solution. This extends beyond headcount, factoring in time commitment to building, maintaining, and orchestrating the infrastructure. Building the infrastructure in-house may work for smaller projects and POCs, but a hosted solution is the way to go once you scale. 

If the price in the early stages is a concern, most hosted-solution providers also allow a free-forever sandbox pricing tier, where you can develop your app without paying. Once you’ve grown to a certain size, you pay as you grow. Hosted solutions are the way to go for companies looking to move fast and don’t want to worry about all the intricacies of networking and infrastructure. 

BAAs

As defined in our earlier terminology section, a BAA is an agreement between you (the entity) and the technology and services (the business associate) you choose to power your app. BAAs are required for HIPAA compliance, so ensuring that the technologies you use to power your app can sign the BAA is paramount.

Why?

Any company can claim they’re HIPAA-compliant. However, signing a BAA puts it in writing that your third-party contractors handle sensitive information. These agreements establish the security expectations between you and the vendor(s). If a vendor isn’t willing to sign a BAA, they aren’t confident in maintaining HIPAA compliance.

PubNub and Healthcare

PubNub provides APIs and infrastructure to power real-time messaging to help you modernize your health and safety applications with robust and secure real-time messaging capabilities. Whether enabling HIPAA-compliant chat, sending and receiving PHI confidently, or signaling and dispatching emergency response, PubNub provides the infrastructure and APIs to power it all.

We’ve built a real-time programmable network so developers can focus on what they’d rather do—like innovate their applications—without worrying about the ‘plumbing:’ whether or not the infrastructure is secure, scalable, and reliable. We’ve also worked hard to ensure our network is HIPAA-compliant so applications handling sensitive health information can safely use PubNub as their real-time infrastructure. 

Beyond HIPAA compliance

Outside of HIPAA, PubNub has taken additional strategies to ensure compliance with other data privacy laws:

E.U. Only Data Storage

PubNub allows any keyset to persist its data only in (at least two) E.U.-hosted data centers. Without this setting, by default, the customer’s data is persisted and replicated in multi-regional (multinational) data centers.

Model Clauses

By request from any PubNub customer on a large-scale plan, PubNub will enter into standard contractual clauses as provided by Articles 25 and 26 of the EU Data Privacy Directive 95/46/EC (known as “Model Clauses”) to allow for the lawful transfer of personal data from the EU to the United States. PubNub has secured reciprocal Model Clauses agreements from all its hosting providers.

EU-US Privacy Shield

PubNub has self-certified its participation in the EU-US Privacy Shield

SOC2

We’ve completed the SOC 2 Type II audit, meeting the security, availability, confidentiality, and privacy standards the American Institute of CPAs (AICPA) set.

ISO 27001

We've attained the international auditable ISO/IEC 27001:2013 standard by setting best practices for data privacy, security, and information governance.

General Data Protection Regulation (GDPR)

PubNub has engineered its services and code to comply with European data privacy regulations. 

PubNub has been HIPAA-compliant since 2015 and is the only HIPAA-compliant real-time network. We have many customers in the healthcare industry—such as New York Presbyterian, AthenaHealth, and OneDrop—who have chosen PubNub for their real-time needs.

Want to get building with PubNub? Here are a couple of ways to get started:

  1. Building HIPAA chat? Check out our PubNub Chat SDKs, which make it easy to build reliable, secure chat for web and mobile.

  2. Dashboards and monitoring? Check out EON, our framework for building dashboards.

  3. Want to talk to somebody? Our awesome success team and architects are ready for you. Contact us here.