HIPAA and Other Musts for Healthcare Software

Healthcare is one of the most promising business sectors. Deloitte predicts that global healthcare spending will rise at a CAGR of five percent from 2019 through 2023. And according to the Peter G. Peterson Foundation, the US spends more on healthcare per individual than other wealthy countries. 

In the era of digitalization, healthcare providers and their associates need to invest in advanced technologies to beat the competition. They also have to make sure they use these technologies in accordance with the law. If they don’t, it might cost them their business.

global healthcare spending

Why HIPAA violations could cost you a fortune

Because of the red tape, developing medical web app systems and mobile and desktop health applications isn’t as simple as developing other types of apps. This is particularly true for the US market, where medical IT solutions fall under the purview of HIPAA, an act pertaining to patient privacy and the security of medical data.

Federal fines for noncompliance with HIPAA requirements depend on the reasons for the violation. The consequences range from $100 to $50,000 per violation (or per record). The highest possible penalty is $1.5 million per year for violations of a given provision. You can check out a list by Compliancy Group to see all HIPAA fines the Department of Health and Human Services Office for Civil Rights imposed on healthcare organizations in 2019.

Before you start developing healthcare software, make sure you understand all applicable HIPAA titles and take them into account.  In this HIPAA compliance guide, we’ll highlight the criteria that indicate whether a particular medical app must comply with HIPAA and provide relevant recommendations.

hipaa violation penalty tiers

Read also: How to Develop an EHR System for Your Healthcare Business

Which medical apps need to comply with HIPAA rules?

There are three major criteria that define whether an app will be regulated by HIPAA:

criteria that define whether an app will be regulated by HIPAA

Let’s take a closer look at each of these criteria in the following checklist.


If an app is used by a covered entity such as a physician, hospital, or health insurance provider, it will most likely need to comply with HIPAA requirements.

For example, if you’re planning to design an app that will facilitate doctor-patient interactions, it will need to comply with HIPAA because a doctor and a hospital they work for are covered entities. At the same time, an app that simply helps a user follow a medication schedule doesn’t fall under HIPAA because there’s no covered entity involved (that is, if the patient inputs information themselves and no doctor sees it).

The Privacy Rule is one of the primary elements of HIPAA.
This rule defines what protected health information (PHI) is. The Privacy Rule also defines who is responsible for ensuring that PHI isn’t disclosed.

According to the Privacy Rule, two types of organizations are subject to HIPAA:

  1. Covered entities. These are health plans, healthcare clearinghouses, and healthcare providers who conduct certain financial and administrative transactions electronically, such as electronic billing and fund transfers, for which standards have been adopted by the Secretary of Health and Human Services.
  2. Business associates. These are all entities that store, collect, process, or transmit PHI on behalf of covered entities.

A covered entity has to sign a HIPAA business associate agreement with each of their business partners to ensure the security of PHI and overall HIPAA compliance. Want to know whether a particular entity is regulated by HIPAA? Check out this documentation from the U.S. Department of Health and Human Services.

who has to be hipaa compliant


HIPAA is primarily interested in protected health information, which is any medical information that can be used to identify an individual as well as data that is created, used, or disclosed in the course of providing healthcare managed services, such as diagnosis or treatment.

PHI includes two parts: medical data and personally identifiable information. Only when personally identifiable information is connected with medical data does the medical data become PHI.

Take, for instance, an app helping physicians diagnose skin diseases by studying anonymous photos. Such an application doesn’t deal with PHI, as it’s impossible to identify the patients. However, if you mention a patient’s name or address in relation to an image, all this information becomes PHI.

According to the Department of Health and Human Services, there are 18 classes of personal information that (in combination with health data) constitute PHI:

 classes of personal information

In short: If the information stored and shared in an app is individually identifiable (e.g. a profile that contains a user’s first and last name and can be traced back to a particular patient), then the app must comply with HIPAA requirements. The same applies when all sensitive data is stored on a third-party server.

Software security

The last criteria that determines whether a medical app falls under HIPAA is directly related to the technology employed and covers a number of standards for protecting and controlling access to electronic protected health information (ePHI).

These standards include audit, integrity, and access controls. Let’s look at each of them.

Audit controls 

The audit controls standard means that a medical app developer needs to implement hardware, software, and/or procedural mechanisms that record and examine activities in systems that contain or use ePHI.

The Department of Health and Human Services states that the standard doesn’t explain what data you should collect or how often you should check it. Instead, it recommends you use your risk analysis system and technical infrastructure to define the most suitable audit controls for your systems.

So as not to be fined for violating the audit controls standard, you should conduct regular risk assessments. In addition, you should regularly review records of system activity, including audit logs, access reports, and security incident tracking reports.

Integrity of ePHI

The integrity standard requires a covered entity to implement policies and procedures to protect ePHI from improper alteration or destruction.

Essential things to take into account when meeting ePHI integrity requirements include whether available information systems provide features or processes for automatically checking data integrity. These include checksum verification or digital signatures and providing electronic mechanisms to ensure the integrity of ePHI. 

Access controls 

In order to discuss the access controls standard, let’s look at its implementation requirements in greater detail:

1. Unique user identification. It’s important to note that the format of the user id doesn’t matter as much as the fact that no one other than the user should know it. In this regard, an email address isn’t a fitting option.

Proof of identity for authentication can be implemented in the following ways:

ways of implementing proof of identity for authentication

2. Emergency access procedure. An emergency is a situation in which normal environmental systems, such as electrical power, have been severely damaged or rendered inoperative due to a natural or manmade disaster. In the case of an emergency, there has to be a way for covered entities to gain access to the needed ePHI.

3. Automatic logoff. When an app is left unattended for a long period of time, automatic logoff can serve as an effective way to prevent unauthorized users from accessing ePHI.

Medical app providers should also make sure no app notifications that appear on a user’s device contain sensitive health information. Notifications can pop up even if a phone isn’t active, which means they can potentially violate patient privacy.

Encryption and decryption

Encrypt your data at all stages. Some apps allow for the exchange of information with doctors and medical facilities through email. But using email for sending sensitive data is generally not permitted by HIPAA, as the majority of email systems do not support encryption. There are some exceptions, however.

Virtru, for example, is a service specifically designed for patients and doctors. It offers an easy and secure way for medical organizations to send messages and attachments that comply with HIPAA’s ePHI requirements. Virtru integrates into email services that physicians, administrators, and patients are already using and safeguards all their networking options.

According to HIPAA, the information in a medical app should be encrypted at all times – at rest, in transit, and on the client side.

Data at rest. Electronic data stored somewhere and not used by and/or sent to anyone is at rest. To protect your locally stored data, use a strong at-rest encryption standard. Also, make sure data stored in SaaS and cloud-based services is also encrypted at rest. Reputable cloud computing platforms like Google Cloud and Amazon Web Services (AWS) ensure smooth data at rest encryption. 

Data in transit. Data that’s being transmitted from one place to another is in transit. Transmission must be implemented using strong in-transit encryption standards like AWS Transport Layer Security 1.2 and must be performed via secure connections. 

Data on clients. Data that’s waiting to be transmitted from a user’s device to a server is currently on the client side. AWS provides an Amazon S3 client-side encryption feature to encrypt data before uploading it to the Amazon Simple Storage Service (Amazon S3).

There are some other criteria to consider when determining compliance with HIPAA requirements for software for the US market. For more detailed and technical guidelines, see Security Standards: Technical Safeguards published by the Department of Health and Human Services.

PHI backup, storage, and transmission

Backups are crucial for PHI integrity. Database corruption or a server crash are likely to cripple your data. To avoid this, we suggest having several copies of your PHI stored in different places.

Create a PHI backup plan that will define the probability of your PHI being compromised. Back up high- and medium-risk data every day and store it in a secure location. You should also ensure your ability to restore data if it’s damaged, so periodically test your system’s recovery capabilities. 

Additionally, log the system’s downtime and any failures to back up data. Activity logs should also be stored and should be in a human-readable format. Keep in mind that backups themselves should also comply with HIPAA security standards for health care. 

Speaking of PHI transmission, you should protect the data you transmit outside your system as well as data transmitted between different tiers of your own system. To ensure the needed protection, force HTTPS for all communications (or at least for signup screens that contain PHI and authorization cookies). 

The secure HTTPS communication protocol encrypts data with SSL/TLS. Using an algorithm, the protocol converts PHI into a string of characters that are meaningless without the decryption key. An SSL certificate ties this key to your online identity.

For more information on how to ensure the security of your software, read our comprehensive guide to data protection. Let’s see how to build your project architecture to ensure the necessary security, privacy, and compliance. 

http vs https

Technologies used for HIPAA-compliant applications

The further out you foresee the evolution of your healthcare app, the better your final product will be. A vision for your app will help you wisely select a technology stack. Criteria for selecting technologies for building HIPAA-compliant software depend on the product specifics and the expertise of your developers and DevOps engineers. But we have some tips from our own practice to simplify the choice.

Use reactive microservices to ensure scalability. Apps can have a monolithic structure or a polylithic structure. Each type has its pros and cons. But healthcare systems are usually complex, so having a monolithic structure often restricts their productivity and limits their scale. When complexity is high, building a reactive polylithic app is the best option. This structure involves the use of microservices that redistribute the workload and streamline the workflow of the complex system. Implementing a reactive microservice architecture will help you create a flexible and scalable healthcare app. 

Be prepared to adopt uncommon technologies. When working on a healthcare project, be ready to use rare technologies like SOAP, FTP-based file exchange, and RPC calls on top of REST. These are standard practice in the healthcare industry.

4 principles governing reactive systems

Choose solutions for securely sharing information. A VPN allows a computer to communicate securely and privately with other authorized computers. Always use a VPN for transferring data. Otherwise, a file sent online might be intercepted by cybercriminals.

There’s also Health Level 7 (HL7), which is a set of international standards for transferring medical and administrative data between apps used by healthcare providers. Following HL7 standards enables software and healthcare providers to store and move data securely and simply. 

In addition, you’ll have to decide where to host your product. We’re sticklers when it comes to AWS and are ready to defend this choice. 

Why choose Amazon Web Services and how to deploy an app there?

AWS deals with well-known technologies and products, which means that new developers or teams can easily get to work on your project. Here are more arguments in support of AWS for hosting a healthcare app:

HIPAA compliance. Amazon guarantees that all the data it stores is encrypted. You can deploy a HIPAA-compliant cloud architecture easily using an AWS Quick Start. You can also refer to a detailed paper by Amazon on how to build a HIPAA-compliant structure using AWS services. 

Complete coverage of needs. AWS provides all services you might need for your project including for sending emails (SES), sending SMS notifications (SNS), and creating data warehouses (Redshift). It also features a fully managed Elasticsearch Service and a Relational Database Service

Support and customized pricing. You can rely on AWS experts, who can consult on any issues you might face. AWS also offers flexible and predictable pricing.

How to deploy a healthcare app on AWS? These are the technologies we use for healthcare projects: 

aws technologies for a healthcare app

These two sources along with our recommendations above will help in the development of electronic health systems:

  1. Rancher (enterprise Kubernetes management) is an alternative to ECS for working with clusters.
  2. A Docker-powered PaaS will help you create and manage the app life cycle.

Read also: Our Healthcare Software Development Services 

Wearables and medical devices

Wearable devices are an essential part of the connected health trend, and a lot of people are concerned about potential privacy breaches related to data shared by wearables. Do HIPAA regulations apply to wearable devices? The answer is yes and no. Imagine a situation when a user goes to a store and purchases a wearable device (a fitness tracker, for example). The company that made this device is not a covered HIPAA entity, and therefore the data this device collects and shares will not be protected under HIPAA.

At the same time, if a user were to get a wearable from his doctor in the hospital (for example, a portable heart rate monitor), the health data this device collected would be covered by HIPAA because it came from a hospital management system (i.e. an entity covered by HIPAA).

Keep in mind that HIPAA is not the only set of rules that healthcare app developers should be familiar with. When developing medical software for wearable devices in the US market, it’s important to make sure they also comply with applicable Food and Drug Administration (FDA) regulations, not only with HIPAA.

An agency of the United States Department of Health and Human Services, the FDA is responsible for protecting public health through the regulation and supervision of food safety, medications, medical devices, and everything else related to food and drugs.

From the FDA’s perspective, a mobile app can be defined as a medical app if:

  1. it’s used as an accessory to a regulated medical device; or
  2. it’s used to transform a mobile platform into a regulated medical device.

​In both of these cases, FDA guidelines for medical devices will also apply to the mobile app.

It’s evident that mHealth apps will continue increasing in importance for the healthcare industry. Medical apps are beneficial for both medical management systems and medical app developers.

Even though HIPAA and other relevant laws and regulations do seem cumbersome, by complying with them, eHealth developers can build future-proof infrastructures and offer innovative medical tech solutions for a booming market.

4.3/ 5.0
Article rating
Remember those Facebook reactions? Well, we aren't Facebook but we love reactions too. They can give us valuable insights on how to improve what we're doing. Would you tell us how you feel about this article?
Want to create a healthcare app?

We’re excited to help

Get in touch

We use cookies to personalize our service and to improve your experience on the website and its subdomains. We also use this information for analytics.