When designing a medical app that handles protected health information (PHI), understanding HIPAA is critical. The act itself covers a lot of ground. What we’ll focus on here is the aspect of it dealing with data security and some of the basic concepts you need to think about when designing a medical app.
In the first part of this series, we talked about encryption of PHI on Android and iOS. If only apps never sent or received data, that could be enough. However, the vast majority of medical apps will exchange data with something, whether a central server or third party services. Here we’ll take a closer look at that process.
Data Transmission
Whenever data is transmitted over the Internet – via email, to the Cloud, or to a web service, it must be securely fashioned. All emails must be encrypted. Transmission via web to the cloud or to a service must be through HTTPS (secure HTTP) via something called Secure Sockets Layer (SSL).
If you use a server that uses HTTPS (e.g., one that uses OpenSSL or advertises SSL compliance, as in Amazon CloudFront Custom SSL with Amazon Web Services), you need to ensure that the server uses a certificate signed by an entity approved by Certificate Authority. Just make sure their web address does not pull up a warning page in a modern web browser; pages with those warnings are self-signed and cannot protect against interception by a bad guy.
HIPAA demands that data releases be limited. This means that I don’t transmit all patient records at once. I only transmit the patient records that are needed by the software to fulfill the function. This minimizes a potential data breach.
Data Queries
How do you ask for data? It’s probably safe to assume that your mobile app screen is secure to the user. But what about the app’s request to the database server?
A GET request places all the information in the web address (URL). This makes it potentially visible to a bad guy. Each URL is placed in the logs of potentially hundreds of computers as it transmits across the world to the server. It’s also visible via public WiFi.
The safer alternative is to request information via a POST command. There are two ways to send data to a server: A GET request provides the request via the URL, and a POST request hides it in a packet sent after the URL. The servers that transmit your URL request to its destination can see your entire URL in their logs, so GET requests can breach PHI. For example, https://www.yoururl.com/?id=12345&firstname=John&lastname=Smith – This obviously is a HIPAA breach.
POST requests are not seen in the logs, and they also do not have to conform to the byte limits that GET request has (in, say, sending large files). It would just appear as https://www.yoururl.com/. Thus, POST requests are more secure from a HIPAA standpoint.
Location of Mobile App Use
Public WiFi is the most dangerous location to access PHI or other sensitive information. It’s fairly easy for a bad guy to intercept traffic there. There’s nothing I’ve thought of that you can do as a developer to mitigate this risk (like, say, requiring that your network is using an encryption key to require only secure WiFi) other than doing steps like the above. You can spread the word to your user base not to access or send PHI here. Panera Bread provides good food and a place to spread work out, but using their WiFi to access EMR material is probably not wise (unless the EMR material is accessed using a https/SSL connection or is encrypted itself).
Of course, a secure VPN would be a way around it. Without some layer of security like a Virtual Private Network (VPNs), all your interactions with the Internet are open to interception. VPNs encrypt all your interactions through another server; this makes it more difficult for an intruder to intercept and decrypt your interactions. Thus, you can work at your workplace’s network without exposing a great security risk.
As such, many security folks recommend staying away from exposing private materials on public WiFi unless you have some layer of protection.
