Many digital health companies, afraid of the costs and timeline of a proper GDPR implementation, opt for a strategy to store personal and sensitive data inside the devices, hoping to circumvent the regulation.
The technical limitations of this strategy are evident for most app developers (no data access for maintenance, updates, troubleshooting, lack of info on how the users use the app for product improvement, etc.). But what's most disappointing is that in most cases, GDPR still applies, and many of these measures end up being in vain.
One of the most common pitfalls of this strategy is that the developer retains control over logical controls. It's very hard to justify that you don't process personal data if you are able to change your data access rights in the next app update.
If you are the one that can change at any point the access rights, it's like saying no one is accessing the door, but you are the one that has the key, and you are also able to change the lock.
The scenario
Let’s imagine you are developing a smartphone-based medical device. The mHealth app is ready to be put on the market.
The app will be downloaded to the hospitals' portable devices (tablets and smartphones) and will allow healthcare professionals to perform tests on visual acuity and store the results along with prescriptions.
All data collected will be stored inside the devices, and technically no data transfers will be performed.
If the device is not connected to the internet, you are not processing the data. In this case, this only needs to comply with privacy by design principles. You need to make sure the app is working properly, even without your intervention.
On the other hand, if the device is connected to the internet (if, for instance, the developer does the data processing for authentication or system maintenance and troubleshooting), you would still most likely be a data processor for all these purposes!
BUT you would probably be a data processor for maintenance, support, troubleshooting, etc.
And for this, you still have to be GDPR compliant, and the hospital Data Protection Officer will make you take responsibility for this in the Data Processing Agreement that you'll sign with the hospital..
Beyond the fact that the app developer still needs to be GDPR compliant, you have to keep in mind that this option leaves quite a bit of responsibility and inconvenience for the hospital. For instance, the hospital would be absorbing a lot of responsibility for how your app works. They would be the ones responsible for ensuring that the data minimisation principle is followed (i.e., that your app is not collecting more data than what is needed to provide the service). This is why it's also a shame that a lot of hospitals are so wary of using cloud solutions.
So, will leaving the data on the device exempt you from the GDPR?
Drum roll, please.
The answer is no. Or, more specifically, not by itself.
Unfortunately, leaving data on a device (smartphones and tablets in this case) does not automatically exempt you from the requirements of the GDPR.
In fact, the Regulation applies to the processing of personal data, regardless of where the data is stored. With “processing” in this context, we mean accessing data for backups, maintenance, etc.
Let’s see 5 examples of how, as an app provider, you are processing data under the GDPR:
- Login and authentication: this may include a variety of personal data, including names, email addresses, location information, and biometric data.
- In-app purchases: if the app includes in-app purchases (this is more frequent in B2C scenarios), you may collect payment information from users, such as credit card numbers and billing addresses (even if you are just redirecting the user to a third-party payment gateway).
- Analytics: As an app developer, you may use analytics tools to collect data on user behavior within the app, such as which features are used most frequently and how long users spend in the app to improve the user experience and optimize app performance.
- Data backup, maintenance, and recovery: When data is stored on a device, it is important to have a backup and recovery plan in place. You should ensure to have adequate backup procedures in place to prevent data loss or corruption. In the best-case scenario, the backups should be encrypted and securely stored to mitigate risks. Your customer would most likely require you to do this.
- Support requests and troubleshooting: If a user needs assistance with your app, you may collect personal data such as the user's name and email address. This data is processed in order to respond to the user's request and provide customer support.
Personal data is a fairly broad concept and refers to any information that can be used to identify an individual, directly or indirectly. This can include name and surname, address, email address, biometric data (e.g., fingerprints, facial recognition), IP address, and any other data that can be used to identify or contact a person. Don’t forget that also encrypted data and personal data that refer to a random ID are part of this category!
[PS: if you need more information about the type of data, download our free ebook about health data categories].
But beyond what is personal data, the core concept here is WHEN are we really processing data
What does data processing mean?
If your app provides features to track medications, appointments, and medical history, it is also a sign that you are processing data.
Some common features like reminders for medication schedules, sending alerts for upcoming appointments, and ensuring accurate and up-to-date health information is available to healthcare professionals are available only through the processing of patients’ data.
Here all the cases about maintenance, troubleshooting, and similar that we discussed in our example still apply as data processing.
If that is the case, you are still subject to GDPR regulations.
Some other regulations, like HIPAA, allow you to do some level of data de-identification, which would allow you to extract certain data points from the original dataset and not have to be within the scope of the regulation. This approach, however, would not work under GDPR since you would still process the data.
Beyond the more usual cases of data processing that we discussed above, when we talk about leaving data on the device, there is a not-so-obvious interpretation of data processing that you should consider.
If you opted for leaving all the data on the device and somehow avoiding all sorts of data processing (like maintenance), but the device is still connected to the internet for software updates, you could still be technically processing the data.
Why? Because you still may retain the ability to change your data access controls to basically start processing the data stored in the device in your own cloud at any time. And a DPO from a hospital that realises this will definitely want to put you as their Data Processor.
3 safeguards you should implement if you are storing data locally
If you are still going to do it, here are some tips for you. Keep in mind that this is a very common scenario for early MVP and clinical trials.
You still need to be GDPR compliant even though you have implemented all these measures. In this case, you are still Data Processor.
The EDPS affirms that “granting data subjects the choice to limit the processing of mHealth data locally – on their smart devices, rather than on a remote server – is one of the important safeguards mHealth apps and devices should implement.”
On personal devices are allowed to access personal data – and that includes receiving emails from or about customers, for example – you should ensure that:
- Mandatory login in the app is possible only with a strong and secure password and/or biometric access.
- Keep your data secure: If data contains sensitive information, it's important to keep it secure: consider encrypting the data, using password protection, and limiting access to authorized users. Keep in mind that you need to implement correct secret key management (and they need to be backed up as well).
- Use a backup system: to protect against data loss, it's important to have a backup system in place. This could involve regularly copying your data using cloud storage or implementing a version control system. (The backup must be encrypted as well, and the key must not be saved with those data).
In addition, be sure the device is updated to the latest OS version. Keeping your device updated is a crucial step to maintaining security at the highest level. Check for updates regularly, back up your device, and ensure enough storage.
Alternatives to storing data locally
Local storage is a solution that fits only a limited number of cases and scenarios. Frequently, you need to process the data on the server side or transfer it via the server to another device (data exchange).
Implementing a backend for storage and processing is potentially hard and risky, but it solves many issues and reduces the risks related to losing the phone or laptop.
1️⃣ Cloud Providers: providers such as AWS, Google Cloud, OVH, and Microsoft Azure typically have robust security measures in place to protect against data breaches and other security threats. It is important to carefully evaluate the provider's security measures, access control mechanisms, encryption capabilities, and data ownership policies to ensure that your sensitive data is protected appropriately. Considering our example in healthcare, take into account the obligatory word of caution regarding the usage of US Cloud Providers
2️⃣ Network Attached Storage (NAS): A NAS device is a type of storage device that is connected to your network and can be accessed by multiple devices. This can be a good option if you need to store a large amount of data or if you need to share data with others on your network.
3️⃣ Online Databases: Online databases like MySQL, PostgreSQL, and MongoDB allow you to store data remotely and access it through a web interface or API. This can be a good option if you need to store a large amount of structured data and need to access it programmatically.
Chino.io, your trusted compliance partner
The one-stop shop for solving all privacy and security compliance aspects.
As a partner of our clients, we combine regulatory and technical expertise with a modular IT platform that allows digital applications to eliminate compliance risks and save costs and time.
Chino.io makes compliant-by-design innovation happen faster, combining legal know-how and data security technology for innovators.
To learn more, book a call with our experts.
