Hiring or looking for a job in Digital Health? Check out our Digital Health Jobs board

Articles Blog

Updated May 24, 2023

DiGAs and the Telekom Cloud Run On Chinese Software From Huawei. Say What?

Dr. Oliver Eidel

Okay, let me get a few things straight before starting my rant. DiGAs are great, and creating incentives for building more (Healthcare) tech in Germany is really cool. The German tech scene is bleeding engineers to US-based FAANG companies, so - any incentive to bolster tech in Germany is much appreciated.

That being said, why the hell are we forcing DiGA companies to choose suboptimal cloud providers like the Telekom Cloud which runs on Huawei software? Does this make any sense, keeping in mind that our goals were data security and data privacy compliance?

The GDPR Situation

Let’s take a step back for a moment and look at the GDPR situation, highly simplified for your convenience. After the “Schrems II” court decision in 07/2020, it became very difficult to transfer personal health data to US-based cloud providers because, obviously, if you store data on US-based cloud providers, they might actually access that data (no surprises there).

Okay, so far, so good.

Like with all GDPR situations, this provided an answer to a question (can US-based providers provide adequate GDPR safe data transfers? –> no). Great. But this answer spawned like another thousand subsequent questions which have yet to be answered. A huge mess, like always with GDPR.

Questions like these: Can we use a US-based cloud provider, if we only use their EU data centers? What sort of measures (encryption?) can we implement to continue using US-based cloud providers? Can we store anonymized data there? If so, where would the data need to be anonymized? Where should we store the encryption keys? Etc., etc.

(I mean, sometimes I feel like the regulators should just publish a GitHub repository with some example implementations. That would answer so many questions. But then again, that would require regulators to actually understand software?)

Interestingly, in 03/2021, France’s highest administrative court ruled that it’s actually okay for France to use Doctolib for Covid vaccination appointments. Doctolib runs on AWS. So, apparently, using a US-based cloud provider seems to be okay if you put “legal and technical measures” in place to prevent access from US authorities. Of course no one knows what those measures exactly are (chuckle), but this is still helpful. So it’s generally still possible to use US-based cloud providers in a GDPR-compliant way for Healthcare data.

DiGA Cloud Provider Requirements

Now, for DiGAs, the BfArM provided additional requirements for cloud providers. Simplifying things greatly again, they basically said that US-based cloud providers can be used, but the data must be encrypted outside of those cloud providers. Like, you could encrypt your data on a server in your basement and then upload it to AWS S3. That would work.

But of course that would hugely increase technical complexity: If your data is stored encrypted somewhere, but the key is somewhere else, you lose a ton of basic technical functionality, like in your SQL database. If you encrypt all columns, it’s no longer possible to do simple things like ordering and sorting.

This is an active area of computer science research, so I won’t go too deep into that. Neither should any DiGA startup! The technical complexity of implementing this is too high for a startup which has other goals - like shipping a product and providing value to patients.

So, now, DiGA companies are faced with a conundrum: They have to choose a EU-based cloud provider, but all EU-based cloud providers are technically inferior to US-based ones. There are actually some pretty good ones in France - there’s Scaleway and OVHCloud, even though the latter recently had a data center go up in flames, with substantial data loss.. woops. Yep, they’re technically inferior for sure. And then there’s Hetzner in Germany who offer virtual servers but no PaaS. They’re pretty cool (I wrote their Clojure API client, but don’t benefit from mentioning them here).

But, for some reason completely unbeknownst to be, DiGA companies choose Telekom Cloud instead. What? I’m not a person who swears a lot, but the Open Telekom Cloud website can truly be described as utterly shitty.

Enter: The “Open” Telekom Cloud

Registering for the Telekom Cloud requires you to put something in your “shopping cart” which costs 0€. If you get confused like I did and click on it multiple times, a helpful error message is displayed (see below). The shopping cart entry also has some sort of UTF-8 (?) formatting issue (“the service description”) which is, um, concerning.

Telekom Cloud Registration

Okay, so this is the cloud which runs many DiGA backends in Germany and stores personal health data.

Cool.

To be fair: Sure, I haven’t tried the actual APIs out first-hand, but I’ve talked to a bunch of developers who have. None of them would recommend Telekom Cloud over AWS or a US-based provider. Some of them are very, very frustrated. But, as I don’t have first-hand experience, I’ll stop my technical rant here.

Instead, I’ll move on to publicly available information which is the actual bombshell: The Telekom Cloud runs on Huawei software (source: Handelsblatt, paywall removed).

Say what?

So, let me get the facts straight: US-based cloud providers are the most sophisticated and the risk of IT security breaches due to faulty infrastructure is low. But their GDPR compliance is questionable, that’s why we choose not to use them.

Many solid alternatives exist - mainly French providers.

But instead, DiGA companies choose a German provider which is technically less mature and runs on Chinese software from Huawei. Huawei has repeatedly been in the media for suspected espionage - so often that there even is a Wikipedia page on the topic.

Are there any rational people left in Healthcare regulation?

What Went Wrong?

Summing up, I see two main points here.

Firstly, when confronted with the choice of which cloud provider to use, companies didn’t choose wisely. The options were:

  1. A US-based provider with external encryption: The best technical choice, but very hard to implement.
  2. A EU-based provider which is good enough (e.g. Scaleway, OVHCloud, Hetzner). Not quite the best technical choice, but adequate for most use cases and easy to implement.
  3. Telekom Cloud which is a bad technical choice and runs on Chinese software.

Companies chose option #3. I really don’t know why (reach out to enlighten me if you were involved in such a decision at your company - I’m genuinely interested).

Next, maybe all of my ranting was for nothing if it turns out that Huawei is acting in good faith and that there are absolutely no backdoors in the software they’re selling to Telekom Cloud. Accordingly, I see two scenarios for the future:

  1. All of my ranting was pointless because the Huawei software on Telekom Cloud has absolute no backdoors and is safe, even though Huawei is a Chinese state-sponsored company and has a track record of espionage.
  2. It actually turns out that there are backdoors in Telekom Cloud and our patients health data has been accessed by China because we priotized GDPR compliance over sane technical decisions.

An interesting comparison here could be that our gas infrastructure was undermined by Russian companies in the past decade and we’re starting to regret that now. Is the same happening to our cloud infrastructure with China?

We’ll see.

On a slighty different note: You want to get your medical software certified under MDR but don't know where to start? No worries! That's why we built the Wizard. It's a self-guided video course which helps you create your documentation yourself. No prior knowledge required. You should check it out.

Or, if you're looking for the most awesome (in our opinion) eQMS software to manage your documentation, look no further. We've built Formwork, and it even has a free version!

If you're looking for human help, did you know that we also provide some limited consulting? It's limited because we are not many people. We guide startups from start to finish in their medical device compliance.

Congratulations! You read this far.

Get notified when we post something new.

Sign up for our free newsletter.

Dr. Oliver Eidel

I'm a medical doctor, software engineer and regulatory dude. I'm also the founder of OpenRegulatory.

Through OpenRegulatory, I've helped 100+ companies with their medical device compliance. While it's also my job that we stay profitable, I try to dedicate a lot of my time towards writing free content like our articles and templates. Maybe that will make consulting unnecessary some day? :)

If you're still lost and have further questions, reach out any time!

Comments

If you have any questions or would like to share your opinion publicly, feel free to comment below. If you'd like to reach out privately, send us a message.

No QMS on this planet will save you from creating crappy software.