eHealth applications offer varied digital solutions to use resources efficiently and improve the patient experience. But there is no school like the old school – getting to the root of healthcare tech we stumble onto the good old-fashioned HIPAA compliance colossus. What is a HIPAA-compliant application and why should developers and businesses care – let's find out it together.
What is HIPAA compliance and why does it matter
Requirements outlining the lawful use of protected health information (PHI) has been regulated by HIPAA since 1996. So, in other words, HIPAA Compliant is the main security guard and a staunch crusader for data property rights. Its initial intent was simplifying and reducing the administrative overhead, leading to incremental insurance and healthcare reform.
It reduces the medical error, improves the quality of care, and increases in customer satisfaction. HIPAA was initially a US framework but <medium>today it has already been adopted by other medical institutes worldwide.<medium>
Generally, it is about ensuring the privacy and security of PHI. And there are a lot of practical reasons for constantly monitoring the state of the data storage and transfer systems. Sophisticated cyber attacks impacting millions of peoples annually. According to HIPAA Journal research, in 2019, healthcare providers accounted for 77.65% of data breaches. And Office for Civil Rights (OCR) collected a total of $12000 in fines and settlements. The HIPAA Journal statistics below only include data breaches of 500 or more records (OCR doesn't publish smaller breaches).
HIPAA requirements should be the de facto security 'checklist' to follow by every healthcare organization. This understanding is essential for healthcare entrepreneurs, employees, and medical software developers.
Protected Healthcare Information: why developers should care
PHI exactly is any data that can be used to identify a patient. The very fact that a person has received medical services is already a PHI.
Protected Health Information consists of two parts: health information and personal identifiers. The latter includes names, photos, addresses, dates, medical records, etc.
Contrary to popular misleading myth – HIPAA compliance is not someone else's job. This is a concern not only of a compliance officer or a legal counsel. And it is not the only responsibility of healthcare providers, defined as 'covered entities' under the law. HIPAA requirements also relates to 'business associates' – organizations handling PHI on behalf of HIPAA-related entities. This category includes software companies that provide IT infrastructure, mobile and web development, and other IT services.
{{quote-bl58-1="/custom-block-to-blog/one-page"}}
In terms of digital security, HIPAA compliance is very granular requiring the incorporating of IT staff. Any health/medical app connected to the internet, i.e. a web app, website or mobile app <medium>must have a clearly defined architecture and detailed review at every development stage<medium>. And detected risks and vulnerabilities should be fixed as soon as possible.
The following are examples of HIPAA-compiliance app architecture and business logic.
That's why it is essential for <medium>developers, QA professionals, and other IT experts<medium> to have a perfect understanding of HIPAA compliance when developing healthcare apps, social platforms, cloud servers, and so on.
Do I need to be HIPPA compliant?
HIPAA compliance is a vital requirement for any software in the healthcare sector. Poor user session management, weak passwords, insecure data storage impact a lot of apps. And that is the main reason for HIPAA compliance improvement.
Before you try to make your app HIPAA compliant, answer questions below to know exactly if your app needs to be HIPAA compliant:
Do you transmit PHI through your app?
Do you collect PHI on your app?
Do you store PHI on a server connected to your app?
If the answer to any of the questions given about is 'yes', then be sure - your application needs to be HIPAA compliant.
HIPAA has had two major updates:
HITECH Act of 2009 expanded the scope of privacy and security protections, and conducive to the usage of electronic health records (EHR) with the prevalence of health data being increasingly recorded in the electronic medium.
HIPAA Omnibus Final Rule recently released in 2013 and modified the standard of determining the case of a breach of PHI, encryption, and risk analysis processes.
Power of three: 3 HIPAA security safeguards
Apps looking to maintain consistent HIPAA requirements must implement the standards outlined by the following trio of safeguards. They are divided into 3 groups comprising 18 standards. All of them manage the development, implementation, and maintenance of security measures to protect PHI. The difference is in the levels of the healthcare ecosystem and the kinds of facilities involved.
<medium>Administrative safeguards<medium> are defined as the relevant expertise and practice properly following security standards throughout the organization. It includes:
policies
procedures, including data breach contingency plan
documentation
regular staff training to familiarize with security policies with respect to PHI
<medium>Physical safeguards<medium> as physical places where data is housed or maintained include all physical parts from any physical location where workforce members' access sensitive data to USB devices and alarm systems.
Finally, <medium>technical safeguards<medium> refer to the access controls, secure encryption of the data in motion, and data at rest requirement, and so on. In short, it is about all technologies and methods related to data protection.
Healthcare app should only comply with technical safeguards, while the other two rest upon caregivers. That's why we are going to park it out in front of the HIPAA Technical Safeguards and explore it in more detail.
You snall not pass, or how to make your app HIPAA compliant
HIPAA Technical Safeguards consist of two specifications – required and addressable. Addressable doesn't mean "optional" or "not required". While Required specification means you must implement the specification as stated, Addressable specification provides an opportunity to implement an alternative measure compliant with the standard or not implement the specification if it's unreasonable and inappropriate for your particular situation. Choosing this option, you must documented such decision stating the factors considered by the covered entity and the results of any risk assessment.
All you need is Encryption (and Decryption too) - addressable
The encryption security technology protects contents of messages even they are intercepted by hackers. So all ePHI that leaves your firewalled servers must be encrypted. Moreover, the user must be able to decrypt message, provided the is the intended recipient. That's why HIPAA-compliant app keeps ePHI encrypted both before being transmitted via an additional security layer and during the transfer.
This not only about using SSL/TLS. At-rest encryption, VPNs & SSH protocols should be leveraged to secure any connection and data in your network. Decrypt any ePHI when viewing using some cryptographic toolkit. Let's mark that such famous cloud computing providers as Google Cloud, Amazon Web Services (AWS), or Microsoft Azure ensure smooth data at encryption.
Authentication - required
Multi-factor authentication (MFA) is still the best armor that offers your app protection from unauthorized use. It controls requires users to provide multiple proofs and in case of loss of the device MFA prevents unauthorized access.
MFA includes entering a password, biometric identifier as fingerprint or iris scanning, or verification code contained in a text message. Implementing of two-factor authentication (2FA) is usually enough to be sure that sensetive data will be safe.
Audit Controls - required
This standard requires the recording of ePHI activities for examination the activity in the system. For medical apps, it means detailed activity logging on a server. It's crucial to record attempted access to the data and all activities, such as changes made, information added, etc.
Emergency Access Procedures - required
That is about clear and secure way to access necessary ePHI during an emergency. In urgent cases, access to EPHI can be a key factor in saving a patient's life. Such access controls are very different from those observed normally and employ a unique user scenario.
Automatic Logoff - addressable
Even though this requirement is addressable, it's critical for protecting EPHI. Your app should terminate the session after a X period (usually go for 30 seconds to 3 minutes) of inactivity and log inactive the user out. If users puts an app in the background and then bring the app back to the foreground (i.e. active) you need to log back in again (same goes for banking apps). It will ensure that nobody can use a session except for the authorized user.
Disposal - required
Backed up and archived sensitive data must be safely disposed of. This is the case for all the decryption keys too: delete the encryption/decryption keys (or its activation data) to eliminate any future decryption of the ePHI. Furthermore, Disposal Standard is about securely erase the PHI from the storage media via suitable software or demagnetizing equipment.
Key tips for maintaining Data in motion
SSL/TLS protocol. It's a crucial part of valid encryption processes that protect and provide authentication, confidentiality and integrity of ePHI.
No alternate non-secure versions of login pages and pages collecting or showing health data.
Encrypting client-server transmitted data (in the body of POST requests) on the sender's side + decrypting it on the receiver's side. That is a classic method to protect ePHI from man-in-the-middle attack (MITM).
Hash values for the transmitted and stored password
{{quote-bl58-2="/custom-block-to-blog/one-page"}}
The ultimate list of HIPAA nuances to be checked depends on the specifics and the purpose of a particular application. You are welcome to leverage our experience in developing healthcare products and turn to Freshcode team for creating a HIPAA compliant app.
.jpg)
.jpg)
