Public Health Service: Between Digital Sovereignty & Patchwork

Contents

The Public Health Service (ÖGD) comprises municipal and state authorities responsible for protecting public health. This includes, among other things, infection control, drinking water monitoring, school medical examinations, and health reporting. The digitalization of this sector is proceeding unevenly: alongside open, reusable solutions, there are proprietary specialized applications. This has resulted in a heterogeneous IT landscape.

Currently, considerable financial resources, time, and development capacities are being used to further expand the digital patchwork rather than organize it. Federalism within the ÖGD leads to states and municipalities developing or commissioning their systems, which often only function within their context and are hardly reusable. Instead of interoperable building blocks, a multitude of isolated solutions are thus created, which are neither technically nor organizationally coordinated. From the perspective of many practitioners, it would therefore be more efficient to place a central, independent IT authority above the municipalities, which defines binding architectures, standards, and interfaces and ensures that digitalization in the ÖGD proceeds more harmoniously, sustainably, and resource-efficiently.

With the “Pact for the Public Health Service,” the federal government provided four billion euros for the modernization of the approximately 400 health authorities, including 800 million euros for digitalization measures. The funding guidelines of the Federal Ministry of Health (BMG) formulate digital sovereignty, interoperability, and nationwide reusability of solutions as goals. Projects are to be implemented, where possible, as open-source software with free licenses. The source code is to be made available in public repositories; deviations from this principle must be justified. However, it remains open how binding these principles will actually be enforced and controlled. The Federal Ministry of Health, which itself praises previous achievements in the digitalization of the ÖGD, has, according to the Academy for Public Health, already indicated that parts of the special fund will be made available for further digitalization of the ÖGD.

In 2024, a study showed that a significant portion of the funding flowed into independent state and municipal projects. These initiatives often had only limited integration with overarching structures. Instead of a coherent overall architecture, a multitude of individual solutions emerged. At the same time, open components already exist, such as a death certificate on an open-source basis in Schleswig-Holstein.

Open Source in the ÖGD: GA-Lotse and other approaches

A frequently cited positive example is the GA-Lotse, which is in use at the Frankfurt am Main Health Authority. The platform was developed in eleven months with a team of more than 60 external developers. It relies on a zero-trust architecture and has undergone multiple external security audits. The source code is publicly available under the AGPL-3.0 license. This means that central funding goals – open source, transparency, auditability, and reusability – are not just mentioned but technically and organizationally implemented.

Further open initiatives can be found in individual states. In addition to the death certificate in Schleswig-Holstein, Bavaria is developing additional open-source applications with the “ÖGD-Bürgerportal” and the “ÖGD-Handbuch.” These are intended to be used jointly by several administrations in the future but so far remain rather isolated solutions.

Proprietary strategies and growing market concentration

In addition, there are a number of proprietary procurement strategies, which are often accompanied by growing market concentration. In Baden-Württemberg, the specialized application “ÖGDigital” was awarded to the company HBSN. HBSN was later acquired by the Berlin-based Init AG, which, according to a report by Welt, profits well from public contracts. Init AG also acts as a service provider in other federal states, for example in Hesse or as a project manager for a contract in Thuringia. There, the responsible ministry emphasizes that the contract was not awarded by them to HBSN. Therefore, a direct conflict of interest cannot be established. In Bavaria, modules are also being developed by companies from the same corporate group.

In Baden-Württemberg, the source code and contracts for ÖGDigital have not been publicly accessible so far. Requests under the Freedom of Information Act were rejected with reference to trade secrets. The responsible ministry points out that the contract assures the state the complete handover of the source code. This allows for later further development independently or by third parties. This path was chosen to establish a clear governance structure and limit liability risks. According to the state, there is no obligation to use open source. An inadmissible market dominance by Init is not apparent.

Rhineland-Palatinate is modernizing the specialized application mikropro health, which has been in use since the 2000s. This is a proprietary standard software for health authorities, primarily used in the child and youth health service for case and administrative processing. According to the responsible ministry, the use of open-source components is not possible there, as it involves the further development of an existing proprietary product.

After a Europe-wide tender, Saxony opted for the commercial solution OctoWare from easysoft GmbH, a proprietary specialized application for health authorities, which is particularly used in infection control for case, contact tracing, and reporting management. According to a spokesperson for the State Ministry, the decisive factors were three points: immediate operational readiness, functional suitability, and cost-effectiveness. Own resources for in-house development were not available.

easysoft GmbH is no stranger to public administration. In Berlin, the company was a contractual partner for specialized software in the child and youth health service for years. Despite ongoing license payments, the solution was never deployed nationwide. It was mainly used for partial functions, for example, to support initial medical examinations. Departments repeatedly criticized outdated technical foundations and limited connectivity to modern, service-oriented architectures.

These examples show a structural tension: politically, the creation of open and reusable solutions is demanded. At the same time, contracts often tie administrations closely to individual providers and proprietary architectures. This also applies where source code transfers are contractually agreed upon but not transparently documented.