WEBVTT Kind: captions Language: en 1 00:00:00.000 --> 00:00:06.429 One of you two has a Wikipedia entry. I assume that person knows about it. 2 00:00:06.429 --> 00:00:09.150 Yes. 3 00:00:09.150 --> 00:00:13.470 What I read there, I found fascinating. 4 00:00:13.470 --> 00:00:21.500 So I'd like to ask you, what does the Federal Cross of Merit mean and how does one receive it? 5 00:00:21.500 --> 00:00:30.940 The Federal Cross of Merit is a decoration, truly classic, like in the old days. 6 00:00:30.940 --> 00:00:36.700 It's the German Order of Merit, the only truly civilian decoration that is awarded. 7 00:00:36.700 --> 00:00:46.780 And the Federal Cross of Merit is the equivalent of an OBE, for example with the British, the Order of the British Empire. 8 00:00:46.780 --> 00:00:49.539 So if I were British, you could call me Sir now. 9 00:00:49.539 --> 00:00:53.979 Basically the knight's cross, as they used to say, but that has connotations. 10 00:00:53.979 --> 00:01:00.899 So it is quite a high distinction. I received it for my work. 11 00:01:00.899 --> 00:01:10.900 In the area of digital sovereignty, meaning open standards, free software, open source, building up the FSFE, and several other things. 12 00:01:10.900 --> 00:01:17.700 FSF what? Right, the Free Software Foundation Europe. Free Software Foundation Europe. 13 00:01:17.700 --> 00:01:22.900 That's a non-governmental organization that advocates for digital sovereignty. 14 00:01:22.900 --> 00:01:29.030 So essentially what keeps coming up in the media now about digital sovereignty, you started that many years earlier? 15 00:01:29.030 --> 00:01:31.030 Yes, it's basically my life's theme. 16 00:01:31.030 --> 00:01:37.030 I discovered it many, many years ago, early to mid 90s. 17 00:01:37.030 --> 00:01:40.030 And somehow it grabbed me and never let go. 18 00:01:40.030 --> 00:01:46.030 So the Sir, the knight sitting across from me, is Georg Greve from the company Vereign. 19 00:01:46.030 --> 00:01:52.450 Just briefly, we're here at HIN, in the healthcare sector. 20 00:01:52.450 --> 00:01:57.450 What do you have to do with Vereign, with the healthcare system? A quick summary, we'll surely hear more later. 21 00:01:57.450 --> 00:02:00.730 So Vereign has been... 22 00:02:00.730 --> 00:02:05.730 Vereign has been working very intensively with HIN for three years. 23 00:02:05.730 --> 00:02:10.729 We are very, very close partners. We've been involved with the healthcare system even longer. 24 00:02:10.729 --> 00:02:17.729 Through European projects, we've also worked with other healthcare institutions. 25 00:02:17.729 --> 00:02:20.729 Personally, this topic has been with me for a very long time. 26 00:02:20.729 --> 00:02:26.729 Good, and next to Georg sits Peer Hostettler, a member of the executive board at HIN. 27 00:02:26.729 --> 00:02:29.729 Peer is CCO at HIN. 28 00:02:29.729 --> 00:02:33.729 Do you actually know what that means? What does a CCO do? Is that Chief Customer Officer? 29 00:02:33.729 --> 00:02:36.729 No, Chief Commercial Officer, but Customer works for me too. 30 00:02:36.729 --> 00:02:40.729 And you could also say Chief Community Officer. I think that's also cool. 31 00:02:40.729 --> 00:02:44.729 So you don't place too much importance on the title? No. 32 00:02:44.729 --> 00:02:48.729 So Peer, I didn't find a Wikipedia entry for you when I googled you. 33 00:02:48.729 --> 00:02:52.729 But a CV, albeit a somewhat older one, mind you. 34 00:02:52.729 --> 00:02:58.729 Not everything is in there, but I did see that you've been working in healthcare since 2010. So quite a while already. 35 00:02:58.729 --> 00:03:05.729 And then I wondered, what is actually your passion? 36 00:03:05.729 --> 00:03:09.729 What drives you, that you've been at HIN for so long? 37 00:03:09.729 --> 00:03:21.419 When I take stock, three drivers motivate me. 38 00:03:21.419 --> 00:03:24.419 The first is the search for purpose. 39 00:03:24.419 --> 00:03:29.969 The second is, I want to discover something. I want to... 40 00:03:29.969 --> 00:03:34.969 It has to be exciting. Like a Columbus-style kind of discovery. 41 00:03:34.969 --> 00:03:41.219 And the third is sociality. Being with pleasant people... 42 00:03:41.219 --> 00:03:47.259 That doesn't always work out, but... Discovering something together with pleasant people. 43 00:03:47.259 --> 00:03:53.750 Insight. Navigating the digital healthcare system. 44 00:03:53.750 --> 00:04:00.750 The podcast from HIN for insider conversations with experts from IT, healthcare, and politics. 45 00:04:00.750 --> 00:04:12.020 For me of course... 46 00:04:13.020 --> 00:04:16.019 It's wonderful that I have two experts here with me. 47 00:04:16.019 --> 00:04:22.019 One is practically a knight, a Sir from the IT and digitalization world. 48 00:04:22.019 --> 00:04:27.019 And the other is Peer, who has really been in healthcare for a very, very long time. 49 00:04:27.019 --> 00:04:29.019 And that's also very important for today's topic. 50 00:04:29.019 --> 00:04:37.019 Because it's about the challenges in healthcare, about the digital solutions that can be offered. 51 00:04:37.019 --> 00:04:42.019 In healthcare, many of the people who work there are stretched to the limit. 52 00:04:42.019 --> 00:04:46.019 Budgets are tight, and there's a shortage of skilled professionals. 53 00:04:46.019 --> 00:04:52.019 And another point is the administrative burden, which keeps growing. That's exactly what we want to talk about. 54 00:04:52.019 --> 00:04:57.019 Where does the shoe pinch in healthcare for the professionals, in hospitals, in practices? 55 00:04:57.019 --> 00:04:59.019 What are the challenges? 56 00:04:59.019 --> 00:05:04.019 But above all, we're talking about solutions that HIN and partners can offer through digitalization. 57 00:05:04.019 --> 00:05:10.019 Great to have you with us. My name is David Umiker and this is the second episode of the HIN podcast. 58 00:05:17.269 --> 00:05:23.300 My keyword is skills shortage. That doesn't just mean we have too few trained people, 59 00:05:23.300 --> 00:05:30.399 but also that highly trained people leave the profession after completing their studies. 60 00:05:30.399 --> 00:05:34.399 Surveys and studies that have investigated this also show 61 00:05:34.399 --> 00:05:40.399 that younger doctors are indeed already leaving the profession. The reasons are varied. 62 00:05:40.399 --> 00:05:45.399 But one reason that certainly plays a role is the growing administrative burden. 63 00:05:45.399 --> 00:05:51.399 Due to bureaucracy. Now, you talk a lot with customers. 64 00:05:51.399 --> 00:05:55.399 What can you share with us, maybe one or two main reasons 65 00:05:55.399 --> 00:06:00.399 that you keep seeing as the main challenges for healthcare professionals in their daily work? 66 00:06:00.399 --> 00:06:05.939 Yes, perhaps as an addition. It doesn't just affect the medical profession, 67 00:06:05.939 --> 00:06:11.939 but the entire spectrum: nurses, therapists, IT. 68 00:06:11.939 --> 00:06:15.939 This skills shortage is everywhere. Since it's everywhere, you could almost say 69 00:06:15.939 --> 00:06:19.939 it's the new normal, so we just have to acknowledge it. 70 00:06:19.939 --> 00:06:25.939 So that as an addition. When you ask me that and when I think about it, 71 00:06:25.939 --> 00:06:31.259 what consistently comes to the surface 72 00:06:31.259 --> 00:06:37.259 is that there are clearly compensation problems or challenges. 73 00:06:37.259 --> 00:06:42.259 The topic of payment for services rendered is highly problematic. 74 00:06:42.259 --> 00:06:46.259 And the spectrum in healthcare, in terms of organization, is extremely broad. 75 00:06:46.259 --> 00:06:50.259 On one side you have freelance professional groups, self-employed people. 76 00:06:50.259 --> 00:06:54.259 These are one-person operations. 77 00:06:54.259 --> 00:07:00.259 And then you have huge university hospitals. You always have to keep that in mind. 78 00:07:00.259 --> 00:07:06.259 But when you look at these extremes, the topic of tariffs, the topic of billing, 79 00:07:06.259 --> 00:07:10.259 is a major topic, a burdensome topic. 80 00:07:10.259 --> 00:07:15.259 Especially when it comes to demands imposed, for example, by new rules, 81 00:07:15.259 --> 00:07:19.259 by new regulations or trends and developments and so on. 82 00:07:19.259 --> 00:07:24.259 There is a massive inability to invest. 83 00:07:24.259 --> 00:07:31.259 The actors, when confronted with our topics as well, 84 00:07:31.259 --> 00:07:34.259 keep saying, for God's sake, now you want even more, 85 00:07:34.259 --> 00:07:39.259 now this costs money again, or now we need even more. It's difficult. 86 00:07:39.259 --> 00:07:44.259 So bureaucracy requires changes to processes or creates more effort, 87 00:07:44.259 --> 00:07:49.259 because you have to report this and that somewhere, to an insurance company or an authority or wherever. 88 00:07:49.259 --> 00:07:54.259 And that could be simplified with certain investments in digitalization. That's what you mean. 89 00:07:54.259 --> 00:08:00.259 And at the same time, they can't bill for the effort that healthcare professionals have. 90 00:08:00.259 --> 00:08:05.420 Do I understand that correctly? Yes, that's the direction. 91 00:08:05.420 --> 00:08:09.420 But there might be a small misunderstanding. Digitalization isn't inherently there 92 00:08:09.420 --> 00:08:15.420 to reduce bureaucratic overhead. I remember it differently. 93 00:08:15.420 --> 00:08:18.420 When the whole topic first became a topic, 94 00:08:18.420 --> 00:08:22.420 people realized that through bits and bytes 95 00:08:22.420 --> 00:08:27.420 you could completely redesign the sequence of workflows, meaning processes, 96 00:08:27.420 --> 00:08:30.420 and we could do entirely new things. 97 00:08:30.420 --> 00:08:37.419 And then there are plenty of well-publicized stories. 98 00:08:37.419 --> 00:08:42.419 At some point the whole topic arrived in healthcare. They started recording patients 99 00:08:42.419 --> 00:08:48.419 in electronic systems, so they could bill electronically, for example. Then at some point they started 100 00:08:48.419 --> 00:08:53.419 documenting electronically. Then lots of IT silos emerged. So that's where we are now. 101 00:08:53.419 --> 00:08:57.419 And now the requirements keep getting higher and higher and higher. 102 00:08:57.419 --> 00:09:02.419 And that means you have to invest in these systems. So your summary was actually right. 103 00:09:02.419 --> 00:09:06.419 And in order to reinvest, you naturally need some kind of earning power. 104 00:09:06.419 --> 00:09:12.419 Because without income, no investment capability, and without investment, no earning power either. 105 00:09:12.419 --> 00:09:19.289 Let alone any innovation. Yes. That's really where the problem lies. That's a catch. 106 00:09:19.289 --> 00:09:25.289 Yes. But one of the bigger ones. And when a healthcare professional 107 00:09:25.289 --> 00:09:31.700 wants to invest in digitalization, they can ask themselves, where can I bill for that? Well, nowhere. 108 00:09:31.700 --> 00:09:36.700 You can't bill for that now. Not at all. There is a tariff system for the inpatient sector, 109 00:09:36.700 --> 00:09:42.700 for nursing, for outpatient healthcare provision, medical outpatient services. 110 00:09:43.700 --> 00:09:45.700 And there's a tariff for that. 111 00:09:45.700 --> 00:09:50.700 And the statement, the political statement, is always the same: 112 00:09:50.700 --> 00:09:55.950 it's already covered in the tariff. And that's a conversation killer. 113 00:09:55.950 --> 00:09:59.950 Because when you obviously have an IT system 114 00:09:59.950 --> 00:10:05.950 that in the worst case sits on heavy legacy technology, 115 00:10:05.950 --> 00:10:09.950 that's self-hosted on-premise, somewhere under a desk, 116 00:10:09.950 --> 00:10:13.950 if you want to open that thing up into a collaborative tool 117 00:10:13.950 --> 00:10:19.950 for new communication pathways, 118 00:10:19.950 --> 00:10:25.950 then you have to overhaul the entire system. And that overhaul costs real money. 119 00:10:25.950 --> 00:10:29.950 And that can never be covered in a tariff. There was just a tariff change. 120 00:10:29.950 --> 00:10:34.950 The old tariff didn't cover it either, because it dates back to the early 2000s. 121 00:10:34.950 --> 00:10:38.950 And the new tariff hasn't changed much either. Keyword: cost neutrality. 122 00:10:38.950 --> 00:10:44.950 There's simply no money in the system. But are there solutions? What are the solutions 123 00:10:44.950 --> 00:10:49.980 when the budget isn't available in healthcare? How are healthcare professionals supposed to use digitally sovereign, 124 00:10:49.980 --> 00:10:53.980 secure, modern tools or even infrastructure? 125 00:10:53.980 --> 00:10:58.980 How is that supposed to work when nobody has money? I mean, I'm fairly certain 126 00:10:58.980 --> 00:11:04.980 that they do of course pay for the tools they use today. 127 00:11:04.980 --> 00:11:10.980 Particularly making payments to the US. So the money is simply gone 128 00:11:10.980 --> 00:11:15.980 once it's been paid. That money could also be used differently, perhaps more sensibly. 129 00:11:15.980 --> 00:11:20.980 So it's a question of redirecting budgets. The budget partly exists. 130 00:11:20.980 --> 00:11:23.980 And on the other hand, it's certainly also a question of efficiency. 131 00:11:23.980 --> 00:11:27.980 If every doctor starts doing things individually 132 00:11:27.980 --> 00:11:32.980 on their own, that's of course totally inefficient. 133 00:11:32.980 --> 00:11:38.980 But they often have exactly the same needs. It's not as if one medical practice 134 00:11:38.980 --> 00:11:41.980 needs a completely different email system than another medical practice. 135 00:11:41.980 --> 00:11:47.980 And I think we're actually in exactly the right place for this. Because HIN was created from exactly this idea. 136 00:11:47.980 --> 00:11:52.980 To say, we solve these problems for all of us, 137 00:11:52.980 --> 00:11:57.980 because this isn't the core of what we do. It's also not where we differentiate ourselves. 138 00:11:57.980 --> 00:12:01.980 It's simply something we need to solve properly together. 139 00:12:01.980 --> 00:12:06.210 We can gain efficiency by bundling all of it. 140 00:12:06.210 --> 00:12:10.210 And HIN is, from my perspective, incredibly valuable in this regard, 141 00:12:10.210 --> 00:12:16.210 because it comes from the sector itself. It belongs to the FMH. 142 00:12:16.210 --> 00:12:23.210 FMH is the professional association of physicians. 143 00:12:23.210 --> 00:12:30.340 And ultimately, HIN has a service mandate 144 00:12:30.340 --> 00:12:34.340 and not a profit mandate. That's incredibly important to understand, 145 00:12:34.340 --> 00:12:38.340 because when HIN makes profits, 146 00:12:38.340 --> 00:12:44.460 those go back to the doctors. The people who use the software. 147 00:12:44.460 --> 00:12:50.460 So it's a cycle. Then it would be a cycle through a heater. That's completely pointless, nobody needs that. 148 00:12:50.460 --> 00:12:56.460 So the point is that HIN is able to efficiently deploy its budget toward 149 00:12:56.460 --> 00:13:01.460 what the doctors actually need. And this concept exists in other sectors too. 150 00:13:01.460 --> 00:13:07.460 In Germany, for example, there's DATEV. They do the same for tax consultants and lawyers. Here in Switzerland. 151 00:13:07.460 --> 00:13:10.460 HIN is unique worldwide, from what I can see. 152 00:13:10.460 --> 00:13:14.460 I haven't seen such a construct anywhere else. 153 00:13:14.460 --> 00:13:19.460 On the contrary, when I tell people abroad that we have HIN in Switzerland, 154 00:13:19.460 --> 00:13:26.230 the first question is usually, shouldn't we also create something like that? And why don't they do it? 155 00:13:26.230 --> 00:13:29.230 Well, the reason is that in other healthcare systems 156 00:13:29.230 --> 00:13:35.230 there are often very large commercial players with very good connections, 157 00:13:35.230 --> 00:13:40.230 who have no interest in being pushed out of this sector, 158 00:13:40.230 --> 00:13:44.230 because they make a lot of money from it. Because they are of course profit-oriented 159 00:13:44.230 --> 00:13:47.230 and try to extract the maximum profit from the sector. 160 00:13:47.230 --> 00:13:51.230 HIN in Switzerland is unique in this regard. 161 00:13:51.230 --> 00:13:55.230 And that's why, when I realized this, I asked myself, 162 00:13:55.230 --> 00:14:01.230 why doesn't Switzerland leverage this competitive advantage much more aggressively? Because we have the vehicle, 163 00:14:01.230 --> 00:14:06.230 we have the organization, we have the professional structures 164 00:14:06.230 --> 00:14:08.230 to tackle all these problems 165 00:14:08.230 --> 00:14:13.299 and actually solve them at the grassroots level for Switzerland. 166 00:14:13.299 --> 00:14:22.669 Georg just told us a lot about HIN, 167 00:14:22.669 --> 00:14:28.669 almost gushed about it, really, which is something unique that Switzerland has with HIN. 168 00:14:28.669 --> 00:14:33.669 And that's actually what we want to talk about now. What does HIN actually have to do with this whole discussion 169 00:14:33.669 --> 00:14:39.669 we've just been having? And what does Georg's company Vereign have to do with it? And I'd be curious to know, 170 00:14:39.669 --> 00:14:45.669 first of all, how did the collaboration between these two companies come about, Peer? And quickly, Georg, 171 00:14:45.669 --> 00:14:50.669 thank you for your advocacy for HIN. I couldn't have put it better myself. 172 00:14:50.669 --> 00:14:56.669 We found Georg and his team, or Georg and his team found us, when we were facing the challenge 173 00:14:56.669 --> 00:14:58.669 that we have a service called HIN Mail, 174 00:14:58.669 --> 00:15:04.669 and this HIN Mail service also reaches non-HIN participants, 175 00:15:04.669 --> 00:15:09.669 for example patients. You can imagine, when a patient has been to the doctor and receives a report, 176 00:15:09.669 --> 00:15:15.669 and the patient wants to receive that report by email, then the doctor has to send it encrypted. 177 00:15:15.669 --> 00:15:21.669 There's a function for that. We had it, but it was rather challenging to use. 178 00:15:21.669 --> 00:15:26.669 And with Georg's team we discussed, are there alternatives? And yes, there were. 179 00:15:26.669 --> 00:15:30.669 And it convinced us so much because when he came in, 180 00:15:30.669 --> 00:15:36.669 before we had agreed on anything contractually, he came with a POC and showed us: 181 00:15:36.669 --> 00:15:41.669 look, this is how encrypted email delivery 182 00:15:41.669 --> 00:15:46.669 to non-HIN participants could work. POC is proof of concept. Correct. Just to clarify. 183 00:15:46.669 --> 00:15:49.669 And this proof of concept convinced us incredibly, 184 00:15:49.669 --> 00:15:55.669 because it delivered on something very fundamental that concerns us, 185 00:15:55.669 --> 00:15:58.669 namely data minimization, 186 00:15:58.669 --> 00:16:02.669 not playing a central role 187 00:16:02.669 --> 00:16:08.669 in handling such sensitive information. And Georg and his team had a concept, 188 00:16:08.669 --> 00:16:11.669 they chose a path that showed us, 189 00:16:11.669 --> 00:16:17.669 wow, there are entirely new ways of thinking 190 00:16:17.669 --> 00:16:22.669 about how to design and implement systems 191 00:16:22.669 --> 00:16:26.669 that elevate us to a completely new level of data protection, 192 00:16:26.669 --> 00:16:31.669 to a new level of sovereignty, on the one hand. And on the other hand, 193 00:16:31.669 --> 00:16:37.669 they're actually even more user-friendly in their application. Georg, what's actually better now 194 00:16:37.669 --> 00:16:44.019 about the HIN Mail you built? The new HIN Mail for communication 195 00:16:44.019 --> 00:16:50.019 between healthcare professionals and patients is a so-called edge application, 196 00:16:50.019 --> 00:16:55.019 meaning an endpoint application. That means the message, 197 00:16:55.019 --> 00:17:01.019 when it's sent, is very strongly encrypted, is chopped into many, many small pieces, 198 00:17:01.019 --> 00:17:07.019 and then enters a kind of large swarm where lots and lots of tiny pieces are floating around, and nobody can tell 199 00:17:07.019 --> 00:17:12.019 which piece actually belongs to whom. And only on the user's device, 200 00:17:12.019 --> 00:17:17.019 the patient in this case, does everything come back together. They have an application 201 00:17:17.019 --> 00:17:22.019 that starts automatically via a web address, which reassembles everything 202 00:17:22.019 --> 00:17:28.019 and knows how to find the right pieces and how to put them back together, how to decrypt them, 203 00:17:28.019 --> 00:17:33.019 and then displays them to the patient. And the whole thing happens at the speed of a normal website loading. 204 00:17:33.019 --> 00:17:38.019 So for the user, it feels like they're opening a website, 205 00:17:38.019 --> 00:17:41.019 but in fact an enormous amount is happening in the background 206 00:17:41.019 --> 00:17:47.019 and there is no longer a central location in this system where the data could be intercepted, 207 00:17:47.019 --> 00:17:53.019 not even in encrypted form. HIN can't do it, we can't do it, and nobody else can either, 208 00:17:53.019 --> 00:17:59.019 because the data simply doesn't exist in a central location. And you'd need all the pieces from this swarm 209 00:17:59.019 --> 00:18:05.019 to understand the message? Yes, exactly. It's like a giant puzzle, but you don't just have a 1,000-piece puzzle, 210 00:18:05.019 --> 00:18:09.019 you currently have 800,000 pieces 211 00:18:09.019 --> 00:18:14.019 being sent around every month, and searching through all those puzzle pieces 212 00:18:14.019 --> 00:18:18.019 is quite laborious. So it's become much more secure. 213 00:18:18.019 --> 00:18:23.019 And yes, I believe especially right now with the conflict in Iran, 214 00:18:23.019 --> 00:18:27.019 where you constantly read about cyberattacks in the media 215 00:18:27.019 --> 00:18:33.410 that keep increasing and so on, it's extremely important in healthcare 216 00:18:33.410 --> 00:18:38.410 to also invest in security. Yes, of course, but the important thing is that you design this security 217 00:18:38.410 --> 00:18:43.410 in such a way that you assume that even if something goes wrong, the resilience, 218 00:18:43.410 --> 00:18:48.410 meaning the system's flexible ability to respond to problems, 219 00:18:48.410 --> 00:18:53.410 must be built in from the start. That also means that even if HIN were hacked, 220 00:18:53.410 --> 00:18:58.410 which I don't expect -- HIN does everything right -- but even if that were to happen, 221 00:18:58.410 --> 00:19:04.410 an attacker couldn't read those messages, because they simply don't exist there. ... 222 00:19:05.410 --> 00:19:12.529 Good, HIN Mail was the beginning 223 00:19:12.529 --> 00:19:18.529 of something big, from what I've gathered. What else is coming? Now we're tackling 224 00:19:18.529 --> 00:19:24.529 the interoperability challenges. Interoperability challenges. 225 00:19:24.529 --> 00:19:30.529 That's quite a tongue twister. A huge topic. We'll get to that shortly. Perhaps just this much upfront. 226 00:19:30.529 --> 00:19:35.529 The interoperability challenge is not a data problem per se, and certainly not one 227 00:19:35.529 --> 00:19:39.529 due to a lack of standards. We almost have too many standards. 228 00:19:39.529 --> 00:19:45.529 It's a trust problem. Interoperability means 229 00:19:45.529 --> 00:19:52.130 that communication works between different systems. Correct. 230 00:19:52.130 --> 00:19:57.309 It's a trust problem. Sorry, I interrupted you. No problem. 231 00:19:57.309 --> 00:20:02.309 You asked me, what's the next big thing? We're going to tackle this topic. 232 00:20:02.309 --> 00:20:04.309 And what does that mean, Georg? 233 00:20:04.309 --> 00:20:09.910 It means the ability to collaborate 234 00:20:09.910 --> 00:20:12.910 between the different systems at the end of the day. 235 00:20:12.910 --> 00:20:18.910 Today, every practice exists like an island on its own. 236 00:20:18.910 --> 00:20:24.910 Every hospital like an island on its own. Now these islands need to communicate with each other. To do that, 237 00:20:24.910 --> 00:20:30.910 we need secure pathways between the islands. That's what we need. 238 00:20:30.910 --> 00:20:36.910 Otherwise, healthcare data would fly around unsecured. You wouldn't know what happens with it. 239 00:20:36.910 --> 00:20:41.940 So we need a secure connectivity layer between the different systems. 240 00:20:41.940 --> 00:20:47.940 And that's exactly what we're working on now. So that in the future we can exchange data between hospital and hospital, 241 00:20:47.940 --> 00:20:53.940 but also between hospital and family practice, or hospital and laboratory, in such a way that the data flows 242 00:20:53.940 --> 00:20:59.940 in a structured manner, with intelligence. Because what's been happening so far 243 00:20:59.940 --> 00:21:05.940 was often just digitized paper processes. To put it bluntly: the PDF. Those are the data 244 00:21:05.940 --> 00:21:11.940 that we... ... To put it bluntly: the PDF. 245 00:21:11.940 --> 00:21:17.940 I once heard someone say "PDF graveyard." Fax machines, we all remember those. And basically, at that level 246 00:21:17.940 --> 00:21:23.940 is where we're still stuck. And in order to be able to unlock the potential of digitalization 247 00:21:23.940 --> 00:21:29.940 for healthcare, the systems need to start exchanging data with each other 248 00:21:29.940 --> 00:21:35.940 in a way that carries meaning. But I have a question, because I think fax is really old by now. 249 00:21:35.940 --> 00:21:41.940 And I'm going to assume it's just an assumption, that various approaches have already been tried 250 00:21:41.940 --> 00:21:48.359 to make things interoperable. Why should it succeed now? Or why does 251 00:21:48.359 --> 00:21:54.359 the current infrastructure work? Well, the whole topic is actually a perfect fit 252 00:21:54.359 --> 00:22:00.359 for HIN, because it's a trust problem. A trust space 253 00:22:00.359 --> 00:22:06.359 needs to be created. And this trust space needs to be secured. In the past, you could only 254 00:22:06.359 --> 00:22:12.359 attempt this through centralized technologies. But when you deploy centralized technologies, ... 255 00:22:12.359 --> 00:22:18.359 you always have a central point where the control sits, where the security depends on, 256 00:22:18.359 --> 00:22:24.359 where every decision hangs. It can also block everything if it doesn't work. 257 00:22:24.359 --> 00:22:30.359 And it's difficult for the institutions to agree on having just one trust point 258 00:22:30.359 --> 00:22:36.359 that would essentially also have control over their own internal systems. So this central point would basically 259 00:22:36.359 --> 00:22:42.359 reach into the local systems. And that is difficult from an organizational logic 260 00:22:42.359 --> 00:22:48.359 and from a trust perspective. ... That's why we need a new structure. 261 00:22:48.359 --> 00:22:54.359 And new systems and a new way of thinking. And what occurs to me right now, 262 00:22:54.359 --> 00:23:00.359 Georg, as you were explaining this: the topic of electronic identity takes on an entirely new significance. 263 00:23:00.359 --> 00:23:06.359 E-ID. Perhaps also the E-ID, but let's first stay with the HIN identity. 264 00:23:06.359 --> 00:23:12.359 Family doctors, nurses, hospitals -- everyone knows this HIN identity. And it's an electronic proof of identity 265 00:23:12.359 --> 00:23:18.359 with some additional attributes. Very significant, right? We've been doing that very successfully for several decades. 266 00:23:18.359 --> 00:23:24.359 And then you authenticate yourself or it's like a key and then you can open applications. 267 00:23:24.359 --> 00:23:30.359 That's HIN identity. But to address the topic that Georg just outlined, ... 268 00:23:30.359 --> 00:23:36.359 namely making structured data exchangeable, we need a new way 269 00:23:36.359 --> 00:23:42.359 of identifying the object. And our existing 270 00:23:42.359 --> 00:23:48.359 identities don't work for that at all. And that's where we've developed solutions 271 00:23:48.359 --> 00:23:54.359 so that we can develop novel approaches to the trust problem in the exchange of 272 00:23:54.359 --> 00:23:59.930 structured data. And is this some kind of 273 00:23:59.930 --> 00:24:05.930 special technology that you use? Or what's new about it? 274 00:24:05.930 --> 00:24:12.539 The whole thing is based on the principle of decentralized key management, 275 00:24:12.539 --> 00:24:18.539 or also Self-Sovereign Identity, SSI. The Swiss E-ID 276 00:24:18.539 --> 00:24:24.539 is also based on exactly this principle. And ultimately it's about every 277 00:24:24.539 --> 00:24:30.539 device and every person receiving an identity. That means I have 278 00:24:30.539 --> 00:24:36.539 identities for individual services in the hospital, but also for agents, 279 00:24:36.539 --> 00:24:42.539 when I think about agentic AI topics and so on. Basically, every interaction needs to exist 280 00:24:42.539 --> 00:24:48.539 between two identified identities. Do I understand correctly? You're using 281 00:24:48.539 --> 00:24:54.539 the same technology that the federal government uses for the E-ID? The same architectural principle 282 00:24:54.539 --> 00:25:00.539 underlies it. What we're building goes even a level deeper, 283 00:25:00.539 --> 00:25:04.539 because it needs to be even more decentralized than what the federal government 284 00:25:04.539 --> 00:25:08.539 is currently building. Because the federal government is on its own. The federal government issues the E-ID. 285 00:25:08.539 --> 00:25:12.539 I don't get a Swiss passport from anyone else other than the Swiss government. 286 00:25:12.539 --> 00:25:18.539 That's why it's much more centralized than what we're building. Because that's appropriate for the use case. 287 00:25:18.539 --> 00:25:24.539 But for us, every hospital is of course its own world, 288 00:25:24.539 --> 00:25:30.539 almost, with lots and lots of systems, lots and lots of people, lots and lots of services, and in the future 289 00:25:30.539 --> 00:25:36.539 also various agentic AI scenarios and so on. And that's already a federation in itself. 290 00:25:36.539 --> 00:25:42.539 And this federation needs to be able to interact with other equally complex federations. 291 00:25:42.539 --> 00:25:48.539 And they need to be able to identify each other in such a way that they know: this request comes 292 00:25:48.539 --> 00:25:54.539 from this automated system, from that hospital, and it is actually authorized by that hospital 293 00:25:54.539 --> 00:26:00.539 to make this request to me, so I can tell my local system: yes, this system is authorized 294 00:26:00.539 --> 00:26:06.539 to do that. The whole thing gets complex fairly quickly if you want to solve it properly. 295 00:26:06.539 --> 00:26:12.539 But we have to solve it properly, because otherwise we just have a kind of 296 00:26:12.539 --> 00:26:16.539 vague sense of, oh, that came from that hospital, it'll be fine. And afterward I can't prove 297 00:26:16.539 --> 00:26:22.539 anything about what it was about, who it was, which system asked, did I deliver the 298 00:26:22.539 --> 00:26:28.539 right data? None of that can be proven afterward. And if something goes wrong, that would of course 299 00:26:28.539 --> 00:26:34.539 be a huge risk. You really can't accept that. That's why we need this level of security 300 00:26:34.539 --> 00:26:40.539 and traceability and auditability. Why can we do this? Because we 301 00:26:40.539 --> 00:26:46.539 actually already have a basic infrastructure in place today. It already exists. It already exists, 302 00:26:46.539 --> 00:26:52.539 exactly. It's now being replaced. And then it'll still exist, right? And this new 303 00:26:52.539 --> 00:26:58.539 basic infrastructure will then be the foundation for exactly what Georg described. And this basic infrastructure 304 00:26:58.539 --> 00:27:04.539 exists for all of Switzerland. Do I understand that correctly? So, I should also ask, 305 00:27:04.539 --> 00:27:10.569 we've heard about how many millions the federal government wants to invest in 306 00:27:10.569 --> 00:27:16.569 the coming years for healthcare, to build, for example, a Swiss Health Data Space. 307 00:27:16.569 --> 00:27:22.569 What's the connection? Or is there even a connection? Are you actually already building 308 00:27:22.569 --> 00:27:28.730 what the federal government is only now planning to tackle? That's an interesting question. 309 00:27:28.730 --> 00:27:34.730 HIN is renewing its basic infrastructure. HIN is renewing the way 310 00:27:34.730 --> 00:27:40.730 services are delivered. And HIN is working to ensure that ultimately the topic of 311 00:27:40.730 --> 00:27:46.730 digital sovereignty can be realized for every single member, whether an individual person 312 00:27:46.730 --> 00:27:50.730 or an organization. That's what we're doing. We're doing that independently from the federal government. Parallel 313 00:27:50.730 --> 00:27:56.730 to that, the DigiSanté program does exist. We're monitoring it. We're in dialogue 314 00:27:56.730 --> 00:28:02.730 with DigiSanté. We observe, at least as I understand it, 315 00:28:02.730 --> 00:28:08.730 that DigiSanté primarily ensures that certain rules, certain 316 00:28:08.730 --> 00:28:14.730 framework parameters are defined so that such a data space 317 00:28:14.730 --> 00:28:20.730 can emerge. And whether this data space will one day replace the HIN trust space, 318 00:28:20.730 --> 00:28:26.730 which has actually already existed for nearly 20 years, or whether there will be connections, 319 00:28:26.730 --> 00:28:32.730 that remains to be seen. All of that is still completely open. ... 320 00:28:32.730 --> 00:28:38.789 Exactly. And if I may briefly add to that. I mean, we, Vereign, 321 00:28:38.789 --> 00:28:44.789 we also built the base layer for the European data space project Gaia-X. This exact 322 00:28:44.789 --> 00:28:50.789 key management identity layer comes from us there. And we accompanied all the healthcare data spaces, the projects, 323 00:28:50.789 --> 00:28:56.789 the lighthouses. ... We worked with the Berlin Charité and others 324 00:28:56.789 --> 00:29:02.789 to look at exactly these topics. But that's the technical reality. That means 325 00:29:02.789 --> 00:29:08.789 there is the higher-level semantic, administrative reality. What does it need to represent? 326 00:29:08.789 --> 00:29:12.789 But underneath, there's the technical reality. And that's what I value so much about our 327 00:29:12.789 --> 00:29:18.789 collaboration, because HIN is pragmatic. They start where they can create value at the 328 00:29:18.789 --> 00:29:24.789 technical level. And we're solving the problem technically in such a clean way that we're laying the foundation 329 00:29:24.789 --> 00:29:30.789 to properly implement such topics in Switzerland in the future. And let me unpack what value means in this context. 330 00:29:30.789 --> 00:29:36.789 Value for us means: when you zoom into a practice, ... everyone has a good 331 00:29:36.789 --> 00:29:42.789 practice information system. Some are in the cloud, others are installed locally 332 00:29:42.789 --> 00:29:48.789 on-site, however it is. They all work in a highly modern and digital way. Now, when it happens 333 00:29:48.789 --> 00:29:54.789 that a patient is referred to a hospital, for example, there are work processes 334 00:29:54.789 --> 00:30:00.789 and the systems support that. But ultimately, it's just as cumbersome. It's just as 335 00:30:00.789 --> 00:30:06.789 cumbersome, because each is an IT silo and there are no automatically existing connections. What we mean by value 336 00:30:06.789 --> 00:30:12.789 is that in the future, when a doctor makes a referral from a primary system, 337 00:30:12.789 --> 00:30:18.789 they should ideally not have to deal with duplicate data entry, intrusions, and manual process- 338 00:30:18.789 --> 00:30:22.789 interrupting activities just to finally get that thing out of their practice. 339 00:30:22.789 --> 00:30:28.789 That brings us back to the administrative burden. That's where we come in. Exactly, that's a good point, David. 340 00:30:28.789 --> 00:30:34.789 What actually happens then is that the administrative burden gets reduced. 341 00:30:34.789 --> 00:30:40.859 The administrative burden is usually not billable. It's not billable. 342 00:30:40.859 --> 00:30:46.859 It's dead time. It's unnecessary. From the doctor's perspective, it's just 343 00:30:46.859 --> 00:30:52.859 ballast. And that's where we come in to ultimately make the whole thing much 344 00:30:52.859 --> 00:30:54.859 simpler and sovereign. 345 00:30:54.859 --> 00:31:03.859 So for me, this has definitely been 346 00:31:03.859 --> 00:31:09.859 a lot of information that we've heard today. And I'll try to summarize it 347 00:31:09.859 --> 00:31:15.859 in a few points. So my takeaway is: we started by discussing the challenges that exist 348 00:31:15.859 --> 00:31:21.859 in healthcare. And my takeaway is that HIN, with partners and service providers -- Vereign is one of them -- 349 00:31:21.859 --> 00:31:27.900 is trying to create something ... that makes the whole thing easier in terms of 350 00:31:27.900 --> 00:31:33.900 communication between all these stakeholders. Between hospitals, practices, clinics, 351 00:31:33.900 --> 00:31:39.900 care homes, whatever. Whoever. And that the platform renewal 352 00:31:39.900 --> 00:31:45.900 is in full swing. It's a journey. It's about new technologies. 353 00:31:45.900 --> 00:31:49.900 We heard about SSI, which the federal government also uses. So for me it sounds like 354 00:31:49.900 --> 00:31:55.900 when the federal government uses a technology that HIN was already using before, 355 00:31:55.900 --> 00:32:01.900 that's like a validation that it works. That's how it sounds to me. 356 00:32:01.900 --> 00:32:06.500 And yes, there's much more to come. Can you 357 00:32:06.500 --> 00:32:13.049 quickly confirm whether my summary is roughly correct? 358 00:32:13.049 --> 00:32:19.049 I find it quite good. Exactly. Wonderful. And then I'd like to turn to you once more. 359 00:32:19.049 --> 00:32:25.049 If you could express a wish to the politicians or whoever it may concern, 360 00:32:25.049 --> 00:32:31.049 what would need to happen so that things perhaps move faster, so that 361 00:32:31.049 --> 00:32:37.880 healthcare professionals have an easier daily working life? Georg. I should go first? Yes. 362 00:32:37.880 --> 00:32:44.650 Yes, for me it's clear. I believe it would be extremely helpful 363 00:32:44.650 --> 00:32:50.650 to... understand data as an asset and as a competitive advantage for 364 00:32:50.650 --> 00:32:56.650 Switzerland. And I would wish that the federal government would leverage this competitive advantage much, much more, 365 00:32:56.650 --> 00:33:02.650 really as a -- in English you say it so nicely -- force multiplier. There's an organization with which 366 00:33:02.650 --> 00:33:08.650 I can very efficiently implement the technical reality, and they're already doing it. So for me, 367 00:33:08.650 --> 00:33:14.650 I would wish that the federal government would get much, much more on board with this and actively participate 368 00:33:14.650 --> 00:33:21.099 and actively promote and support it. Collaborate. Wish sent, I'd say. 369 00:33:21.099 --> 00:33:27.099 Peer? You're quite the charming partner. I've never heard that before. You'll get the bill for that 370 00:33:27.099 --> 00:33:33.099 later. Right. I think that was a good one. 371 00:33:33.099 --> 00:33:39.099 I have a different wish. I have a very modest wish. His was really great. 372 00:33:39.099 --> 00:33:43.099 I mean, mine is much smaller. I wish for less 373 00:33:43.099 --> 00:33:48.819 regulation. That deserves its own podcast for people who 374 00:33:48.819 --> 00:33:54.819 deal with regulation. Happy to, I'm in. So less regulation. 375 00:33:54.819 --> 00:34:01.049 Regulation, because that means less bureaucracy. Or why less regulation? 376 00:34:01.049 --> 00:34:07.049 Yes, I think that's good. I like it, because regulation is a form of bureaucracy. 377 00:34:09.050 --> 00:34:15.050 Of course, I mean, we don't want -- I don't want the Wild West, anarchy. 378 00:34:15.050 --> 00:34:21.050 God forbid. But I observe -- we are a unique state construct. 379 00:34:21.050 --> 00:34:27.050 We don't just have one healthcare system. It's a cantonal matter. That's all fine. 380 00:34:27.050 --> 00:34:33.050 And I think that's one of the most incredible achievements. But, but, but, but, when you actually 381 00:34:33.050 --> 00:34:39.050 look at it, in my humble view: there's a certain lived reality. There's a lived reality 382 00:34:39.050 --> 00:34:45.050 in the healthcare and social care system. And it's already complicated and complex enough. And when, constantly, 383 00:34:45.050 --> 00:34:51.050 triggered by our parliamentarians, ... more and more demands are made 384 00:34:51.050 --> 00:34:57.050 that the administration then has to respond to, that's self-explanatory. But this 385 00:34:57.050 --> 00:35:03.050 ... ... ... 386 00:35:03.050 --> 00:35:09.050 ... the force, the weight of these regulatory 387 00:35:09.050 --> 00:35:15.050 requirements is growing so much that nobody can keep up anymore. 388 00:35:15.050 --> 00:35:21.050 And I sometimes get the impression that clearly, internally too, there are certain 389 00:35:21.050 --> 00:35:27.050 coordination challenges. And that blocks progress. What I really care about is: less regulation, yes, less bureaucracy, 390 00:35:27.050 --> 00:35:33.050 but no -- my main concern is that if yet another law comes along and 391 00:35:33.050 --> 00:35:39.050 yet another ordinance and yet another appendix, that leads us into stagnation. Because everyone 392 00:35:39.050 --> 00:35:45.050 says, okay, now I first have to wait, right? Let's wait for that framework, that law, and this and that. 393 00:35:45.050 --> 00:35:51.050 And then we're somehow in the year 2035, right? And the core problems -- unlocking value, 394 00:35:51.050 --> 00:35:57.460 simplicity -- simply fall by the wayside. That really would be a topic for its own podcast. 395 00:35:57.460 --> 00:36:03.460 Thank you so much, Peer, for being here today. It was great having you. Thank you so much, and thank you too, Georg. 396 00:36:03.460 --> 00:36:09.940 Thank you for the invitation. That was the second episode of the HIN podcast, Insight: Navigating 397 00:36:09.940 --> 00:36:15.940 the Digital Healthcare System. If you have questions or comments, please check our show notes. 398 00:36:15.940 --> 00:36:21.940 You'll find all the contact details you need there. And if you've only listened to this podcast as audio, 399 00:36:21.940 --> 00:36:27.940 I'd like to point out that you can also watch it as video, ... for example on YouTube or 400 00:36:27.940 --> 00:36:33.940 on Spotify. Thank you for being here today, dear listeners. Or dear viewers. 401 00:36:33.940 --> 00:36:39.940 All the way to the end -- I really appreciate that. We'll be back in June, and then it's Happy Birthday, 402 00:36:39.940 --> 00:36:45.940 HIN! HIN turns 30. We'll talk about how HIN went from email 403 00:36:45.940 --> 00:36:51.940 to -- well, we heard it today -- platform renewal, to where they are today. 404 00:36:51.940 --> 00:36:53.940 And I'm very much looking forward to it. 405 00:36:53.940 --> 00:37:04.550 Until then, take care! 406 00:37:04.550 --> 00:37:08.550 Thanks for joining. Until next time on Insight: Navigating the Digital Healthcare System.