B3.0_Leistungsbeschreibung.pdf

[Seite 1]

[Hier eingeben]

Leistungsbeschrei-

bung

Anlage B3

Software zur Datenbewirtschaftung

Stand: 11.09.2026

[Seite 3]

Inhalt

Vorwort ................................................................................................................................. 4

1 Ausgangslage: Datenbewirtschaftungsprozesse im WIdO ..................................... 5

2 Kurzbeschreibung des Beschaffungsgegenstands und Ziel der Leistungserbringung .............................................................................................. 6

2.1 Anforderungen an die Software ................................................................................. 7

2.2 Beispiele als Ergänzung zum Kriterienkatalog .......................................................... 10 2.2.1 Beispiel zu Deployen Teil 1 Muss-4.1.1: .................................................................... 10 2.2.2 Beispiel zu Protokollierung/Monitoring Teil 1 Muss-4.2.2 ....................................... 10 2.2.3 Beispiel zu Logging und Monitoring Teil 1 Muss-4.2.1 ............................................. 11

3 Nutzung der Software: ........................................................................................ 12

4 Installations- und Betriebsbedingungen für IT-Systeme im AOK- Bundesverband ................................................................................................... 13

4.1 Entwicklungsumgebung ............................................................................................ 13

4.2 Serverkomponente ................................................................................................... 13

4.3 Softwareanforderungen ........................................................................................... 14

4.4 Anforderungen an IT- und Datensicherheit .............................................................. 14

4.5 Mandantentrennung................................................................................................. 14

5 Unterstützung bei der Inbetriebnahme ............................................................... 16

Abbildungsverzeichnis ......................................................................................................... 17

Tabellenverzeichnis ............................................................................................................. 18

[Seite 4]

4 Ausgangslage: Datenbewirtschaftungsprozesse im WIdO

Vorwort

Das Wissenschaftliche Institut der AOK (WIdO), als eine Geschäftsführungseinheit des AOK-Bundesverbandes, bietet fundierte Expertise über alle Leistungsbereiche der ge- setzlichen Krankenversicherung und nimmt vor allem die Patientenversorgung in den Blick. Das WIdO versteht sich als Bindeglied zwischen Wissenschaft und Praxis. Das heißt einerseits, wissenschaftliche Erkenntnisse für die Praxis nutzbar zu machen, und andererseits, Fragen aus der Praxis auf die wissenschaftliche Agenda zu bringen. In beide Richtungen setzt das WIdO seit vielen Jahren wichtige Impulse. Damit das ge- lingt, werten die WIdO-Expertinnen und Experten jedes Jahr viele Millionen Datens- ätze zur Gesundheitsversorgung in Deutschland unter Qualitäts- und Wirtschaftlich- keitsaspekten aus.

Eine wesentliche Grundlage für die Aufgaben des WIdO sind empirische Daten auf Basis der über 28 Millionen AOK Versicherten. Basierend auf diesen Daten bietet das WIdO zahlreiche Produkte für das AOK-System sowie in der öffentlichen Nutzung an. Hierzu zählen Anwendungen und Webseiten aber auch gesetzlich verpflichtende Da- tenlieferungen für das AOK-System. Externe Kooperationen für Politik und Wissen- schaft basieren ebenfalls auf diesen Datengrundlagen.

Das Data Warehouse des WIdO im Forschungsbereich „Integrierte Daten und Analy- sen“ beherbergt in der produktiven IBM Db2 Datenbank derzeit 72 TB komprimierte Daten. Das bisherig eingesetzte Tool wird nicht mehr gewartet, so dass ein neues Tool beschafft werden muss.

Die neue Softwarelösung soll als Standard für alle weiteren Forschungsbereiche des WIdOs sowie weitere Geschäftsbereiche im AOK-Bundesverband eingesetzt werden, so dass sich Anforderungen auch an Verarbeitungsprozesse anderer Datenquellen er- geben.

[Seite 5]

Ausgangslage: Datenbewirtschaftungsprozesse im WIdO 5

1 Ausgangslage:

Datenbewirtschaftungsprozesse im

WIdO

Das Data Warehouse im Forschungsbereich „Integrierte Daten und Analysen“ im WIdO besteht aus mehreren Datenbankschichten, um die Datenhaltung nachvollzieh- bar und die Daten gemäß den Datenschutzvorgaben vorzuhalten. Mit einer Schicht ist ein Datenbankschema gemeint, das themenbezogen zugeordnete Tabellen enthält. Die Datenmenge umfasst aktuell ca. 72 TB und wird regelmäßig aktualisiert und um wei- tere Daten erweitert.

Die Metadatenlogik für den ELT-Prozess ist in Steuerungstabellen der Datenbank hin- terlegt. Über die Metadatentabellen und durch die, für die einzelnen Prozesse, abgeleg- ten SQLs, bleibt der Gesamtprozess hoch transparent. Es werden vorwiegend Steue- rungsflüsse erstellt und damit die volle Performance der Datenbank bei komplexen Da- tenverarbeitungsprozessen genutzt.

In den letzten 10 Jahren wurden zentrale Steuerungsflüsse aufgebaut, die ein schnelles Laden der zahlreichen Daten ermöglicht. Zentraler Gegenstand der ELT-Prozesse sind metadatengetriebene Kontrollflüsse. Das heißt, die Datenverarbeitung selbst findet auf der leistungsstarken Datenbank statt. Daneben gibt es für einige Datenkörper auch Da- tenflüsse, welche SQL-basierten Code erzeugen, um die im Kontrollfluss definierten Aufgaben zu erfüllen.

Zudem ist es möglich Data-Mining-Modelle mittels graphischer Data-Mining-Flows zu erstellen. Hierbei werden Daten aufbereitet, Data-Mining-Modelle erstellt und Visuali- sierungen von Datenmodellen erstellt, welche die Anwendung (oder Bewertung) der Modelle ermöglichen.

Das derzeitige Tool besteht aus

• Einer Entwicklungsumgebung mit einer Anbindung an ein Versionsverwaltungs- system
• Einer Serverkomponente für das Deployment der Flüsse inkl. einer kleinen Meta- daten Datenbank.
• Einer entsprechenden browserbasierten Oberfläche zum Steuern bzw. Ausführen fertiger Prozesse.

In der Entwicklungsumgebung werden ELT-Prozesse von Entwicklerinnen oder Ent- wicklern des WIdO „gebaut“. Diese Prozesse werden dann in einer Serverkomponente deployed und stehen über eine Web-Oberfläche zur Verfügung. Diese kann auch von nicht Entwicklerinnen oder Entwicklern (sogenannte Business User) der Teams im WIdO genutzt werden, um Datenverarbeitungsprozesse zu starten.

[Seite 6]

6 Kurzbeschreibung des Beschaffungsgegenstands und Ziel der Leistungserbringung

2 Kurzbeschreibung des

Beschaffungsgegenstands und Ziel der

Leistungserbringung

Der Auftragnehmer hat dem Auftraggeber ein Datenbewirtschaftungstool zur Verfü- gung zu stellen. Das WIdO hat für verschiedene Projektkontexte vollautomatisierte hochkomplexe ELT-Prozesse etabliert und gepflegt. Es besteht die Notwendigkeit diese Prozesse nun möglichst schnell in eine neue Software zu überführen. Da die bisherigen Prozesse möglichst rasch in ein neues Tool überführt werden müssen, werden die Funk- tionalitäten des bisherigen Tools sowie die Anforderungen der bestehenden Prozesse aufgeführt. Diese sind auch durch die neue vom Auftragnehmer zu liefernde Software- lösung abzudecken.

Zwischenzeitlich sind neue Anforderungen an die Datenverarbeitungsprozesse und an die Qualitätssicherung der Daten, sowie Data-Mining Anforderungen hinzugekom- men, so dass auch diese durch das neue ELT-Tool abzudecken sind.

Wir werden im Folgenden abkürzend den Begriff „ELT“-Tool nutzen, wenngleich hier- bei natürlich auch andere Verarbeitungsschritte bzw. Reihenfolgen mitgemeint sind.

Zur Überwindung der Herausforderungen, die durch die immer größer werdenden Da- tenmengen entstehen, muss ein ELT-Tool zur Datenbewirtschaftung einfach zu benut- zen sein, damit Entwicklerinnen und Entwickler schnell und effektiv Prozesse ändern oder erweitern können.

Neben Entwicklungsumgebungen muss die Software auch eine Serverkomponente enthalten.

Zudem muss das Tool in die bestehende Infrastruktur des AOK-Bundesverbandes in- tegrierbar sein und den Anforderungen an IT-Sicherheit und Datenschutz genügen.

Die Datenverarbeitungsprozesse sind derzeit im Wesentlichen als Kontrollflüsse ange- legt. Das bedeutet, dass über Meta-Tabellen der Datenbank und über entsprechende Parameter der Prozessketten die Datenverarbeitung gesteuert wird. Dabei wird in der Regel durch PUSH-Down die eigentliche Datenverarbeitung auf den Datenbankser- vern durchgeführt. Es gibt aber auch Prozesse, die Datenflüsse in einen Kontrollfluss einbetten.

Eine Ablaufsteuerung bestimmt die Verarbeitungsreihenfolge von Datenflüssen, Data- Mining-Flüssen und anderen Arten allgemeiner Datenverarbeitungstasks (z. B. Aus- führen von Betriebssystemskripten, SQL -Skripten, SFTP und E-Mail). Zudem ist es möglich iterative Schleifen, Bedingungen und Fehlerbehandlungen durchzuführen.

Eine typische Ablaufsteuerung ist zum Beispiel das Holen der Daten vom Filesystem, der Aufruf eines SQL-Skriptes zum Laden in eine Staging-Tabelle sowie die daran an- schließenden Weiterverarbeitungen, bei denen ggf. neue Range Partitions für Tabellen erstellt und SQL- oder Shell-Skripte ausgeführt werden. Die Protokollierung in die Da- tenbank erfolgt direkt über einen entsprechenden SQL-Operator. Datenquellen liegen zum Teil als File vor und werden in der Regel über entsprechende Load-Aufrufe in die Datenbanken geladen. Auch Datenquellen anderer Datenbanksysteme als dem Zielsys- tem sollen verarbeitet werden können.

[Seite 7]

Kurzbeschreibung des Beschaffungsgegenstands und Ziel der Leistungserbringung 7

Zudem werden monatlich Katalogdaten aus dem Internet, die in XML-Format oder an- deren gängigen Daten-Austausch-Formaten vorliegen, aus öffentlichen Quellen herun- tergeladen und verarbeitet. Auch das Verarbeiten von formatierten Excel-Tabellen mit mehreren Tabellenblättern ist eine weitere Anforderung, da Statistikinformationen öf- fentlicher Quellen regelmäßig verarbeitet werden müssen.

Die Bausteine der gesamten Prozesskette werden in der Entwicklungsumgebung visu- alisiert dargestellt. Jeder einzelne Baustein kann separat inhaltlich definiert bzw. aus- gefüllt werden.

Abbildung 1: Exemplarischer Auszug aus einem Prozess

2.1 Anforderungen an die Software

Die Anforderungen des Auftraggebers an die Softwarelösung sind im Detail im An- forderungskatalog (Anhang zur Leistungsbeschreibung, „B3.1_Anforderungskata- log und Bewertungskriterien_*.xlsx“) aufgeführt und mit eindeutigen Identifikatoren gekennzeichnet (Spalte „Anforderungsziffer“).

Die Einzelanforderungen sind in Muss- und Kann-Kriterien unterteilt, die im Anfor- derungskatalog beschrieben sind.

Hier eine Übersicht zu zentralen Anforderungen: Die durch den Auftragnehmer zur Verfügung zu stellende Softwarelösung muss aus einer Entwicklungsumgebung und einer Serverkomponente bestehen.

Die allgemeinen Anforderungen an die Softwarelösung adressieren die intuitive Be- dienbarkeit, zentrale Elemente einer Ablaufsteuerung sowie die Möglichkeit, dass Fachteams gemeinsam an Projekten arbeiten können. Relevant sind weiterhin die Sys- temintegration und der sichere Betrieb der Software.

In der Entwicklungskomponente werden die Datenverarbeitungsprozesse entwickelt und in eine Serverkomponente deployed. Die erstellten Prozesse werden damit auch nicht-Entwicklerinnen und -Entwicklern (Business User) zur Verfügung gestellt, die diese Prozesse über eine Weboberfläche aufrufen können. Dies gilt auch für entwickelte Modelle aus maschinellem Lernen (AUTO-ML) oder sonstigen statistischen Modellen. Im Folgenden eine Liste der zentralen Anforderungen an die Softwarelösung des Auf- tragnehmers:

[Seite 8]

8 Kurzbeschreibung des Beschaffungsgegenstands und Ziel der Leistungserbringung

 Vollständiger On-Premises-Betrieb (Idealerweise VM).  Windows oder SUSE-LINUX  Es können vielfältige Input-Datenformate verarbeitet werden. − Relationale Datenbanken -- Datenbankunabhängigkeit (z. B. PostgreSQL, Oracle, DB2) − Dateibasierte Verarbeitung (CSV, Excel, JSON etc.) − APIs / Webservices stehen zur Verfügung  DSGVO-konformer Betrieb.  Übersichtliches und gut handhabbares, rollenbasiertes Berechtigungskonzept und eine wirksame Zugriffskontrolle sind relevant. (Admin, Developer, Business User).  Single-Sign-On (LDAP, Active Directory, SAML).  Verschlüsselte Kommunikation (TLS/SSL).  Möglichkeit zur Integration in bestehende Netzwerksicherheitsstrukturen (z. B. Firewall-Segmente, SSH-Tunnels).  Updates und Security Patches müssen On-Premises installierbar sein.  Unterstützung kollaborativer Workflows (Team-basierte Projekte), Versionsver- waltung  Vollständig grafische Low-Code-Oberfläche (Drag & Drop) für ELT und Maschi- nelles Lernen. Es steht eine Operatoren-Palette zur Verfügung die per Drag and Dop bei der Entwicklung von Prozessketten genutzt werden können (No-Code- Prinzip).  Push-Down Processing: − SQL-Transformationen sollen nach Möglichkeit direkt in der Datenbank aus- geführt werden. − Unterstützung von Spark-/Hadoop-Flows (falls verfügbar).  Möglichkeit zur Erstellung wiederverwendbarer Komponenten.  Eine Aufgabenplanung wird in der Serverkomponente angeboten (scheduling)  Offene APIs (REST, JDBC/ODBC, Python/R SDKs) zur Integration von Program- mierschnittstellen.  Automated Machine Learning (AutoML) wird ebenfalls angeboten.  Datenqualitätsfunktionen (wie Anomalieerkennung).  Skalierbarkeit und Performance.  Der Auftragnehmer muss Enterprise-Support bereitstellen (DE/EU bevorzugt).  Dokumentation und Schulungsmaterialien müssen verfügbar sein.

On-Premises Lösungen Auf Grund des sehr hohen Schutzbedarfs der zugrundeliegenden Daten sowie der er- forderlichen Kontrolle über den Betrieb der eingesetzten Software durch den Auftrag- geber darf der Auftragnehmer nur On-Premises Lösungen einsetzen.

Die Speicherung und Verarbeitung von Daten auf externen Servern, wie es bei SaaS- Lösungen üblich ist, ist aus rechtlichen und sicherheitstechnischen Gründen nicht zu- lässig. Dies vor allem vor dem Hintergrund, dass mit dem ELT-Tool auch Rohdaten verarbeitet werden. Somit werden teilweise sensible Daten verarbeitet, die den gesetz- lichen Anforderungen des Sozialgesetzbuches unterliegen. Diese Daten mit dem Schutzbedarf „sehr hoch“ können u.a. den Sozialdaten gleichgestellte Betriebs- und

[Seite 9]

Kurzbeschreibung des Beschaffungsgegenstands und Ziel der Leistungserbringung 9

Geschäftsgeheimnisse der Geschäftspartner der AOKs gemäß § 35 Abs. 4 SGB I sein. Daher sind On-Premises-Lösungen zu bevorzugen. Die Software wird als zentrales Da- tenbewirtschaftungstool eingesetzt, welches eng mit internen und betriebskritischen Prozessen verzahnt ist. Dies erfordert eine hohe Verfügbarkeit und unmittelbare Kon- trolle des Auftraggebers über alle Systemkomponenten. Damit verbunden ist unter anderem eine granulare Kontrolle über Updates, Verfügbarkeit und Performance. Dies ist nur bei einer On-Premises-Lösung möglich.

Beständigkeit und Wartung der angebotenen Software In der Entwicklungsperspektive der nächsten 6 Jahre muss nach jetzigem Stand si- chergestellt sein, dass die On-Premises Lösung weiterhin zur Verfügung stehen wird. Dies vor dem Hintergrund, dass die Implementierung von Datenbewirtschaftungspro- zessen mit entsprechenden Aufwänden des Auftraggebers verbunden ist.

Der Auftragnehmer muss stets sicherstellen, dass etwaige Sicherheitslücken der Soft- warelösung schnell gefixt werden und entsprechende Softwarepatches zur Verfügung gestellt werden.

Datenverarbeitung über Kontrollflüsse in den zugrundeliegenden Datenbanksystemen Die über die Software angesteuerte Datenverarbeitung muss primär in den zugrundlie- genden leistungsstarken Datenbanken bzw. Quellsystemen und darf nur teilweise in- nerhalb des Tools erfolgen. Lösungen, bei denen die Verarbeitungen bzw. Transforma- tionen ausschließlich in ihrer eigenen Umgebung durchgeführt werden können, sind ausgeschlossen, da damit weitere Investitionskosten des Auftraggebers in eine geeig- nete Umgebung notwendig wären.

Deployment und Serverkomponente Die entwickelten Flüsse/Prozesse werden auf einen Server deployed und stehen über eine Weboberfläche zur Verfügung. Insgesamt sollte der Deployment Prozess intuitiv sein und mit wenigen „Klicks“ möglich sein. Die deployten Prozesse müssen auf der Serverkomponente übersichtlich und mit einem Kommentarfeld dargestellt werden können. Der Filename des deployten Prozesses kann durch einen entsprechend spre- chenden Namen ersetzt werden.

Anforderungen Maschinelles Lernen und Statistik. Es besteht die Anforderung, Methoden des maschinellen Lernens über AUTO-ML Me- thoden anzuwenden, so dass die Daten mit minimalem Aufwand und minimalen Fach- kenntnissen analysiert werden können. Hierzu muss es möglich sein, dass Trainings- daten vorbereitet werden, entsprechende Modelle trainiert werden und anschließend die Modelle bewertet und ggf. iteriert werden. Die Schlussfolgerungen aus den Model- len sollen dann im Anschluss verglichen werden. Wichtig sind hierbei Klassifizie- rungsmodelle, Regressionsmodelle und Prognosemodelle. Hierbei werden Lösungen, die Datenvisualisierung und AUTO-ML Modelle anbieten, bevorzugt.

Damit verbunden soll auch automatisches Feature Engineering möglich sein. Mit au- tomatischem Feature Engineering können aus den Daten die für die jeweiligen Modelle relevanten Informationen hervorgehoben werden und um irrelevante Merkmale redu- ziert werden. Somit wird insgesamt die jeweilige Modellkomplexität reduziert und die Interpretierbarkeit erhöht. Transparenz und Erklärbarkeit der Modelle sind ebenfalls relevante Features zur Modellinterpretierbarkeit mit Hilfe von Feature Importance oder SHAP (SHapley Additive exPlanations).

[Seite 10]

10 Kurzbeschreibung des Beschaffungsgegenstands und Ziel der Leistungserbringung

Auch spielen Themen zur Analyse von neuen Eingangsdaten eine Rolle. Hierbei geht es im Prinzip um deskriptive statistische Auswertungen. Visualisierungen der Ein- gangsdaten wie zum Beispiel BoxPlots, Histogramme etc., sowie die Darstellung von Ausreißern und Anomalie-Detection sind ebenfalls von Interesse.

2.2 Beispiele als Ergänzung zum Kriterienkatalog

2.2.1 Beispiel zu Deployen Teil 1 Muss-4.1.1:

Der ELT-Prozess selbst heißt zum Beispiel File2Mart_EXPORT_RKI_COVID. Dieser hat als Be- schreibung den Text: „RKI-Daten Export für WI8“. Beim deployen wurde der Name EXPORT_CO- VID_RKI vergeben.

Abbildung 2: Beispiel Prozesse in der Serverkomponente Deployment: Anwendungsname und Kommentar/Bemerkungsfeld

2.2.2 Beispiel zu Protokollierung/Monitoring Teil 1 Muss-4.2.2

Der ELT-Prozess selbst heißt zum Beispiel Storage2MartV1. Beim deployen wurde der Name Storage2MartV1 vergeben. Ein Job der nun Daten verarbeitet wird mit den entsprechenden Parametern gestartet und wurde mit VER_QRT_ALL benannt. Der Job hat einen Status: Grün.

[Seite 11]

Kurzbeschreibung des Beschaffungsgegenstands und Ziel der Leistungserbringung 11

Abbildung 3: Beispiel Steuerungsfluss-Jobs mit Status (grün = ok, rot=Fehler)

2.2.3 Beispiel zu Logging und Monitoring Teil 1 Muss-4.2.1

Im Logging von Prozessen müssen auch Ausgaben aus den aufgerufenen Skripten er- sichtlich sein. So wurde zum Beispiel ein Shell-Skript ausgeführt, welches über ECHO- Befehle bestimmte Ausgaben erzeugt. Diese werden dann auch im Logging ausgewie- sen.

Abbildung 4: Beispiel eines Protokolls bei dem die Inhalte der Jobausführung eines Shell- Skriptes angezeigt werden

[Seite 12]

12 Nutzung der Software:

3 Nutzung der Software:

Die Software wird zum einen von Personen verwendet, welche die Prozesse entwi- ckeln (Entwicklerinnen und Entwickler), Personen, die User/Usergruppen anlegen und selektiv berechtigen, Datenbankverbindungen einrichten und Projekte anlegt usw. (Admins), sowie zum anderen von Personen, die über die Serverkomponente die Prozesse starten (Business User). Business User brauchen über das Starten von Prozes- sen hinaus keine weiteren Rechte zur Entwicklung oder Administration. Die Entwickler-, Admin- und Business User-Lizenzen werden nach Usern (Named oder Concurrent), die Serverlizenzen gerätebasiert gezählt. Die untenstehende Tabelle führt die Anzahl der benötigten Nutzenden auf. Je nach Li- zenzmodell können sich mehrere Personen eine Lizenz teilen. Die Anzahl der Perso- nen die gleichzeitig arbeiten können müssen ist in der Spalte „gleichzeitige Nutzungs- möglichkeit“ angegeben.

Zu Beginn des Vertrages rechnet der Auftraggeber mit folgenden Personen:

Tabelle 1: Anzahl Nutzenden zu Beginn des Vertrages

*sofern abweichend von Entwicklern, sonst inkludiert in Entwickler **sofern zusätzlich zur Serverkomponenten erforderlich © WIdO 2026

Als maximalen Bedarf beziffert der Auftraggeber folgenden Personen:

Tabelle 2: Anzahl Nutzenden maximaler Bedarf

*sofern abweichend von Entwicklern, sonst inkludiert in Entwickler **sofern zusätzlich zur Serverkomponenten erforderlich © WIdO 2026

[Seite 13]

Installations- und Betriebsbedingungen für IT-Systeme im AOK-Bundesverband 13

4 Installations- und Betriebsbedingungen

für IT-Systeme im AOK-Bundesverband

Die IT-Infrastruktur des AOK-Bundesverbandes definiert bestimmte Anforderung hin- sichtlich Integration, Datenschutz, IT-Sicherheit und Wartbarkeit von Softwareproduk- ten. Die folgenden Anforderungen sind durch das vom Auftragnehmer eingesetzte ELT-Tool zwingend zu erfüllen. Diese Kriterien sind auch im Anforderungskatalog (Anhang 1 zur Leistungsbeschreibung) aufgeführt.

Der Auftragnehmer hat im Rahmen des Vergabeverfahrens Mindest-Hard- und Soft- wareanforderungen an die Entwicklungsumgebung sowie Serverumgebung in seinem Angebot zu benennen. Diese müssen sich in die folgenden Rahmenbedingungen des Auftraggebers einfügen:

4.1 Entwicklungsumgebung

− Betriebssystem: Installation der Einwicklungsumgebung ist auf mehreren Termi- nalservern (auf virtuellen Maschinen VMware) unter Windows Server (ab Windows Server 2022) vorgesehen. − Verbindung zum Internet ist nur über einen Proxy mit einer Kerberos Authentifi- zierung möglich. − Den SSL-Zertifikaten von Windows muss vertraut werden. Insbesondere den Root Zertifikaten die im Windows Truststore liegen.

4.2 Serverkomponente

Für die Serverkomponenten kann Linux oder Windows durch den Auftragnehmer ein- gesetzt werden. Je nach Betriebssystem gelten die folgenden Anforderungen:

 Linux: Als Linux Distribution kommt im AOK-Bundesverband nur SUSE Linux Enterprise Server zum Einsatz. Eine entsprechende Kompatibilität ist zu gewähr- leisten. Es wird mindestens SUSE Linux Enterprise Server 15 SP7 erwartet.  Wenn der Server eine dedizierte Webserverkomponente benötigt (wie zum Beispiel Apache, nginx etc.) so müssen diese zwingend aus den Paketquellen der Suse-Dis- tribution installierbar sein.

 Windows: Es wird mindestens Windows – Server 2022 erwartet.

 Softwarebereitstellung über Containerlösung: Im AOK-Bundesverband ist als Containerlösung Docker vorgesehen. Insofern die Software der Serverkomponente in einem Docker Container zur Verfügung gestellt wird, muss die Netzwerkkom- munikation zwischen Containern und Kontrollmöglichkeiten für die zu öffnenden Ports gegeben sein. Die Kommunikation zwischen den Containern muss über lo- kale Firewall, Zertifikate und SSL abgesichert werden können. Auch die Container- software muss regelmäßig (mehrmals pro Jahr) durch den Auftragnehmer auf Si- cherheitslücken geprüft werden. Bei Bedarf hat der Auftragnehmer Patch-Updates

[Seite 14]

14 Installations- und Betriebsbedingungen für IT-Systeme im AOK-Bundesverband

zu veröffentlichen. Es sind auch die Verfahren zur Sicherstellung der Docker Image Security der bereitgestellten Images zu beschreiben.

4.3 Softwareanforderungen

• Falls Java verwendet wird ist folgender Releasestand zu berücksichtigen: Java Runtime, OpenJDK Java 22 JRE oder höher

• Die Kompatibilität der Webbrowser mit Microsoft Edge ab Version 135 muss gegeben sein

• Wird für den Webserver (Applikationsserver) Tomcat verwendet, so wird min- destens Tomcat 9.x oder höher erwartet.

4.4 Anforderungen an IT- und Datensicherheit

Prinzipiell besteht hinsichtlich der Softwarelösung eine hohe Anforderung an die Si- cherheit. Dies bezieht sich sowohl auf die Software selbst als auch auf die Datenbank- zugriffe sowie Zugriffe auf das Filesystem.

Hierzu zählen unter anderem folgende Anforderungen:

Generelle Anforderungen − Passwort-Verschlüsselung (für User, der sich zur Zieldatenbank / zum Zielserver verbindet) muss gegeben sein − Der Auftragnehmer hat den Auftraggeber über eventuell auftretende Sicherheits- lücken im Produkt zu informieren und zeitnah entsprechende Patches zur Verfü- gung zu stellen Hierzu zählen: • Erfassung von Schwachstellen • Bewertung zur Ausnutzbarkeit • Behebung von Schwachstellen und Bereitstellen von Patches durch den Softwareanbieter − Datenbankverbindung erfolgt durch JDBC oder ODBC - Schnittstellen − Die Übertragung und Speicherung der Daten werden nach dem aktuellsten Stand der Technik verschlüsselt.

4.5 Mandantentrennung

Für das Rollen- und Berechtigungskonzept erwarten wir eine Trennung von Berechti- gungen je Forschungsbereich (Mandant). Somit können wir steuern, dass Personen des einen Forschungsbereichs nicht auf Prozesse oder Datenbankverbindungen anderer Forschungsbereiche zugreifen können.

[Seite 15]

Installations- und Betriebsbedingungen für IT-Systeme im AOK-Bundesverband 15

Da das Thema Mandantentrennung von Bedeutung ist, wird zusätzlich je Forschungs- bereich (Mandant) ein entsprechender Administrator festgelegt, der die Berechtigun- gen für das jeweilige Team definieren kann. Diese dürfen selbstredend nicht die Be- rechtigungen untereinander festlegen.

Über ein dediziertes Berechtigungskonzept muss über einen Administrator eingestellt werden können, wer welche Prozesse deployen oder ausführen kann. Das Abkapseln von Prozessen, Projekten und Datenbank-Verbindungen erfolgt nach Nutzendengrup- pen bzw. Mandanten

Siehe auch exemplarisch die untenstehende Abbildung.

Abbildung 5: Grafische Darstellung des Berechtigungskonzepts

Somit muss also gegeben sein, dass Prozesse nur für berechtigte Personengruppen sichtbar sind. So kann zum Beispiel Usergruppe A nicht die Prozesse von Usergruppe B einsehen.

[Seite 16]

16 Unterstützung bei der Inbetriebnahme

5 Unterstützung bei der

Inbetriebnahme

Für die Inbetriebnahme der Softwarelösung benötigt der Auftraggeber im Einstieg Un- terstützung durch den Auftragnehmer. Dies erfolgt in Form von Dienstleisterunterstüt- zung in Zusammenarbeit mit unsere Hauseigenen IT und den durch diese vorgegebe- nen Datenschutzregelungen. Entsprechende Zugänge werden bereitgestellt.

• Aufsetzen der Serverkomponente.

• Einrichten der Software für Entwickler auf VMs

• Einrichten der Lizenzen und sonstige Konfigurationen die zur Inbetriebnahme notwendig sind.

• Einführung zur Wartung und Update-Show-Case.

• Falls sich Software Updates paketieren lassen und damit ein automatisiertes Update der Clients (Entwickler) erfolgen kann, Unterstützung bei der imple- mentieren dieses Szenarios.

[Seite 17]

Abbildungsverzeichnis 17

Abbildungsverzeichnis

Abbildung 1: Exemplarischer Auszug aus einem Prozess ............................................................ 7

Abbildung 2: Beispiel Prozesse in der Serverkomponente Deployment: Anwendungsname und Kommentar/Bemerkungsfeld ............................................................................................. 10

Abbildung 3: Beispiel Steuerungsfluss-Jobs mit Status (grün = ok, rot=Fehler) ........................ 11

Abbildung 4: Beispiel eines Protokolls bei dem die Inhalte der Jobausführung eines Shell- Skriptes angezeigt werden ......................................................................................................... 11

Abbildung 5: Grafische Darstellung des Berechtigungskonzepts .............................................. 15

[Seite 18]

18 Tabellenverzeichnis

Tabellenverzeichnis

Tabelle 1: Anzahl Nutzenden zu Beginn des Vertrages ............................................................. 12

Tabelle 2: Anzahl Nutzenden maximaler Bedarf ....................................................................... 12