HIPAA Compliance for Digital Health Platforms

HIPAA Compliance (Health Insurance Portability and Accountability Act of 1996) is United States legislation that provides data privacy and security provisions for safeguarding medical information.

Following our meet @MelbourneGA last month the lovely folks @MovemberAUS invited me for drinks to ‘pick my brain’ about HIPAA compliance (their words not mine!). Having built a few HIPAA compliant app platforms over the years for hospitals I thought I’d post my basic run-down notes below for anyone that may be confused about this whole HIPAA thing!

So what is HIPAA Compliance?

For starters HIPAA is really a US framework but has been adopted by other medical institutes around the world as the defacto security ‘checklist’ to follow as there really is not much else; the purpose is to ensure patient data is safe and secure and that only authorised medical staff can view these records.

This article was originally posted on Medium as HIPAA Compliance for App & Web-based Digital Health Platforms. What is HIPAA?

My notes for building any health/medical app connected to the internet i.e. a web application, website or mobile app that meets HIPAA compliance:

• TLS/SSL (https) secure API and all transactions to and from all/any apps i.e. GET/POST/PATCH etc
• Data should only be accessible by authorised users and they should only be allowed to view and edit data they are allowed access, this includes patients and doctors & further via any means; i.e. direct HTTP GET to API or via a logged-in web application, CMS admin area etc etc.
• Logout inactive user after X period of in-activity (we usually go for 30-secs to 3 minutes), logging back in can be via PIN, touch ID or password, the point is the app is secure like a bank app; if you put a banking mobile app in the background for example and then bring the app back to the foreground (i.e. active) you need to log back in again, same goes for health apps
• Save all cloud based data in a local data-centre (this is more US centric but data should to be saved in the local country of origin, for AU we use AWS data-centres in Sydney to comply for US you would use SFO or NYC etc.
• If you’re rolling out in country specific its prob best to have multi-server geographic roll-out and direct users to their local server via device IP check or have a fixed server based on user profile etc), would need to consider if the user moves; i.e. copy data protocol across servers etc
• In ‘terms of use’ doc need to note restricted access to confidential information, i.e. don’t allow export of data, only allow certain doctors to view their access allowed patient data
• Consider restricting access to data via IP i.e. just inside hospital X, this becomes difficult/impossible on apps as all IP’s essentially need access
• Encrypt any sensitive data in the database when saving and decrypt when viewing using something like KeyCzar (SHA-1)
• Link sensitive data with a UID instead of username or at the least architect your system so data is not traceable back to a single user on a first name last name basis; i.e. if the database is exposed you should not be able to plainly see the data listed in text; should be encrypted and need a key to decrypt as created
• Keep access logs for the server, i.e. do not provide root user access to the server, there should be a key person that commissions the server and then any sub-level users should be created and provided to IT staff; this is so if a security breach occurs a time-stamped log can be reviewed to trace back
• Log user login access to a web portal, i.e. administrator portal access, any decent web framework should do this by default anyway; i.e. Django etc.
• You need to have technical policies in place such as offline back-ups to ensure you can restore data as is if any server corruption or loss of data occurs
• You should also check for data consistency i.e. data should not be tampered with after creation unless by an authorised user such as a doctor; i.e. if a database is hacked/accessed and data changed this should be alerted as a data integrity issue and measures should be put in place to alert the correct staff and resolve/restore the issue to correct data point via a backup etc
• You shouldn’t allow the export of data out of databases &/or should have clear terms of use for doctors and medical staff regarding the export and use of data; i.e. if you have a web app that allows the export of CSV data you should not be emailing this data, uploading to another cloud service etc; this is to ensure all and any data that has been input into a system/app a patient thinks is safe and secure is not exposed by other methods.

Hope that helps! Any questions please reach out via LinkedIn, Twitter or visit my company website for further info on HealthTech app development.