In November 2019, new legislation passed by the German government provided a massive impetus for developers of German digital healthcare apps (DiGA) to get their products to market. According to the Digital Healthcare Act (DVG), if their app is formally approved by the German government, it can be prescribed by doctors and funded by health insurers. However, the following summer, when the European Court of Justice invalidated the integrity of the privacy shield between the EU and US, many German HealthTech developers were left reeling. They were unexpectedly prohibited from storing health data related to German citizens on US-based cloud providers. Despite some updates on the ruling in regards to the possibility of using US cloud subsidiaries based in the EU, the issue of compliance with non-EU cloud providers remains ambiguous.
The German Digital Healthcare Act was a significant piece of legislation designed to facilitate the digitalization of the German healthcare system. The Act was an effort to acknowledge and incorporate the valuable contribution of digital health applications in healthcare outcomes. Any DiGA that provides qualitative support to a patient managing a diagnosed medical condition can now be listed on a government directory of approved apps. Once listed, this DiGA can be prescribed by a doctor for their patient’s care, the cost of which will be covered by statutory health insurance. The roughly 86% of the German population currently insured under the statutory health insurance scheme are entitled to such prescriptions.
The Act was a huge boost to the German HealthTech industry and sparked a flurry of digital health innovation. To get their app approved and listed on the directory, digital health companies need to submit their app for a formal evaluation by the Federal Institute for Drugs and Medical Devices (BfArM), where it will be assessed for quality, functionality, effectiveness, and data security and data protection.
In July 2020 the European Union Court of Justice ruled that the EU-US privacy shield was incompatible with the requirements of GDPR and therefore invalid. This ruling left the developers of DiGAs in a vulnerable position because it meant that DiGAs and their associated patient data could no longer be stored and processed on US cloud services. This was something of a tremendous blow given the global dominance and widespread popularity of US cloud providers such as American Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
The ruling left some confusion however about the use of US cloud subsidiaries based in the EU. Amazon Web Services, for example, was quick to point out that it offers cloud hosting on its server located in Frankfurt, Germany. Earlier this year BfArM provided some further guidance on the issue, outlining several conditions that need to be in place that make it permissible to use a US owned cloud provider located in the EU. Primarily you need to guarantee that an appropriate level of protection is in place to ensure the privacy of personal data. Essentially data requires record-level encryption before being transferred and stored on the cloud, and encryption keys need to be stored separately. Furthermore, you are required to obtain a Data Processing Agreement (DPA) with the EU subsidiary of the parent company.
It is worth noting that the BfArM pointed out that their guidance could be overruled by one of Germany’s independent data protection authorities. (There is a separate authority in each of Germany’s separate 16 states).
To avoid the headache of achieving regulatory compliance while using a US owned cloud provider, many DiGA developers are choosing instead to partner with EU-based cloud platforms. The need to meet GDPR compliance requirements that will allow them to achieve BfArM approval is a strong incentive to avoid any legal uncertainty.
If developers are hoping to integrate communication functionality into their digital health apps via ready-to-use SDKs, APIs, and code samples they need to find communication backend providers who can host their software in any location and with any cloud provider they choose. This could be problematic as many CPaaS (Communication- platform-as-a-service) providers store and manage customer data on their own cloud, so DiGV developers will need to check what cloud provider they rely on.
If you are building a DiGA that requires communication functionality, QuickBlox can assist. We have total flexibility over wherever you wish to run your instance. Here’s 4 reasons why you should partner with us:
To find out more please contact us now.