$4.3 million (maybe even more) to be paid in penalties. This might be the verdict you’ll hear in court one day if you reject the need for developing telemedicine apps in a HIPAA-compliant manner. This is a real-life case that we’re talking about. A cancer center from Texas, which we’ll leave undisclosed for understandable reasons, has recently paid $4.3 million in civil monetary penalties because it couldn’t care less to protect its patients’ data the way HIPAA instructs and requires to.
The investigation conducted by the Office of Civil Rights has shown that the center has failed to encrypt three devices that kept 34,000 patients’ PHI records in accordance with HIPAA requirements. Whenever you think about why HIPAA compliance is one of the first boxes to tick off the list of your healthcare app’s features, think of $4.3 million that you can pay in penalties if you don’t do so. Now that we have your attention, let’s move on to an instructive and rather practical guide on how to develop HIPAA-compliant software for telehealth.
What is HIPAA? Answering the Primordial Question
Some folks still find it hard to understand why developing HIPAA-compliant apps is crucial. In fact, their unwillingness to cognize stems from the lack of knowledge of what HIPAA is. The Health Insurance Portability and Accountability Act of 1996 (HIPAA), also referred to as the Kennedy-Kassebaum Act, is one of the most crucial milestones achieved by the United States Government in modernizing the country’s and global healthcare systems.
Signed into law on the 21st of August, 1996, HIPAA has changed the way of collecting, maintaining, governing, and, what is more, protecting patients’ personally identifiable information. This Act has once and forever altered the information flow patterns within healthcare systems worldwide.
HIPAA makes it crystal clear that the healthcare insurance and healthcare industries must protect their patient’s private health information (PHI), as well as electronic private health information (e-PHI), from any attempt of intrusion and misuse. This kind of data is extremely sensitive and might be used for causing serious mental and material damage.
Hence, the United States Government has passed this law to ensure that every company providing services in the healthcare industry, collecting any data from their customers, must conform to HIPAA. When it comes to HIPAA compliance in software development, there are four major rules that you have to adhere to
- The Privacy Rule. Assuring that clients’ PHI is adequately protected while smoothly transmitted between the authorized parties for ensuring the very best treatment outcome is what not only The Privacy Rule but the entire HIPAA boils down to. Therefore, all the entities covered by the Act must follow a rigid set of rules regarding the clients’ rights to manage the way their identifiable PHI is stored and used within the platform.
By the way, if you want to find out whether your company or a project can be deemed a HIPAA-covered entity, you can go to the Centers for Medicare and Medicaid Services website and use their specially-designated decision tool.
- The Enforcement Rule. Codified under 45 CFR Part 160, Subparts C, D, and E., the enforcement rule imposes the need for holding the covered entities accountable by applying financial penalties and court procedures to the violators.
- The Security Rule. It is to be found at 45 CFR Part 160 and Part 164, Subparts A and C as it features the HIPAA Administrative Simplification provisions defining the national standards for the security of e-PHI, electronic exchange, and health information security and privacy.
- The Breach Notification Rule. Described at 45 CF, §§ 164.400-414, the Breach Notification Rule requires all the HIPAA-covered entities to notify their stakeholders and anyone involved in the e-PHI storage and management process of a possible or actual breach.
Four rules, four principles, and four restrictions should keep you on track towards a HIPAA-compliant product. You have to make sure that the e-PHI is properly protected following the standards laid out at 45 CFR Part 160 and Part 164, Subparts A and C. Yet, if a breach happens, you have to report it and respond to it. Otherwise, get ready for the penalties envisaged by 45 CFR Part 160, Subparts C, D, and E.
While everything might seem clear – follow the holy four and you’ll be safe and sound – developing HIPAA-compliant software for telehealth, is a bit more complicated than that. Nowadays, everyone can tell you that you have to follow the rules, but none of them will explain to you how to do it. SPsoft has decided to take a revolutionary approach to the matter, as we’ll teach you how to do it in practice. We’ll take you right behind the scenes of developing a HIPAA-compliant app for the telemedicine industry.
HIPAA-Compliant Software for Telehealth: This Is How We Do It
It was not long ago that a US-based telehealth start-up, called Switchback Health, contacted us in the search for help. Their previous tech partner has abandoned the platform with an extensive tech debt to deal with, including HIPAA-compliance and cybersecurity issues.
Switchback Health is a neoteric telehealth platform for physiatrists and recuperative care patients that makes the treatment process easier. Strangled by the COVID-19 pandemic limitations, patients and doctors required a new way of ensuring the continuity of the needed recuperative care.
With the help of Switchback Health, Instead of visiting a doctor’s office, patients get a personalized set of recuperative exercise videos, which doctors can adjust and update. This is an up-and-coming HIPAA-compliant telehealth project called to refine the healthcare delivery process.
The years of cumulative experience gathered behind our team members’ backs has cleared the way for a swift and yet efficient implementation of the project. Nonetheless, developing HIPAA-compliant software for telehealth always starts from an extensive R&D session.
Having scrutinized the architecture and infrastructure left behind by the previous vendor, we have identified the fundamental need actually to refactor the code, architecture, and infrastructure from scratch to render the platform compatible with AWS ABB and App Store requirements (we’ll talk about it a bit later). Meanwhile, let’s embark on the initial checklist you need to tick off when striving for HIPAA compliance in software development.
Your Checklist for HIPAA Compliance
We have come with a stepwise guide for achieving HIPAA compliance for your app. Yet, if you feel like you could use a bit of expertise, you can always count on us. You need to follow three significant steps to reach the state of HIPAA compliance in software development. Adhering to this software development algorithm will ensure your project’s conformity to each of the four HIPAA rules mentioned above.
1. Analyze the Risks
It seems pretty easy to understand what is meant under the term “risk analysis.” Yet, there is no unified approach to it, as we all comprehend the concept of risk in various conjunctures. Generally speaking, you have to identify the possible threats to the confidentiality, security, and integrity of the clients’ information stored and transmitted within the app you develop. There are eight checkpoints to go through before you might deem yourself ready for deploying the product.
- Detect that data’s source, storage & maintenance environment, as well as transmission destinations.
- Define the data classes involved.
- Research and evaluate the PHI security practices used by the industry leaders.
- Detect the potential risks associated with infrastructure vulnerabilities.
- Analyze and adjust the scrutinized security practices to your project’s needs.
- Predefine and assess the consequences in case of the PHI breach.
- Develop and document the PHI/e-PHI response plan.
As you’ve been reading through this list, you might have, probably wondered about the data classes that we mentioned. Defining the data classes featuring within the app is actually an important step that many software vendors miss on. In accordance with the United States Department of Health and Human Services, there are 18 personal data classes that can be construed as PHI/e-PHI when combined with healthcare data. Those are:
- The patient’s name;
- Patient-related dates, e.g. date of birth/death, admission/discharge.
- Geographical information on patient’s domicile.
- Emails.
- Phone numbers.
- Fax numbers.
- Social Security number.
- Medical record number.
- Health plan beneficiary numbers.
- Bank account numbers.
- Certificates & license numbers.
- Vehicle identifiers and serial numbers.
- Device identifiers and serial numbers.
- Web URLs.
- IP addresses.
- Biometric identifiers, including finger and voiceprints
- Full face photographic images and any comparable images.
- Any other unique identifying number, characteristic, or code.
Even though we took over the Switchback platform – a readymade product – we have had to run the initial risk assessment in order to make sure that we eliminate every single issue on our way. Now, let’s move to step number two.
2. Eliminate the Risks
As soon as you have the assessment results, you’re ready to eliminate all the risks that might affect your project, even theoretically. The best approach to apply here would be starting from scratch. That is, commence training your teams on cybersecurity, gradually moving to introduce the HIPAA-specific concepts.
For example, visit the HHS website to learn the minimum necessary requirements for PHI usage and disclosure. It would be a great starting point. Sure, there is a lot of information to soak into your mind, but we know you have it. The whole point of this step is to ensure that your teams know how to implement HIPAA compliance in software development, regardless of the project you’re taking on. By the way, here’s a piece of advice to use in every telehealth project: make sure to implement two-factor authentication in your app, as this is the core of making your platform HIPAA-compliant.
When we started working on Switchback, we already knew what we were doing. Hence, having teamed-up with High Tower Security, the SPsoft team has provided R&D services, technology consulting, as well as architecture and infrastructure updates required for refining the product’s functionality and security.
We also dealt with the tech debt left behind by the customer’s previous technology partner, like refactoring the outdated iOS code that prevented the app from meeting the updated App Store requirements, thus clearing up the way for further product development. Adding the automated SSL-certificates and a custom-designed referral program, we have exterminated a myriad of the app’s legal and customer experience discrepancies.
3. Manage Risks in Advance
Ensuring your platform’s security in advance is good. Making sure it will remain in mint condition, in the long run, is even better. Remember, there are always hackers and other villains eager to lay their hands on your clients’ PHI/e-PHI. You will have to monitor your network quite precisely and ensure that you prevent any case of intrusion or react to it instantly, shall one befall your system. Basically, there are seven steps to ensure continuous security and thus compliance of your telehealth app with HIPAA.
- Apply vulnerability scans.
- Apply penetration testing at least 1 every 3 months.
- Apply network event monitoring.
- Analyze audit trails, thus identifying an action that was affected by it.
- Track logins to see who’s logged in.
- Provide automated event analysis and compliance reporting.
When we were crafting Switchback’s digital battlements to withstand any potential attack, we knew it was all about the response speed. Our DevOps specialist has provided continuous support of the product’s SLA, reacting to any performance discrepancies within an hour. The product’s refactored code, coupled with the infrastructure and architecture improvements, has managed to dock the number of DevOps incidents down to zero over the course of six months.
Yet, as you might have already guessed, ensuring security is not enough; you have to uphold it. We have delegated the mission of conducting constant penetration testing to High Tower Security. Finally, their cybersecurity professionals have embarked on developing a long-term log collection strategy and 24/7 security monitoring, achieving a high-trust level of HIPAA compliance.
Do not Forget HITECH
One of the most widespread mistakes the software vendors make when seeking HIPAA compliance in software development is forgetting about HITECH, another integral part of the overall HIPAA compliance ecosystem. Yet, SPsoft does not forget about it, as the Health Information Technology for Economic and Clinical Health Act is one of the key documents to follow when working in the telehealth industry.
Enacted under Title XIII of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5), the HITECH Act provides for the creation of a nationwide electronic health records network. Now, you might ask what is the difference between HIPAA and HITECH, and whether there is any difference at all?
Well, it should be acknowledged that while the difference exists, it is truly very subtle. The two documents care about the PHI/e-PHI security. Nonetheless, HITECH brings a vital extension to the patients’ rights, as it makes sure they are entitled to know the parties (authorized and unauthorized) their e-PHI has been disclosed to. Since 2011, patients are eligible to request data access reports, as ruled by the Department of Health & Human Services. Those reports must state who, why, and why was entitled to see their PHI/e-PHI.
HIPAA has been enacted to put people in charge of their sensitive personal data. HITECH finalizes the process of putting patients in total control over their health data, and this is why it is essential to keep it in mind when developing HIPAA-compliant software for telehealth.
Make it clear from the start of using your software that there are multiple ways to achieve any goal with it. Let your users choose the most appropriate way for them, so they create their unique customer journeys. This shows empathy and builds strong loyalty bonds. To do that, organize layouts in grids or table lists, offer an option to bulk select and delete some items, instead of swiping them one by one, etc.
Ensuring an AWS-Based App HIPAA-Compliance
Switchback Health was an AWS-based platform from the very beginning. Yet, lots of AWS requirements were not met by the client’s previous tech vendor. After signing the AWS Business Associates Addendum (BAA), we had no other choice but to adhere to the three core principles of this community, which are:
- High-Availability. One never knows when healthcare data might be needed. Hence, the software vendor must take proper care of the client’s user’s ability to swiftly restore their health data in case of its loss.
- Security. The app’s security must continuously fall within the HIPAA-compliance framework, as the security teams must provide solutions, including encryption, intrusion detection, penetration testing, vulnerability scanning, etc.
- Resilience. All the sensible data and PHI/e-PHI, in particular, must be stored in a reliable and secure manner.
It seems like sometimes HIPAA compliance is more about support and maintenance, as the need for penetration testing, intrusion detection, and the other ongoing services shows. Therefore, when ensuring Switchback’s HIPAA-compliance, we teamed up with High Tower Security – one of the most trusted partners in today’s world of cybersecurity. Thus, we were able to ensure an AWS architecture that serves the app’s security needs right.
No matter if your users install the desktop version of your software, browse the web for it, or use the product on their smartphones or tablets. The design and feature layout should be as consistent as possible, to reinforce confidence and ensure a positive user experience. Keep the page architecture the same wherever possible to make using your SaaS products intuitive on all devices.
Setting the AWS Architecture for a HIPAA Compliant App
Regardless of how brilliant your company might be from the legal point of view, there’s a need to understand that most organizations start experiencing hardships when it comes to the purely technical part of the matter. Infrastructure planning for HIPAA-compliant software for telehealth is that one big barrier that everybody stumbles upon. Yet, we’ve got some experience to share, and we’ll gladly do it. There are four practical (not theoretical) rules to apply when doing so.
- Provide Production Services in Copious Availability Zones (AZ)
As has already been mentioned, your application must be highly available. It means that a user must be able to instantly restore their health data, regardless of whether the data was stolen or the very account suspended. AWS offers several availability zones to use, thus providing for the developers’ ability to craft EC2-based services across copious AZs. Using the EC2 auto-scaling groups and Elastic Load Balancers (ELB) is a great way to achieve this result.
- Separate Development & Production Environments
Separating development and production environments is a must when developing HIPAA-compliant software for telehealth. AWS offers two ways to do it. You can create development and production environments using separate VPCs or build them in separate AWS Accounts that an AWS organization manages. This way, developers’ access to the app’s data is limited to the resources required strictly for developing and updating the app. As a result, the probability of unauthorized access is being minimized.
- Ensure Auditing by Collecting Logs
Preventing data breaches is the best way of dealing with them. Thus, collecting the suspicious activity logs is the right way to analyze the instances and come up with efficient response and prevention methods and practices. Some of the AWS verified log collection practices are AWS Cloud Trail and Access Logging for Regions and Access Logging for AWS services (S3, RDS, Redshift), respectively. Also, harnessing AWS CloudWatch to collect errors, availability metrics, and application logs would be a great idea.
- Devise Backup & Data Archivation Lifecycles
A resilient cloud architecture must contain reliable backup and recovery processes, which are integral for preventing data loss and recovering the data compromised or stolen. Hence, make sure to come up with the product’s Disaster Recovery Policy that will provide the data backup and recovery standards to follow. Make sure to review it periodically, catering to its utmost technical relevance and reliability.
Geolocation, orientation sensors, camera, vibration, voice control, integration with wearable devices, and secondary screens — there should be multiple ways to deliver value to your customers using their device functionality. Controlling multimedia with voice or wrist movements, automatic connecting to any smart TV after tapping a single button, joining a network by scanning a QR-code instead of manually entering the login and password — all of these are examples of adding value to your product by effectively using device functions.
Saving Our Clients
We have already mentioned an institution that paid more than $4 million in penalties because its IT specialists were too nonchalant to not encrypt the company’s devices in a due manner. Well, when working on the Switchback project, we have made a wiser decision and implemented it on an AWS basis. Thus, any attempt of hacking or breaching our client’s patient’s data will end up in a failure.
Remember, we talked about the 18 classes of information that are deemed sensitive PHI/e-PHI when combined with health data? Well, we took them apart and distributed them to various servers, meaning there is no correlation between the data and patients’ records. Hence, even if somebody (which we highly doubt due to the High Tower Security services) will be somehow able to reach the information, they will make no use of it, as they will not know to whom it belongs.
Thus, we did nothing else but saved our client from experiencing even the slightest possibility of both civil and criminal penalties. Below, you can find the list we deem to be the last resort at reminding people and companies why it is crucial to develop only HIPAA-compliant software for telehealth.
Civil Penalties for HIPAA Violations
- $100 to $50,000 for ignorance violation;
- $1,000 to $50,000 for violations despite reasonable vigilance;
- $10,000 to $50,000 for wilfully neglected violations corrected within 30 days;
- $50,000 for a wilful violation not corrected within 30 days.
Criminal Penalties for HIPAA Violations
- $50,000 + up to 12 months in jail for knowingly disclosing PHI/e-PHI;
- $100,000 + up to 60 months in jail for a violation under false pretenses;
- $250,000 + up to 120 months in jail for a violation committed for personal gain.
Let’s Sum It Up
Developing HIPAA-compliant software for telehealth is a task to be named a rather bilateral one. On the one hand, it must be easy, as there is a rigid and precise set of rules and guidelines to follow. On the other hand, HIPAA compliance in software development is a domain that requires extensive experience in developing solutions that meet both legal and technical requirements of the Kennedy-Kassebaum Act. Nonetheless, everyone eager to enter the telehealth industry has a choice to make: HIPAA compliance or immense penalties, coupled with criminal liability.
Many miscellaneous aspects might be unintentionally left behind when there is so much to ponder. For example, when ensuring the app’s compatibility with the HIPAA requirements, a software vendor can forget about HITECH or the AWS ABB requirements. Fortunately, the SPsoft team can deliver on both fronts of development – technical and legal, as we have the experience needed on our team. Developing a HIPAA-compliant app is not a challenge but a routine for us. Yet, we make sure to address every routine with creativity and vigor.
