Herald: Next up is a talk I've been looking forward to all day.

It's "Digitization. In eriner Pandemic. In the health department!"

German authorities and digitalization is more of an oxymoron than a beautiful reality.

And what one experience when public health departments suddenly become really

relevant in a pandemic is what Bianca Kastl will now tell us.

Bianca: Good evening, my name is Bianca Kastl and the topic for the next 40

minutes on this talk is "Digitization. In a pandemic. In the Health Department!".

Jo, who am I? My name is Bianca, you can find me at

bkastl.de on the Wold Wide Web, on Twitter at @bkastl and on Mastodon @bkastl@mastodon.social.

If you happen to find my office, you'll see "Digitalization" in front of it.

That's because that's my office sign.

And that's actually what I'm doing professionally right now,

because I'm, well, I've had a bit of a career in this area.

I'm actually a software project manager, I'm a web developer, but during the pandemic

I was in charge of the digital contact tracing in different health offices,

I'm currently working on a digitalization in the health office in Frankfurt,

as I mentioned, that was the sign, I'm the process

manager for IRIS connect, which is an interface for contact tracing in

currently 5 federal states, and I've also hacked the Luca app, maybe some of you know about that.

Jo, this talk is actually a meta talk.

That is, this talk does not go into many technical details in depth,

but goes into many different areas that all have something to do

with digitization, problems and experiences in the field.

If you want to look for any of my Luca Talks,

you can find them in the appendix at the end.

But for now, this is the attempt I made: "10 insights from the attempt to better manage the pandemic with digital tools"

in a relatively short form.

These 10 insights are not a priority for now, but rather

a historical, chronologically grown knowledge that you can perhaps share a bit from recent experience.

If you are wondering how I came to the topic of digital contact tracing, health offices, that is actually a very, very exciting story, because sometime in August 2020 I was once called and I was given the task "Yes, Mrs. Kastl, you must help us to abolish the paper economy in the health office".

That was also a very concrete announcement about what I actually had to do. We'll find out later how I came about this and what happened as a result, but my introduction to the topic of digitizing public health departments was actually a very practical one, namely in this pandemic in the area.

We have a pandemic right now, we have a lot of data, we have to track contacts, we can help with that. But a little bit more about that later.

First thesis: first experience that you have with digital contact tracking very particularly, but also with other topics, whether it's vaccination or whatever.

That bad user experience doesn't scale. That's actually obvious, it's just that I think you have to look at it a little bit differently in the topic of digitalization idie is happening now in health departments then.

We have scenarios that like to repeat themselves from user flows. For example, we have this one. The other day, an announcement was made in the middle of the year. Tell me, Bianca, we are creating a lot of contacts in the same household. Is there any way to simplify this? Um, it's actually always the same process. You phone a positive person, who usually has Corona, and then you ask them: Yes, you are now positive. Now they might have some contacts.

We have to isolate them now so that we can contain the infection.

Who are your other contacts? One will then find out. Yes, so of course, I am, live in the household.

Then, for example, my family, the children, um, life partners.

And, and from them you actually have to collect data somehow. Because it's a matter of, on the one hand, perhaps issuing quarantine notices to them.

But it is also about settlements of, for example, loss of work performance.

That is actually a data collection process. This is very often done by telephone. That it's very little digitized. I actually...

My entry point into that was to digitize that process. But that's actually making phone calls.

Asking people who they met in the relevant time period and then taking data from that. That process happens with everybody, with every case actually. At least when there were decent contact traces in quotes. Over and over again from the beginning. That means we have, for example, 100 cases a day. Then have contact tracing. That's like 4, 5 in the 2020 time. That's, of course, in the time that we live in now, with a lot of contacts or where we had a lot of contacts, it's a lot more, of course. So that means that you do the same user flow that you always do manually on the phone, so to speak, and type it out again and again. It's called I want to create a contact person for a case. I also want to say that this person is in the same household. The has then probably the same address, as the index person. So the positive Corona case. It might also have the same phone number and a lot of data will be the same. But somehow there is probably a lack of user flow. This is actually relatively easy to solve in the user experience by simply creating a button that says: Well, create new contact person in the household. Now, of course, you have to actually accompany this process. You have to listen to people and ask them: Yes, what hinders you most when using our software? Where could we optimize most? Where can we optimize continuously? And only then will we see the savings that actually result from using the software, such as when the whole family is on the phone. A button would help to actually make such software better.

Because software, so that it can be used meaningfully. And that software or services can really be used meaningfully, it needs not only good conception at the beginning, but it needs also always the adaptation to the use and it needs constant company. And I can tell you that when we developed this contact tracking software, in an agile process. It was not a SORMAS. I'm sorry. We also had relatively good experiences saying: Yes, well, let's take a look at what user flows we have that we can constantly optimize, because we actually save time because they repeat themselves, there's potential there. And yes, we have continuously optimized them in an agile user-user-story scenario, and this has actually had positive effects. As I said, in a health department, in the pandemic. It all works.

Second thesis: you should always keep software processes executable. One scenario we had in January 2021 was the first B.1.1.7 case. That's what's known today as alpha. This is a virus variant. At that time, it was the first major virus variant that was significant. There used to be the wild type. That was only Corona and then there was the virus variant B.1.1.7 and that was something special back then in January 2021, when it came to Germany. Because of course it was contagious again, it was more dangerous. And yes, how does something like that happen? How do you get mutants like that into a system? Yes, sometime on a Thursday, there was a phone call that said: Yes, now we have to quickly get the mutants in there. We recorded that very, very quickly, because we knew that it was of course relatively urgent. This should also be recorded in a meaningful way, because through mutants, various containment strategies are also connected to it. Because mutants have to be isolated better than normal cases. Because they are both somehow... already bad, but mutants were at that time even worse. And then the announcement was: Build this topic with virus variants into the system. And yes, we did that, it took three hours. After three hours we were done and deployed it in the evening. Um. That doesn't sound all that impressive. But I think you also have to see it that way, that this was of course also, uh, an ongoing product, which you could simply expand continuously. And it turned out that when we deployed it on Thursday.... We thought to ourselves, we have now created this sensibly, we have done it quickly. Was good. Will we need now soon in two weeks. No, it turned out: this feature, which we had finished on Thursday, was already needed on Saturday, because on Saturday there was the first B.1.1.7 case in the health department, which I was in charge of at that time. And you can definitely say that we then actually reacted so quickly to the changes that there were, um, that we then.... Actually, when we deployed the feature, the first case that was relevant for it was already on its way. That is, that is also the agility and the flexibility with which you also have to approach software processes. That was a bit like a... Yes, what is currently buzzing around a bit with log4j. You have to react quickly, and that was the same with the virus variants in software development.

But that only works if you have executable processes. That is, if you also have deployment, if you have development, if you have everything active and can also reactivate it relatively quickly. And it's never just a project where you say it's finished, it will never be developed further, it will never be touched again, but it's always a living software product. And projects are always such completed things that you never touch again. But it never is. Especially not in a pandemic.

Thesis number three: Agile working can also work in an administration. That sounds a bit utopian. Um, administrations, agile working, that doesn't really fit at all. But I can confirm that it can work. Um. 
Key data: We had an agile software project for six months. It was actually fully remote. In other words, some of the people in the administration who used this software and developed it with us were also remotely involved in this project. Now I said project. Well, on this software. And we actually then developed via video conferencing and fully remotely this issue for 6 months. We did that in scrum. There were 2-week sprints. We also tried shorter sprints at times because the topic was so dynamic. It was really about contact tracking and what changes dynamically. And a very dynamic field, by the way. And yes, we then tried to do shorter sprints. That didn't quite work. Two-week sprints are actually quite okay for an administration, because things change continuously. But people can then also train each other so that something changes. That worked quite well. And what actually also worked quite well, surprisingly, was software-related communication via GitLab. That is, introducing people to issues and to milestones and to project-related communication, and not sending emails back and forth in a haphazard way, worked wonderfully, was wonderfully accepted, was easily visible to all people, and was actually a complete success. I don't really know why we don't work more with structures like GitLab or issues, milestones, project boards for some things, it seems that administrations are still a bit sleepy. 
The result of this whole software approach was that we actually achieved this contact tracking of cases and contact persons measurably to 90% of all cases and contact persons on a daily basis. That is, we reached 90% of all cases and contact persons, that person also on the same day. That is also what you have to do in order to somehow achieve containment in this pandemic. Everything you process has to be up to date on the same day. We have also managed to digitally integrate all those involved in this entire process via a platform. One of the parties involved was, of course, the public health department. The health department is responsible for recording this contact person, for recording these cases. But that also goes on to the public order offices, which then take care of the quarantine notices. At least that is the case in Baden-Württemberg. And then it also goes to local police authorities, which then take care of the quarantine monitoring. This means that we also have 23 municipalities connected to a system. That was quite exciting, even when we explained to them that they now have to use two-factor authentication. That worked, too. And yes, it was not SORMAS. But more about SORMAS later, perhaps. But as you can see, it can actually work in a pandemic to develop digital software in an agile way, even in an administration, because people have also seen: Okay, there's a lot of data, so we have to optimize our processes somehow and see if we can somehow manage it better. And when you have a lot of data and people and a certain amount of pressure, who also recognize that they can influence their processes independently and change them for the better, then they actually want to do that, even if they are in administration. That is the insight that I can now pass on. I don't know whether it would have worked so well outside the context of this pandemic. But because there was always a certain workload, it worked surprisingly well.

Yes, working well is another issue. What I think is also important, if you have any learnings, if you do anything good, you should also write about it. I wrote this wonderful article in March 2021, "The Corona Interface and Other Problems." It's an article that actually kind of describes how the systematics work with SORMAS, what is DEMIS, so DEMIS is the interface for laboratory data. Then there is SORMAS, for example, then there is SurvNet, where these cases are then transmitted in health offices. That was actually a basic article. As I said, I published the basic article on March 1. It was lying around for a while and somehow picked up a bit of wind. And then relatively exciting reactions came back. I once got fan mail from Smudo, the Smudo who then later tried to sell the luca app. I don't think he writes fan mail anymore, but back then there was fan mail from him. There were a relatively large number of reactions from people who had some idea about the subject. I also received inquiries from people who simply realized: Look, you really know something about this topic, can you explain this and that to me? Actually, only because I wrote an article. So the article, was probably demonstrably somehow quite okay. But as you can see, I think it always makes sense, no matter in which professional contexts you are on the road, to share your experiences and your knowledge. And I don't know what would have happened if I hadn't written this article. I probably wouldn't be sitting here giving this talk. That's actually one way to look at it. And yeah, so like I said, if you guys are doing good stuff, write about it. 
So, let's move on to the topic of digitization. My favorite topic at the moment. And here's my thesis: meaningful digitization doesn't just electrify analog processes. That used to be the platitudinous phrase "If you digitize a shitty process, you'll have a shitty digital process." I would now formulate it in such a way that digitization is simply more than simply drilling out what is analog in some way with electronic means of communication. 
When dealing with digitalization issues, you should always ask yourself the question: What problem do we really want to solve? And there are two examples of this. This is the wonderful reporting chain. It's called the German computerized reporting system. That's actually how the reporting chain of Corona cases still works for the most part. This is taken from a description of SurvNet from 2006, actually 15 years old, but we see that, for example, when a patient receives a pathogen detection from a laboratory, this pathogen detection - at that time it was still done by fax, now it is done digitally - goes via DEMIS, i.e. a digital interface, which was also created in this pandemic, to the local health department. The health department also has personal data from this person in order to contact this person. The health department then sends that data via SurvNet via some sort of email, so that's an email with transport data, to the state health department, which is usually the state health department. And that in turn summarizes these things and then sends these things, again via SurvNet, to the Robert Koch Institute. In the end, the RKI always receives these daily figures of corona cases or other infectious diseases, but currently corona is what people are interested in. And we then see topics like: There was once a 24-hour delay from the laboratory to the public health department. That still works out quite well. The delay between the health office and the state health office has become a bit shorter, at least no longer days and no longer a week, where the state health office needs to send it to the Robert Koch Institute. It actually does that on a daily basis now, but the process as such is still essentially the same. This topic is still being sent around in many different ways, and because it is sent around in so many different ways, regardless of whether it is SORMAS or not, the process is not necessarily faster and more efficient, but it is still a process with many, many pitfalls. Even if you were to use SORMAS at some point and say "We think that's great", you still have something at the front where you have to transmit case data, you still have a connection to SurvNet, and sometimes you also have a connection to the state health offices. So, as I said, SORMAS is simply a modern shell for the process, which is currently not really successful anyway. 
Because the question is really: Are we interested in a quick overview that is as up-to-date as possible? Or is it about digitally mapping the administrative structures that we actually have? This structure, which I have just shown you with this reporting chain of, yes, first goes to the health office, then it goes once from the health office to the state health office and then now it goes to the RKI, is simply a normal administrative structure, because that's just how the responsibilities are in this area. And this has been mapped digitally. The fact that this does not really scale well, that reporting chains in Germany are a bit inefficient and so on, is also due to the fact that the technical maturity of the solution in between is not really good, that it does not really scale. People have simply said: Okay, you take what you have as an administrative responsibility and build such a reporting chain and then do it digitally. That would also be much more efficient and faster. For example, it is also very exciting that these reporting chains from health authorities are only ever carried out once a day. No one knows why, but that's just the way this digitally reconstructed file run is. People in public health offices ask me why they still have to transmit the data manually when they have already closed the case. Yes, you just have a bit of this administrative thinking - with files and you then put the files on a trolley and then push them on to the next office - digitally mapped. And yes, you could also make this principle simpler. Of course, you could take out a few parts of the chain and make it more efficient, but somehow it looks like it's digital to the outside world. But it's really just an electrified file flow from one authority to the next and, accordingly, it's not really fast and not always very resilient. The next candidate for electrifying processes that I have is the wonderful subject of Luca. This is such a chronology of how Luca then queries data: You take the notification from the health department, then the person is contacted. They then release things, they then realize: Okay, you have to request things from a location and then these things are released and then you can look at the check-ins to see who had contact. You then try to contact these people somehow, whether it's by phone or now probably also by chat or by alert or whatever. But it's a manually triggered process.

This process has of course worked from this, also times the big question: What should we now actually do here with it? Do I want to warn people as quickly as possible about risk contacts? That would just imply, well, positive people were contacts, maybe in digital, like the Corona warning app does, for example? Or do I want this data collection process that's always happening, so to speak, with Luca? So I checked in where, I registered, and then I sort of gave my data digitally, then I sort of send that to a server where things are queried by the health department and processed. Do I want to replicate that? As I said, again an electrified process not really thought completely digital, but just ah yes, what was in the Corona regulation in it, tried to digitize as best as possible. You also created some collateral damage in the area of IT security. Great. But yes, that's not really the, the evolution in the sense of a successful digital process.

We recognize: consistent digitization changes responsibilities, in some cases completely. It may even give established structures the feeling that they no longer have control over the process. What do I mean by that? This actually successful digital warning process, which we now have with the Corona warning app, for example. It's actually one that no longer has any intermediaries for data, but rather the person in question always releases his or her test result directly and warns others. That is the most direct way. But it is also the one that works the fastest. And it is also the most resilient. Because if one part of the chain falls out, then we now have one test less. But the general chain does not somehow depend on individual single points of failure. Yes, but of course: health authorities are not really enthusiastic about it, because they don't really have any more control over this process, the CWA, because they don't have anything from it anymore. So the only, the clientele that comes from the CWA is then at most the ones that then test positive. But with the rest of the people, they don't really have any influence anymore, because they are anonymous people. This explains a little bit why Luca was so well received by the health authorities at the time; partly, not all of them. Because they had the feeling that they had the illusion of control, because data suddenly came out that could have been used for something if they had had the time. But of course that is not a successful, efficient digital process. 
The issue of Luca, the issue of security, is also not so successful. We now have... Luca was advertised a lot: We have everything encrypted, and also double encrypted, and that is totally secure. But we have learned that cryptography alone does not solve security problems. There are two security gaps, which I can now quote here as officially confirmed by the Ministry of Social Affairs, Health and Integration of the state of Baden-Württemberg. Uh, just in case anyone should deny this again. The spying out of QR codes, QR code key fobs, the possibility of copying the code to access the contact history of the deposited code. And we still have the issue of code injection when health departments download CSV files. Those are two things that actually went completely past all of this encryption. What happened? We have the LucaTrack issue, where I was involved together with Tobias Rabenstein. And what did we find there? At Luca, there were key fobs that were QR codes where you could check in to the Luca system. However, an endpoint was created for these QR codes, from which you could then also read out the movement history of these QR codes at will. Meaning: if you had the QR code, you also had the entire movement history for all of the several 1000 key fobs. Encryption doesn't help you any more. Because if you also store the key with it, then you can also cancel your crypto concept. You can also destroy your crypto concept if you get the idea. Hmm, so let's assume that I now insert code into this Luca that perhaps tries to generate things with CSV, for example, to resolve a formula in Excel. Can I actually get that through? Yes, that's what happened when Markus Mengs demonstrated this issue with CSV injection at Luca. We have malicious code in Excel, write it in Luca in, for example, a contact data field. We take the postal code because it is particularly absurd and then enter... Of course, we have not entered the formula directly. But we enter a comma and then make a formula afterwards. That was the whole joke with the number. And then we get the health department to open these data. Yes, they probably have to open it, because they want to do contact tracing. So you have to work with that data. Open up that data in Excel and tada! Theoretically, you could drive a ransomware on a health department. That has also been described as plausible by the BSI. You have to take it a long way, but it is certainly plausible. And there's no point, of course, if you have a crypto concept. If you as a crypto have a concept, if the crypto concept doesn't care at all what data is actually being pushed around. We learn that cryptography is great, but of course it doesn't replace other security concepts and other security measures that you should actually take before you possibly put some crypto concept on top of something and say to yourself: Yes, great, it's now secure because of crypto. That is rarely the case, but rather an add-on.

Like that. What I also saw a bit of through the scenario with Luca is a phenomenon that I would call the digital-savior phenomenon. There are people who say I can do digital technology here. I can do software. I can now solve all the world's problems. That is mostly nonsense. Because digital saviors can't solve problems on their own. The following episode from my everyday life illustrates this. In March 2021, I had the opportunity to pilot the Luca app together with the Lake Constance District Health Department. And we were allowed to try it out a little earlier and were supposed to form an opinion about it. And we realized relatively early on that this topic is extremely unsuitable for contact tracking, mass and efficiency and whatever else. We told the good manufacturer about a few bugs, a few features, feature requests and other things. Most things of it he has done in the meantime of it also times. But he got quite a lot of product development know-how also from health offices. Yes, but this Luca was just not really the last word in wisdom and also not really the big winner. That was as said in March 2021 already, was already determined professionally, with the help of my person. This is also quoted in the ZEIT in this wonderful article by Eva Wolfangel. And what also came up in this article in addition to this problem that it was developed technically simply Luca the product relatively yes past reality and it is of course also not the role of the health department to provide development assistance for private operators, of course also came up that health departments of course this software also can not audit. Because a public health department is actually not in a position to conduct such an audit of individual providers. The fact that I did this in my spare time is a relatively funny episode, because on the one hand, I had already been involved in the technical aspects of Luca, and on the other... Yes, of course you also want to know how something works technically as a good nerd. That's why I looked at it a little bit on the side, like now, what the technology behind it is. After we found out that the technical subject matter was not really well covered. And yes, we notice with this topic Luca also again and again that it ... There are people who say: I solve problems with digital tools. But most of them are very ignorant about the subject. Because they have ... understand the digital world, and therefore they also understand the world somehow. But they usually don't understand the technical dimension. On the other hand, there are experts who are often digitally ignorant. I know many manufacturers of specialized procedures who say: "This is a great specialized procedure. This is also the case in public health departments, in the context of contact tracing, in specialized procedures for infection software, SORMAS. These are technically good, but mostly not quite digitally mature. However, we recognize that successful digital applications are actually only created through technical and digital expertise. And, always very important, of course you can build such an expert system. But all of this will only work if you really build it in a user-centric way. Be it for citizens or, for example, a B2B application for your, yes, the users in your offices, administrations or other expert systems.

So when you build applications like that, you should actually think differently first. You should first think in terms of infrastructure, in terms of APIs, and then in terms of applications. But that's a bit difficult, because people actually want apps. Apps, on the other hand, don't fill any digitalization gaps. As we mentioned with Luca, there's a check-in app that does check-ins, but it doesn't solve certain problems that might be repeated. So for example, the issue of "How can I transmit end-to-end encrypted data to an office if I want to exchange information as a citizen.in, on an abstract basis?" Of course, I can now say that Luca can now move data back and forth, but that is not an open standard, rather it is somehow a very special system that works with double encryption, which is also very specific to the use case of contact tracing. Because it is really rare that you park data with a provider and then send it to an office. Most of the time there is a direct exchange. But when you build a basic infrastructure like this, and if you build it now in a pandemic, then it's not perceived as particularly innovative. But of course it's a problem if it's not there, because its absence then prevents digital innovation. So, ideally, though, you shouldn't just create apps, you should actually provide digital infrastructure. We once tried to outline that with the topic of IRIS, so as a counter design. This is the architecture of IRIS Connect, which is a similar system to Luca: that also tries to connect guest list apps to health departments and we see a couple of things here. For example, we have an IRIS client in the health department, which is this one. And then we have, for example, a central part in the system, but those are basically just things that are necessary to make connections. But actually we have different clients in respective health departments. We have connectivity to appropriate apps, we have certificates, we have endpoint systems like that. We have the option of using public and private proxies to transmit data to offices, provided they request it, and we actually have a system at the abstract level that simply solves a digital basic infrastructure problem and which then connects guest list apps as a side effect, but which actually does much more because it simply represents a basic infrastructure. You can also use this later for other topics. It doesn't have to be guest list apps, it can be drinking water controls, it can be whatever, because you have the infrastructure. You haven't built an app, you've cast an infrastructure in code. And that's like I said, we see IRIS Connect as connecting apps, but also as the basis of public digital infrastructure.

Let's come almost to the end to the topic with good intentions. They don't protect against problems. We had a request in June of this year or May of this year, which was called, "Can you do a security audit there?" It was about an immunization portal. So "what is it about?" "Yes, we have a few thousand emails from people who want to be vaccinated." In this moment was then actually also already again, we beat the hands together over the head and thought us "Yes, how, you collect here enamels, makes actually also still such a kind vaccination register. Have you actually understood what you are doing? So you're collecting emails, maybe you're sending them some vaccination appointments with some doctors, and you're also logging data from them? It's already a problem what you're creating." There was only a limited awareness of the problem. Awareness of the other problems with such architectures was also limited. But with some advice and support on architecture and other things, we were actually able to support this rescue project in a way that could save it.

If you're wondering what kind of portal it was, it was called "sofort- impfen.de". They collected a lot of data, onboarded a lot of doctors and tried to provide a lot of vaccinations. But in fact it is also like this: even if you have a rescue project and you try to improve problems in the world somehow with digital knowledge, you must also be aware that your good intentions can also have side effects. In the area of data protection, in the area of IT security, in the area of liability, in the area of anything else. It's not always just about Rescue Project, it's also always about the responsibility you take on; you should always be aware of that.

So as an insight from immediately- inoculate.com. 
Which leads me to the last slide, the last thesis: there's always a bit of frustration about the broken state of digitalization. It's perfectly fine to take that frustration and say "let's make it better." Take your frustration, make it better, and that's now also the end of my talk and I would then take questions.

Herald: Yes, thank you Bianca for that insightful talk. If you have any questions now, feel free to ask them on Twitter or Mastodon under the hashtag #rc3cwtv, which is chaos west stage TV, and then you can also answer me right now afterwards. The first question would be: What are the chances that other administrations, organizations, Bürgeramt, will follow this example in digitalization? In particular: Are there contacts with ITDZ, i.e. in Berlin, or do they want to do everything on their own?

Bianca: Basically, the chances of best practices being copied are good. But you might also have to look a little bit at what was particularly pandemic-driven and what was a bit improvised? What might have been done a little differently under different circumstances? But I think we have at least understood that you can actually do something like this in an agile way. But I think it always depends a bit on the respective municipality, the respective ministry, whether everyone really wants it. And in the pandemic, everybody wanted it, so it worked quite well.

Herald: What about open data? Basically, the data can be published. Journalists would also be interested in it. And there were also complaints because the RKI changed a format unannounced on the weekend.

Bianca: Basically, all these data, the health offices, can give out or transmit them. At some point, they no longer have any personal reference. This means that, theoretically, you could also go in the direction of open data. There are also municipalities that, for example, make at least their daily case number data and other data available somehow as CSV. However, there is not such a pretty REST API in which you could somehow deliver Open Data. SORMAS, for example, doesn't have that either; SORMAS is more of an internal specialist system that exports data as needed. But they haven't quite arrived in the API age, so that you could integrate it with Open Data in a meaningful way, unfortunately.

Herald: Can you give a classification of whether an immunization register is feasible with the current data situation?

Bianca: Well, from a purely technical point of view, many public health departments currently have a bit of a problem that if someone now says, of course, that they've been vaccinated because they want to escape quarantine, then the verifiability is relatively difficult because actually - there's no meaningful way to securely determine this data. So encrypted e-mails are not available in the health offices, fax is also nothing. And often, data is collected by telephone, batch numbers or other things, in order to at least verify whether this vaccination makes sense. That would be a rather cumbersome way of setting up such a register. It would just be manual rework. If you wanted to set up a registry like that -but that's really just the theoretical possibility, I personally have my doubts about that- you would probably do it at some major action that's going on anyway, whether it's some booster vaccination, other things, that would probably be easier to do that kind of thing.

Herald: If you're a specialist working on a problem and you're lacking information, where do you find it first outside of your own county or state? The federal government or another state?

Bianca: That's a little difficult to find the information there. There are these federal regulations that you can find relatively well at the federal level, if they apply to the federal government. Of course, there are always these whole state numbers. So what I had explained with Ordnungsämter and Ortspolizeibehörden, that was so in Baden- Württemberg special number, you then always have to find at the state, because the state has a deviation from what applies in the federal government. And also with everything that has to do with Corona, there were always the Corona state ordinances, compared to the federal government. So it's actually always: first look at the state, and then see if maybe there's still a federal regulation that then somehow still conflicts with that. But mostly it's the state, actually.

Herald: On the subject of the state and the federal government, it feels like no one wants to relinquish jurisdiction. If, for example, it's at the state level, it leads to each state cooking its own soup because they can't or won't agree on anything. Any ideas on how to cut through this Gordian knot? It doesn't help if everyone reinvents the wheel and then nothing fits together.

Bianca: It's a bit silly that you now have to bring in SORMAS as a negative example of something like this, because it was actually the federal solution to say, "We have a federal investment protection application," but then it didn't really work. I think you can already teach people that sharing data across federal state borders, especially also for example investment protection, is a sensible idea. But you really have to pick people up a bit where they can say, "Okay, here is a basic software: Okay, here is a basic software, but you can still adapt it a bit according to your state specifics and other things. Because somehow the sovereigns need that somehow still have their specialties in the software, because they are simply the state anyway. And in the sense of easily adaptable software, easily adaptable standards, you can do that. But you shouldn't assume that you're going to throw software in at the top and it's going to work great for everybody; unfortunately, you can't do that.

Herald: The next question would be Is the Luca app dead now from your perspective?

Bianca: Technologically, yes, and from the effect of a pandemic, too, because de facto, if no one in health offices gets around to triggering the Luka app, to retrieving data, nothing happens. That means that the workload is now so high that you can say it no longer has any effect. And we had actually said that at the beginning of this pandemic. That we would use it relatively rarely. Then they didn't believe us and spent a few million for a few months. Which is a pity, but somehow I think you only learn by wasting money. Apart from that, I don't see what other use there is for it, especially with case numbers, as might happen with Omikron.

Herald: What was the main communication tool then? GitLab?

Bianca: In communicating with how we did agile development, actually Gitlab, GitHub, depending on what projects that was in. And what was actually also exciting, in administration there are also such tendencies that people also start to chat and actually via the VoIP system. Sounds funny, but if the VoIP program can also chat, it's actually faster for people than writing an email. There's been that as well.

Herald: Does infection control make sense to you at the state level?

Bianca: I think infection control at the state or decentralized level makes sense, because you actually have to be close to the people. There are specifics that I think you can only find out in some data contexts that you only know if you have local knowledge. Whether each country needs its own corona ordinances or other things, I'm not sure now, but I would rather say: No. But I believe that this can also be done very locally - at least in the implementation, I think it's important to strive for a standardization of the legal regulations, because then perhaps it's a bit easier to handle throughout Germany.

Herald: You talked about the integration of municipalities, public order offices with 2-factor authentication. How did that work? The person asking the question can't imagine that with sufficient data protection.

Bianca: Yes, this is a Baden-Würtemberg special number. Normally, it is the case that the health authorities also carry out these tasks in the Union, so quasi the local police authorities are the ones who also monitor the quarantine. And in this case - in Baden- Württemberg it is like this: the police authority quasi monitors the quarantine and also transmits the documents for this. In Baden-Württemberg, there is also a tool for this purpose that has been coordinated with the data protection authority. This has its legal framework and has also been coordinated with the data protection authorities. The communication channel has also been coordinated, and so on. However, this is actually a special feature of Baden-Württemberg. Normally, it runs centrally via the health office of the respective district.

Herald: Someone else is interested in this - The question is: "I would like to know how the Corona warning app stores the data of the vaccination certificates. Are they reasonably secured against access by other apps? 
Bianca: Yeah, that's a really great topic, because that's just changed now. Normally, the Corona warning app actually stores the data only on the device and access by other apps is not possible, as far as I know. Now the Corona-Warn-App has released an update with version 2.15, in which it is then possible to transmit the vaccination certificate online with ticket bookings to a testing provider, in this case the Telekom - Lilith also talked about this in the keynote. That is, currently I can't say conclusively that it's secure, because there is this function that vaccination certificates are transmitted to online verification providers, which can then forward them to a ticket provider and say, "look here, is verified," but I can't say in the current state that that is completely secure, because there is this possibility for outbound transmission to these verification providers.

Herald: That's too bad. Does anyone know if states have renewed their Luca licenses yet or if they're all letting that expire? 
Bianca: So there is for example, in Baden- Württemberg - there I know it relatively well, because I sit here in Stuttgart - there is the option that this Luca thing runs for two years. And if the state doesn't cancel now, it will be extended, and I think it's like that in most of the states. There are federal states that have now changed their regulations so that the Corona warning app is also possible, for example Baden-Württemberg or Brandenburg or Bremen. There are indications that at least an extension is not being sought. However, there are federal states in which this will perhaps continue under certain circumstances. But I think that will only become clear at the beginning of the year until April, when the contracts actually expire. 
Herald: From your point of view, have the health departments learned anything and are better prepared for future pandemics? And I would like to add: Is it even possible to draw conclusions from this process to other agencies and bring them along better in digitization? 
Bianca: So I think public health departments, or public authorities in general, have understood that digitization can actually benefit something as well. That's because I think there used to be such a story, you're not going to get into a situation now where you then suddenly need somehow networked, decentralized remote offices and so on, where it would make total sense. They've already understood that it's not so completely wrong with digitization now, that it can also be used and that you can also use it to your advantage. The problem, of course, is that you can't suddenly have a hundred digital experts in the office from zero to one hundred, but you always have to work with the same resources that you have: There are not enough staff, the staff is poorly paid, there is a lack of competence, there is a lack of training, there is a lack of many things. To trigger a real change there, you would have to do more to transfer this digitalization flow that you learned in the pandemic to the post-pandemic. I believe that this has been recognized in public health offices, but I think there is a lack of resources. In other offices it has perhaps also been recognized that it would be quite good if one could perhaps also do home offices or something else and if this could work quite well with these portals. But there is a resource problem and I think you can take the spirit, but it depends on a lot of resources that just - partly this lack of resources is also home-made. 
Herald: You talk about we a lot. Who are you working with?

Bianca: Yeah, it's a little complicated to explain in detail in this talk. In principle, it's like this: this Talk is actually divided into two parts. I did this topic with contact tracing in the Lake Constance district with my company at that time in Stuttgart, which is the company cron. The topic IRIS was developed together with the InÖG and the Björn Steiger Foundation and the topic with the security things with people together, as you just do it. 
Herald: Cool. That was already the last question. Thank you Bianca for your commitment and that you also deal so much in your spare time with such things that concern us all. That was the last day for today here on the chaos-west-stage and I wish you all an enjoyable rC3.