Dealing With The HIPAA Compliance

Does your mobile app need to be HIPAA compliant?

Good question. What if your app is related to a health-care sector? Perhaps, it briefly touches the topic, and you could get away with non-compliance. Here’s the list of questions to answer to understand if your app needs it, given you are interested in marketing to the US healthcare market.

Who is using the app?

Is a doctor or a healthcare provider involved? If your app facilitates interaction between the doctor and the patient, then it most definitely falls under HIPAA compliance. If your app is created for the user alone, there is a good chance it doesn’t require to be HIPAA compliant, unless it matches the patient with his health data. Let’s say the app is a fitness tracker that tracks heart rate variability. Since it involves no interaction with the hospital, the regulations do not apply here.

What type of data about the user does the app manage?

If personal data is connected with medical data (names, medical record number, SSN, etc.), it qualifies as Protected Health Information. If any medical data is managed by the app, like the course of diagnosis or actual treatment and prescriptions, the app absolutely must be HIPAA compliant. If the user enters information on his own (e.g. reminder to take pills), then the app need not be HIPAA compliant. Discover the power of
Generative AI Use Cases in Healthcare industry.

Answering these 2 questions will help you understand if your app must comply with HIPAA security technical safeguards in the US market.

Technical part of HIPAA compliance

To pass HIPAA Compliance audit, your system should secure Protected Health Information being processed\exposed. Here are general technical recommendations.

1. Prevent any unauthorized access. Access to the application should be restricted after some time of user inactivity by automatically signing out or locking the session with pin screen or automatic logout, for instance.
2. Avoid storing or caching (including HTTP caching) any sensitive data on the device. If you must store sensitive data (including authorisation tokens, session data, etc.), it should be strongly encrypted. Do not store any passwords.
3. Interactions with the server should be performed via well encrypted SSL\TLS (Enable only strong ciphers (128-bit and up) and TLSv1). Certificates should be signed by a trusted CA for browser access. Restrict any non-encrypted access.
4. Do not expose actual account numbers on the client side – use tokens instead.
5. If you need to store sensitive data on the device, it should be custom encrypted in addition to standard device encryption APIs.
6. Do not store sensitive data in RAM longer than needed.
7. Tread with all client inputs as untrusted. Data should be validated and sanitised to prevent app crash, buffer overflows SQL Injections, and other attacks.
8. Keep server configuration up-to-date; apply all software security patches fast.
9. Disable verbose errors output on production.
10. To prevent brute-force attacks, response to the client should be the same for both cases – if user does not exist or if username and password combination is invalid.