This article is dedicated primarily to HIPAA-compliant mobile app development but may be of interest to any healthcare provider or software developer.
Smartphones and wearables are widely used for telehealth, and even hospitals and insurance companies’ adoption of mobile devices is growing. Simultaneously, as data breaches become more problematic, the developers of healthcare apps for mobile and wearable devices (mHealth) should increasingly focus on patients’ data security and privacy.
In the U.S., they are regulated by HIPAA (meaning Health Insurance Portability and Accountability Act of 1996). It governs the management, storage, and transmission of protected health information (PHI). Since September 2013, all doctors, hospitals, insurers, and other entities that deal with PHI have been obliged to follow HIPAA guidelines to ensure compliance.
Healthcare app developers are primarily preoccupied with the HIPAA Privacy and Security Rules published by the Department of Health and Human Services (HHS). The first requires protection for certain electronically stored or transferred health-related information. The second outlines the safeguards whose implementation is necessary for HIPAA compliance.
The efforts of software developers and others to meet the national standards set in the Rules are overseen by the HHS Office for Civil Rights (OCR). There is no governmental structure responsible for formal HIPAA certification of organizations and products, but it spawned a whole industry encompassing HIPAA training, audits, consulting, legal assistance, and more.
This article offers advice on how a healthcare or health insurance app can meet HIPAA requirements so that it becomes popular and profitable and doesn’t subject you to the OCR sanctions. Many of the tips will be relevant for apps targeting other countries as well.
The first step is to understand all applicable terms and whether HIPAA software requirements apply to your mHealth app in the first place.
The need for HIPAA compliance is determined based on two criteria:
The healthcare software domain interacts with two types of information:
I. Сonsumer health information (CHI).
This type includes data that apps can gather even from a fitness tracker, e.g., heart rate readings, the number of steps walked, calories burnt, etc.
II. Protected health information (PHI).
PHI consists of health data and personal identifiers. The first type of data relates to a patient’s physical or mental health or condition and to payments for the healthcare. This encompasses doctor bills, emails, lab test results, MRI scans, and other data generated, utilized, or disclosed when healthcare services are provided. Health data also includes information related to patients’ healthcare insurance coverage and even geolocation details that locate a person within a territory smaller than a state.
The mere fact that an individual has received medical services may count, but health data becomes PHI only in combination with personally identifiable information.
The rule of thumb is: if an application collects, processes, stores, or transfers any PHI, HIPAA software compliance is mandatory.
According to Privacy Rule, two types of organizations should seek HIPAA compliance:
I. Covered entities
Covered entities include:
An application designed for use by a covered entity, such as communication between doctors and patients, will be most likely subject to the regulation. HIPAA software requirements may apply even to apps that deal with hospital employee records and education records for medical institutions.
II. Business associates
These persons or organizations collect, store, process, or transfer individually identifiable health information as part of a service to, or on behalf of, a covered entity. This category comprises attorneys, accountants, billing firms, software vendors, hosting/data storage, email, and encrypted email services, healthcare app developers, and other third parties that may handle patients’ data even unintentionally.
When in doubt as to the laws and regulations to follow, these instruments may prove useful:
Anybody who qualifies as a covered entity or business associate must:
Now, let’s focus on HIPAA software requirements that are critical for web and mobile app developers.
Software developers and IT vendors that deal with HIPAA-covered entities and PHI should strive to implement all applicable administrative, physical, and technical safeguards mentioned above.
For example, the physical data standards apply to the physical access to ePHI that is stored in the cloud, remote data center, on-premise server, and even PCs, laptops, tablets, or smartphones. They require protection of the back-end, a network for data transfer, and ensuring that ePHI cannot be compromised if mobile devices are hacked, lost, or stolen.
Nowadays, much of the burden of physical security standards has been taken over by HIPAA-compliant cloud hosting companies like Amazon Web Services (AWS), Firehost, Rackspace, or TrueVault. Other aspects are handled by software developers’ internal rules regarding access to PHI and access management. You can find basic information relating to administrative safeguards and physical data security here.
This article is primarily focused on HIPAA information technology requirements that distinguish the development of HIPAA-compliant mobile apps from other types of software. The modifications in the development process, app features, and design are mostly related to the technical safeguards – the ideal workflow an app must follow in handling ePHI.
The applicable requirements and best practices can be divided into three groups:
1. Access control requirements:
2. Transmission security:
3. Audit and integrity standards:
The technical safeguards determine the mechanisms used to secure and control access to ePHI that can be shared between or stored on servers and devices. For example, the technical policies for HIPAA compliance require the encryption of ePHI at rest and in transit once it leaves the organization’s internal firewalled servers. In the event of a data breach, it will preclude bad guys from deciphering, reading, and using this data.
Before we delve into the specifics of HIPAA-compliant app development, it will be useful to recollect why businesses put up with the increasing complexity and cost of HIPAA compliance.
What is HIPAA compliance all about? The benefits for healthcare providers and patients, such as identity theft prevention, are undeniable. The stringent regulations also urge developers to adopt a far-reaching and innovative approach to infrastructures and solutions, making them more competitive. However, the main goal of businesses and institutions is to minimize the financial risks.
HIPAA compliance mistakes come at a high price: the penalties for bypassing the HIPAA compliance rules and regulations start from $120 per violation and can reach $1,806,757 per year.
The leading causes of security breaches reportedly included:
Each person whose data was exposed makes a separate case. For example, in 2021, a health insurer agreed to pay $5,1 million to settle a breach that affected nearly 9,4 million records.
For startups, such consequences of non-compliance in healthcare data protection can prove deadly. Luckily, even beginners can leverage the wealth of knowledge amassed over the years.
The following recommendations are relevant to healthcare providers, insurers, health tech companies, and other entities bound to ensure HIPAA compliance.
This best practice can be formulated as follows:
An entity that gathers and keeps superfluous information not only fails HIPAA standards but also wastes resources on this data storage and protection. Continually assess how much information your app actually needs to operate and bring value to the users.
According to the HIPAA Privacy Rule, no person should see more information than their job requires. (The rule also specifies the patient’s rights to view and grant or restrict access to their own information.)
HIPAA compliance is easier to achieve when all trackable user data is cloud-based and stored in secure servers. Eliminate unnecessary collection and storage, track only the data that you really need, and exclude from your analytics any data that may violate HIPAA rules. Limit the sharing of PHI to the minimum required to accomplish the intended tasks.
Figure out which of the data can be categorized as PHI and see what PHI you can avoid storing or transferring through your app.
It’s recommended that all patients’ health data should be kept in a separate database, away from other app data. That way, you can avoid constantly encrypting and decrypting every byte.
Teach your employees to identify cyber-attacks, take the necessary proactive and reactive measures, and report incidents. You also need a sanctions policy in place, should employees bypass HIPAA compliance rules.
Designate a security and privacy officer to take precautions for securing all data handled by the organization and to guide employee behavior accordingly. They should systematically assess the risks and detect the organization’s vulnerabilities and other factors that jeopardize the availability, confidentiality, and integrity of the PHI.
First of all, determine where PHI comes from and where it is stored, maintained, and transferred. Find out what security threats existing vulnerabilities pose and try to estimate their potential impact, as well as the impact of a possible data breach. Prioritize the risks to address.
Scrutinize the existing security practices and their application. Define the most suitable audit controls for your systems that contain or use ePHI.
Share the risk analysis report across the organization, discuss it with competent persons, and develop an actionable plan including protective measures and alleviation of the identified issues.
Eliminate non-conformities progressing from minor to major issues. You may start with implementing two-factor authentication, sign a BAA with your backup provider, then organize relevant HIPAA training for the employees, and so on.
PHI that is no longer needed should be erased. As long as a copy of such PHI remains in one of your backups, the data isn’t considered “disposed of.” Archived and backup data can also hide in photocopiers, scanners, MRI or ultrasound machines, laptops and other portable devices, memory cards, USB flash drives, DVDs/CDs, flash memory in motherboards and network cards, ROM or RAM, and even floppy disks.
Developers should take measures to dispose of all the unused data in a safe, non-retrievable manner. They should also properly destroy the media that contain PHI before throwing or giving them away. In flash-based memory drives, such as USB sticks, data is spread over the media, making it difficult to erase sensitive information with regular data destruction software. Manufacturer utilities, such as Samsung Magician, can do the job.
Your organization and software products will keep evolving, and so should their security.
Focus on the HIPAA requirements from the initial stages of your mHealth app development and check if you need to comply with any other privacy and security regulations before you set off.
Document all your efforts to protect PHI throughout the development process and beyond.
Regular technical and non-technical evaluations of such efforts will be required. The regulator has published an audit protocol that can help you assess your HIPAA compliance.
Set up procedures for monitoring HIPAA issues as you go. You will need to track PHI access, detect security issues, regularly reassess the effectiveness of security measures, and estimate the potential risks to compromising ePHI.
For each release of your app, provide specifications, plans to test its security, and their results.
It may be beneficial to employ network monitoring software. As a minimum, such tools can track logins into the system and, at maximum, automatically provide compliance reports.
The following chapter will describe some app features supporting compliance with HIPAA and technology that software developers can leverage to implement such features.
The minimum list of features that are essential to HIPAA-compliant products includes the following:
Any system that stores PHI should restrict viewing and alterations to the information.
Role-based access control allows app developers to implement those restrictions by granting to groups of users, e.g., doctors, lab technicians, or administrators, privileges essential to their jobs.
Another way to accomplish this is to assign a unique ID for identifying and tracking the activities of each user accessing your system. Then, you can grant each user a set of privileges allowing them to view or modify specific data, and then regulate access to individual database entities and URLs.
The simplest form of user-based access control consists of two database tables: the list of privileges with their IDs and the distribution of those privileges to individual users. In the above case, a doctor (user ID 1) is entitled to create, view, and update medical records; the lab technician (user ID 2) can only update them.
After assigning privileges, app developers need to enforce regular authentication and preclude access to the system without authentication.
Blockchain technology may also prove helpful for the prevention of tampering with patients’ data.
Several HIPAA-compliant ways to implement proof of identity are recommended:
An app may check these requirements on the signup screen and decline weak passwords.
Multi-factor authentication combining a secure password/PIN with other verification methods reinforces an app’s security. The second element can be anything from a one-use security code received via SMS to a biometric scanner. The idea is simple but effective: if hackers obtain a user’s password, they’ll also have to steal their device or fingerprints to access sensitive data.
Other ways to ensure that only authorized personnel can access the data include regular change of passwords by employees and access control audits.
An emergency occurs when a natural or man-made disaster disrupts the operations of essential services and networks. However, healthcare providers should be able to access and protect ePHI under all circumstances.
Neither should authorization get in the way of aiding patients in an emergency. For example, a doctor may need to urgently view a patient’s records. It’s reasonable to allow authorized users to access any data they need when the situation requires so while the system automatically notifies several other people and launches a review procedure.
A system containing or using PHI should automatically terminate a session after several minutes of inactivity in the app. This protects PHI in the case a user loses their device while logged in. To continue, a user would have to re-enter their password or be verified in another way.
The encryption of all data and communications with the apps is the best way to ensure PHI integrity. iOS and Android devices tend to store data on disks when the network is offline. Whether at rest locally on smartphones, stored with a SaaS or cloud server, or traveling between apps and servers, all data needs encryption. Even if hackers steal patient data, it will make no sense to them without the decryption keys.
If your app asks for sensitive user data, you need to embed a system for automatic encryption of all the data, whether it is stored locally or transmitted to a central server.
For the encryption of data stored in the software system – backups, databases, and logs – experts can leverage RSA and AES algorithms and encrypted databases like SQLCipher.
For the end-to-end encryption of data during transmission, you can use services like AWS’ Amazon S3 or Google Cloud that run Transport Layer Security 1.2. TLS can be enough by itself, but AES 256-bit encryption can fortify it further.
Gmail doesn’t provide the necessary protection for PHI sent via emails. If you send emails beyond your firewalled server, they need to be encrypted. Browser extensions, the OpenPGP encryption method, or a HIPAA-compliant email service like Paubox that can do the job.
All parties should also encrypt the hard drives of all devices that contain PHI. Encryption tools like BitLocker for Windows or FileVault for Mac OS can do this.
To protect the PHI that circulates over the network and between the system’s different tiers, app developers also need secure connections and protocols.
To this end, they should force HTTPS at least for the signup screens, all pages containing PHI and authorization cookies, and ideally for all communications. This secure communication protocol encrypts data with TLS.
App developers need to get an SSL certificate from a trusted provider, properly install it, and make sure to use a secure SSH or FTPS protocol for sending PHI-containing files instead of the regular FTP.
During client-server data transfers, when the data has to be transmitted in the body of the POST requests, the system may first encrypt them on the sender’s side and decrypt on the receiver’s side. This helps prevent man-in-the-middle attacks.
For data in transmission, using SSL-enabled endpoints with Amazon S3 is the best option. Some features include EC2 AMI Creation or Snapshotting.
When the information is in transit between a device and server, you can use modern cipher suites and TLS to handle data on the move. When the devices operate in untrusted networks such as public Wi-Fi, the app can use the certificate pinning process.
The developers also need to embed a Virtual Private Network (VPN) for greater file security during data transfers. Another level of certification is Health Level 7 (HL7) which provides data transfer guidelines among healthcare providers.
Make sure your app doesn’t send any push notifications or other automatic messages containing PHI.
Apps should also avoid
Once the data has landed in the server storage, the provisions around the key rotation, key management, encrypted backup, and audit logging come into play.
Backups are essential for data integrity. Multiple copies have to be safely stored in several different locations, but only of those pieces of data that you absolutely have to keep. Avoid storing or cacheing PHI whenever possible, e.g., users’ geolocation data (other than state-level).
All information with a high or medium risk of data compromise should be backed up daily and stored in a secure facility.
The backups themselves and the cloud services that healthcare apps are connected to should also comply with HIPAA security standards. Major cloud providers, such as AWS, Aptible, Datica, Google Compute Engine, and TrueVault, help a lot by offering out-of-the-box HIPAA-compliant back-end, backup, and recovery services.
Continuously log your system’s downtime and any failures to back up the PHI; test the system regularly to prevent recovery failures.
The app should automatically sync data between a local device and central servers so that a user doesn’t always have to stay connected to a network for accessing data.
There also should be an option for patients to erase their data from the system, including remote removal from a lost mobile device.
For the organizations to know who, when, and where accessed, modified, or deleted PHI from their system, it’s essential to record each time a user logs in and out, their IP Address, point of entry, and what exactly data was accessed. The system should store and present these activity logs in a comprehensible format.
For recording all user-data interactions, developers may use a five-column table in a database or a log file. These columns should be:
The app architecture should incorporate systems that enable security providers to access detailed logging information. Periodic audits of the activity logs should help discover if any users abuse their privileges to access PHI. It’s helpful to set up emergency alarms for detected anomalies or abnormal system behavior.
AWS CloudWatch is excellent at keeping a record of access to PHI. It allows for viewing the access data as graphs, running constant analytics, and stringent HIPAA security risk profiling.
Regarding the AWS levels of access, AWSCloudTrail may be recommended. It will help you record the data (AWS API Calls). AWS Config will let you handle AWS Resource inventory,
configuration history, and configuration change notifications.
Smartphones and tablets present additional risks because they can be easily stolen or lost, compromising sensitive information that was stored or accessible on the devices.
To prevent this, you can include into your onboarding or send via emails the instructions for users to use screen lock, full-device encryption, and remote data erasure capabilities on their Android or iOS devices.
Many physicians use personal smartphones to send health information. A secure messaging platform within your app will mitigate this risk. Another solution is encrypted password-protected portals where patients can read messages from their doctors without actually any PHI in them (e.g., “Dear User, you’ve got a new message from [redacted]”).
Even though all the above solutions together can’t guarantee your app’s absolute security, their implementation should convince an auditor that you’ve done enough to protect patient records and other sensitive information in compliance with the HIPAA requirements.
The entire software development process should occur with an eye on fulfilling government requirements for healthcare applications.
If you don’t have enough expertise or experience in HIPAA-compliant software development, it’s always better to hire third-party experts to advise you, review your existing app architecture, audit your entire system, and analyze your current preparedness.
A qualified HIPAA or security specialist will help you understand what kinds of data you deal with qualify as PHI. This may be the first step to a new app development, allowing to design the future database properly. The expert can also advise on what kind of data you can avoid sharing through your mHealth app and define the security requirements for it.
Outsourcing healthcare software projects to an agency with a corresponding track record also can solve this problem while saving costs. Experienced healthcare app developers will build your product faster, and the hourly rates of remote developers are often considerably lower than in the US. This is a bonus both for startups and established health tech companies and healthcare providers.
Another good practice is to outsource testing to a third party that can audit your app developers’ work by running all necessary tests.
Upon release, you can periodically hire professionals to audit your app’s infrastructure and code.
Instead of trying to build a HIPAA-compliant app from scratch, it’s reasonable to take maximum advantage of high-quality third-party solutions and ready-made infrastructure that are already HIPAA-compliant. This is called IaaS – Infrastructure as a service – and dramatically saves time, money, and effort.
Leading hosting providers take responsibility for security while storing or managing PHI data, and you won’t have to worry about signing a BAA with them. AWS and TrueVault are good examples of HIPAA-compliant technology you can use for healthcare software development.
Establish a long-term strategy for monitoring all HIPAA-related aspects of your healthcare app.
Even a minimum viable product (MVP) requires thorough testing with fake users and data to ensure security, particularly the gateways and authorization processes. Then, you will need to perform testing and validate your app’s security after every update. Test it both statically and dynamically, consult with experts, and make sure the documentation is up to date.
Maintenance is another ongoing process. Libraries, tools, frameworks, and third-party services are constantly being updated. Make sure you are using the latest version to prevent operation issues and security breaches.
Here are some more tips on how to deal with mobile apps:
In 1996, the U.S. Congress enacted HIPAA, meaning, among other things, to help protect patient information from theft and fraud. Nowadays, the consequences of non-compliance may be disastrous and the penalties for violating HIPAA may reach $1.8 million per year.
To minimize these risks, a healthcare company can hire a third-party agency to audit or consult them, provide the appropriate instruction, and even issue a corresponding certificate. However, remember that being HIPAA-certified does not equal being HIPAA-compliant; it means only that a company has completed a training course on becoming compliant. Moreover, OCR doesn’t recognize any third-party HIPAA certification either.
Finally, third-party services may be useless if you engage them after building your software without proper administrative and technical policies for HIPAA compliance; addressing these requirements from day one is the wisest.
Infrastructure should be set up to ensure safe collection, storage, and transfer of sensitive information and to prevent its unauthorized or accidental alteration. Measures like access authorization combined with distinct user roles and access rights to different app features, data encryption, and regular backups are indispensable when building HIPAA-compliant software.
Whether it is mHealth, SaaS, eCommerce, or FinTech application development, Onix will safeguard the users’ data under any conditions. Our team has a track record in building apps that meet all applicable federal and international security and privacy requirements.
Please feel free to book a free consultation if you have questions about your product’s HIPAA compliance, application development process, or outsourced design and development services.
A thousand thanks to Volodymyr Katarovskyi, PM at Onix’s healthcare software projects, for his assistance with this material!
How to hire HIPAA-compliant software development consultants?
You can look for specialists on job sites and freelancer platforms, such as Upwork, or contact agencies specializing in information security, including HIPAA compliance – software development advice should fall within the scope. Alternatively, when communicating with a potential outsourcing partner, you can ask whether they have knowledgeable software engineers on board.
Where are HIPAA-compliant software developers located?
Naturally, it will be the fastest and easiest to find them in the U.S. However, given the scale of IT outsourcing nowadays, it’s possible to build HIPAA-compliant apps virtually in all corners of the world. Your chances of hiring such experts are likely the highest in major outsourcing destinations, such as India, Malaysia, Singapore, the Philippines, Mexico, Brazil, Argentina, Romania, or Ukraine.
Can you set up a dedicated team for developing a HIPAA-compliant app?
Yes. Onix-Systems offers dedicated full-time teams on flexible employment and pricing terms, always focusing on regulatory compliance and intellectual property protection.
How many HIPAA-compliant apps has Onix released to date?
Onix-Systems counts nearly a dozen such products on its track record.