Angaben zum Bewerber

V1.03	Digitale Kur Stadt Pyrmont	Beratung erfolgt durch die
	Angaben zum Bewerber	KUHLEMANN Medical IT Valley GmbH
		Am Hoffeld 2
Bereich	Angabe	D-83703 Gmund a. Tegernsee
Firmenname
Firmenanschrift
Firmenwebsite
Produkte/Services
Gesellschafterverhältnisse
Gründungsjahr
Niederlassungen
Anzahl Mitarbeiter total
Anzahl Mitarbeiter Deutschland
Kontaktperson
Telefon
E-Mail

Ausfüllhinweise!

Unnamed: 1	Unnamed: 2	Unnamed: 3	Unnamed: 4

Ausfüllhinweise / Legende	Die Bewerber sind aufgerufen, bei Fragen und Unklarheiten Fragen zu stellen.	grün in diesen Ausfüllhinweisen = den Teilnahmewettbewerb „EK“ betreffend
		Gelb in diesen Ausfüllhinweisen = im Teilnahmewettbewerb noch nicht relevant

Bewertungs- und Ausfüllsystematik (UfAB 2018, fortgeschrieben auf Rechtsstand 01.09.2026)
Eignung (Teilnahmeantrag / Eignungsprüfung). Im Teilnahmewettbewerb sind nur die Reiter „Angaben zum Bewerber“ und „1. EK“ auszufüllen.		Leistungsanforderungen und Zuschlagswertung. Im Teilnahmewettbewerb informativ, um zum Leistungsgegenstand zu informieren.	Die Gewichtungen sind seitens der Klinik vorgegeben und führen zur gewichteten Punktzahl: 0 = im Projekt nicht geplant 1 = Faktor einfaches Gewicht 2 = Faktor mittleres Gewicht 3 = Faktor hohes Gewicht
EK-A = Eignungs-Mindestanforderung. Nichterfüllung führt zum Ausschluss; es gibt keine Punkte.		A = Ausschlusskriterium der angebotenen Leistung. Zwingende Mindestanforderung; nur erfüllt / nicht erfüllt. Keine Gewichtung und keine Bewertungspunkte.
EK-B = Dieses Kriterium wird bewertet wie jeweils im Textfeld angegeben. Nur wenn im Textfeld zusätzlich ein Mindestkriterium angegeben ist, erfolgt bei Nichterfüllung ein Ausschluss.		B = Bewertungskriterium der angebotenen Leistung. Bewertung nach veröffentlichtem Maßstab; Gewichtung ist vorab festzulegen. 0 Punkte bei einem B-Kriterium führen nur dann zum Ausschluss, wenn dies ausdrücklich als Mindestschwelle festgelegt ist.
		Qualifikation und Erfahrung des konkret eingesetzten Personals dürfen als Zuschlagskriterium bewertet werden, wenn sie die Auftragsausführung erheblich beeinflussen (§ 58 Abs. 2 Nr. 2 VgV).
		Aspekte der digitalen Souveränität sind seit 01.07.2026 ausdrücklich als mögliche Zuschlagskriterien in § 58 Abs. 2 Nr. 4 VgV genannt.
Abkürzung		Bedeutung
A		Ausschlusskriterium der Leistung; zwingend, ungewichtet, unbepunktet.	wird im Teilnahmewettbewerb nicht bewertet und daher nicht auszufüllen
B		Bewertungskriterium der Leistung; gewichtet und nach bekannt gegebenem Maßstab bepunktet.	wird im Teilnahmewettbewerb nicht bewertet und daher nicht auszufüllen

1. EK

Unnamed: 0	Unnamed: 1	Die Bewerber / Bieter sind aufgerufen, bei Fragen und Unklarheiten Fragen zu stellen.	Unnamed: 3	Unnamed: 4	Unnamed: 5	Unnamed: 6	Unnamed: 7
	Anforderungen Anbieter					Summe
						0
Ziffer	Anforderung	Erforderliche Nachweise	Kriterium	Priorität / Gewichtung	Bewertung durch die Klinik	Ergebnis	Aussagekräftige Antwort durch Bieter
A.1	Allgemeine Anforderungen an Anbieter
A.1.1	Auszug aus dem Handelsregister (nicht älter als 6 Monate) oder jeweils zuständiges / zutreffendes (nationales) Register	Bestätigung mittels Auszug	EK-A
A.2	Anforderung bzgl. der Personalressourcen
A.2.1	Der Anbieter bestätigt, dass die zum Einsatz gelangenden Personen für die Dauer des geplanten Einsatzes einen aufenthaltsrechtlichen Status haben oder haben werden, welcher diese berechtigt, in Deutschland einer Erwerbstätigkeit im angebotenen Umfang nachzugehen.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.2.2	Der Anbieter bestätigt, dass die für das ausgeschriebene Vorhaben eingeplanten Personen bereit und fähig sind, für die durchzuführenden Arbeiten die deutsche Sprache (mündlich und schriftlich) EU Level B2 zu verwenden und die Ergebnisse in deutscher Sprache abzuliefern. Das Verhandlungsverfahren wird komplett auf Deutsch durchgeführt.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.2.3	Bestätigung, dass Mitarbeiter/innen des Anbieters die jeweils geforderten Arbeitsleistungen unter Einhaltung der deutschen oder mindestens gleichwertigen Arbeitsschutzbestimmungen erbringen werden.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.3	Nachweise, Zertifikate
A.3.2	Ein zeitgemäßes Qualitätsmanagement existiert. Entsprechende Zertifizierungen können nachgewiesen werden. Alternativ: Eigenerklärung möglich. Eigenerklärung = 1 Punkt, Zertifizierung = 2 Punkte	Nachweis oder Eigenerklärung mit Darstellung	EK-B	1		0
A.4	Compliance Anforderungen an Anbieter
A.4.1	Die deutsche Gesetzgebung wird in jedem Fall, insbesondere betreffend dem Datenaustausch, umgesetzt.	Kein Nachweis über das LV hinaus erforderlich	EK-A
A.4.2	Der IT-Dienstleister erklärt sich bereit die Bedingungen des Deutschen Datenschutz’ zu akzeptieren.	Kein Nachweis über das LV hinaus erforderlich	EK-A
A.5	Unternehmens-Eignung
A.5.1	Mindestumsatz > 500.000,- netto im Jahr 2025 oder im ersten Halbjahr 2026	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.5.2	Mindestumsatz mit vergleichbaren Leistungen im Open Source oder Healthcare > 250.000,- € netto im Jahr 2025 oder im ersten Halbjahr 2026	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.5.3	Der Bieter muss nachweisen, dass für Einführung, Schulung, Betrieb und Support qualifiziertes Personal zur Verfügung steht. Angabe der Vollzeitäquivalent-Stellen.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.5.4	Für die Auftragsdurchführung müssen mindestens die Rollen Projektleitung, technische Architektur, Integration/Schnittstellen, Softwareentwicklung, Customizing und Support qualifiziert besetzt werden können.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.5.5	Für die wesentlichen Schlüsselrollen ist eine geeignete Vertretungsregelung sicherzustellen.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.5.6	Der Bieter verfügt über eine Betriebs- bzw. Berufshaftpflichtversicherung mit einer dem Auftragsrisiko angemessenen Mindestdeckung in Höhe des zweifachen Auftragswerts.	Eigenerklärung gem. Vergabeunterlagen-Anlage „Eigenerklärung über eine Berufs- und Betriebshaftplichtversicherung“	EK-A
A.5.7	Der Bieter muss organisatorisch in der Lage sein, die geforderten Support-, Wartungs- und Störungsbearbeitungszeiten während der Vertragslaufzeit sicherzustellen.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.6	Open Source
A.6.1	Der Bieter weist mindestens zwei produktiv gesetzte Referenzprojekte nach, bei denen Open-Source-Software wesentlicher Bestandteil der Lösung war. Pro Referenz über die Minimalforderung hinaus gibt es 1 Punkt, wobei der Referenz Open Source im Healthcare 2 Punkte gibt. Maximalpunktzahl 10 Punkte möglich.	Referenzliste mit Auftraggeber, Leistungsgegenstand, Zeitraum, Produktivstatus. 2 Referenzen sind mindestens nachzuweisen, ansonsten Ausschluss aus dem Verfahren	EK-B	2		0
A.6.2	Der Bieter verfügt in den genannten Referenzen über nachweisbare Erfahrung in Pflege, Weiterentwicklung, Patch- und Release-Management von Open-Source-Komponenten. Pro Referenz gibt es 1 Punkt, wobei der Referenz Open Source im Healthcare 2 Punkte gibt. Maximalpunktzahl 10 Punkte möglich.	Referenzbeschreibung; Projekt-/Release-Nachweise	EK-B	2		0
A.6.3	Der Bieter verfügt über etablierte Verfahren zum Umgang mit Open-Source-Lizenzen, Abhängigkeiten und Third-Party-Komponenten. Darstellung eines Verfahrens: 1 Punkt, Nachweis mindestens einer Referenz unter Nutzung solcher Verfahren: 2 Punkte	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-B	2		0
A.6.4	Der Bieter weist Erfahrung mit offenen, dokumentierten APIs und herstellerunabhängigen Standards in produktiven Projekten nach. Pro Referenz 1 Punkt, max. 5 Punkte	Referenzen mit API-/Standardbezug	EK-B	2		0
A.6.5	Der Bieter weist Erfahrung mit Projekten nach, in denen Betrieb, Daten und technische Dokumentation so gestaltet wurden, dass ein Betreiber- oder Dienstleisterwechsel möglich war. Pro Referenz 1 Punkt, max. 5 Punkte	Referenzbeschreibung	EK-B	2		0
A.7	Healthcare-Kompetenz
A.7.1	Der Bieter weist mindestens zwei produktive Referenzen aus dem Gesundheitswesen oder vergleichbar regulierten Versorgungskontext nach. Pro Referenz über die Minimalforderung hinaus gibt es 1 Punkt, wobei der Referenz Open Source im Healthcare 2 Punkte gibt. Maximalpunktzahl 10 Punkte möglich.	Referenzliste mit Leistungsgegenstand, Zeitraum, Nutzergruppen, Produktivstatus. 2 Referenzen sind mindestens nachzuweisen, ansonsten Ausschluss aus dem Verfahren	EK-B	2		0
A.7.2	Nachweis von Referenzen zur Integration mehrerer klinischer bzw. medizinischer IT-Systeme.	Referenz mit Schnittstellen-/Systembeschreibung	EK-B	2		0
A.7.3	Der Bieter weist praktische Erfahrung mit FHIR nach.	Referenzen; Eigenerklärung zu Standards	EK-B	2		0
A.7.4	Der Bieter verfügt über Erfahrung mit Datenschutz, Nachvollziehbarkeit, Berechtigungsmanagement und regulatorischen Anforderungen in Gesundheits-IT-Projekten.	Referenzen; kurze Darstellung des regulatorischen Projektumfelds	EK-B	2		0
A.7.5	Mindestens eine Referenz weist eine mit dem ausgeschriebenen Vorhaben vergleichbare Nutzer-, Rollen-, Prozess- und Integrationskomplexität auf.	Strukturierte Referenzdarstellung anhand vorgegebener Vergleichsdimensionen	EK-B	2		0
A.8.	Softwareentwicklung
A.8.1	Der Bieter weist mindestens zwei produktiv gesetzte Softwareentwicklungsprojekte vergleichbarer technischer Komplexität nach. Über 2 Projekte hinausgehende Referenzen geben 1 Punkt pro Projekt, maximal 3 Punkte.	Referenzliste mit Architektur, Integrationen, Zeitraum und Produktivstatus. 2 Referenzen sind mindestens nachzuweisen, ansonsten Ausschluss aus dem Verfahren	EK-B	2		0
A.8.2	Der Bieter verfügt über einen etablierten Entwicklungsprozess mit Versionsverwaltung, Code Review, Build-/Deployment-Prozessen und dokumentierter Qualitätssicherung.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.8.3	Der Bieter verfügt über etablierte Verfahren für automatisierte Tests, Integrations-/Regressionstests und Freigaben.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.8.4	Der Bieter verfügt über geregelte Prozesse für sichere Softwareentwicklung, Schwachstellenbehandlung, Dependency-Management und Security-Patches.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.8.5	Der Bieter weist Erfahrung mit Entwicklung und Betrieb dokumentierter APIs sowie Authentifizierungs-/Autorisierungsverfahren nach.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A
A.8.6	Der Bieter verfügt über etablierte Verfahren für Releases, Fehlerkorrekturen, Security-Fixes, Versionswechsel und Lifecycle-Management.	Eigenerklärung als Antworttext in Spalte H oder als frei erstellte Anlage	EK-A

2. Konzepte und Personal

Unnamed: 0	Die Bewerber / Bieter sind aufgerufen, bei Fragen und Unklarheiten Fragen zu stellen.	Unnamed: 2	Unnamed: 3	Unnamed: 4

Konzepte

Anforderung	Erforderliche Nachweise	Kriterium	Ausführliche Darstellung als Anlagen!	Bewertung durch Auftraggeber
Allgemeine Anforderungen an Anbieter
Liefern Sie ein Realisierungskonzept für das ausgeschriebene Projekt	Konzept als Anlage benennen und liefern	B
Liefern Sie ein Lösungs- und Betriebskonzept inkl. Backup für das ausgeschriebene Projekt	Konzept als Anlage benennen und liefern	B
Liefern Sie einen Zeitplan für das ausgeschriebene Projekt. Angenommener Start: 1.3.2027, Betriebsbereitschaft spätestens 1.10.2027	Zeitplan als Anlage benennen und liefern	B
Liefern Sie ein Schulungskonzept für das ausgeschriebene Projekt	Konzept als Anlage benennen und liefern	B
Anforderung bzgl. der Personalressourcen
Der Bieter weist nach, dass die für die Projektumsetzung gestellten Personen eine ausgewiesene technische Expertise für Healthcare nachweisen	CVs und Qualifikationen mit Relevanz für das Vorhaben liefern. Die vorhandene Qualifikationen für das Projekt werden bewertet.	B

			Die Umsetzung der eingereichten Konzepte (Anlagen zum LV) ist in den angebotenen Dienstleistungen enthalten.

3. Erfüllung Rechtsgrundlagen

Erfüllung (Rechts-)grundlagen	Unnamed: 1	Die Bewerber / Bieter sind aufgerufen, bei Fragen und Unklarheiten Fragen zu stellen.	Unnamed: 3	Unnamed: 4	Summe	Unnamed: 6
					0
Maßnahme / Leistungsanforderung	Rechtgrundlage	Kriterium	Priorität / Gewichtung	Bewertung durch Auftraggeber	gewichtete Punktzahl	Aussagekräftige Antwort durch Bewerber


Ambulante Vorsorgeleistung	§23 Absatz 2 SGB V	A
Versorgung mit Heilmitteln	als Selbstzahler / privat	B	3		0
Maßnahmen der Primärprävention	§ 20 SGB V	A
GeDIG / gematik	GeDIG und SGB V, Regelungen zur elektronischen Patientenakte (ePA), Vorschriften zur Telematikinfrastruktur, Interoperabilitätsvorgaben, Datennutzungs- und EHDS-Umsetzungsregelungen (European Health Data Space)	B	3		0
Telemedizin	https://www.kbv.de/praxis/digitalisierung/anwendungen/videosprechstunde?utm\_source=chatgpt.com	A

SC.1 Open Source

Die Bewerber / Bieter sind aufgerufen, bei Fragen und Unklarheiten Fragen zu stellen.	Unnamed: 1	Unnamed: 2	Unnamed: 3	Unnamed: 4	Summe	Unnamed: 6
					0
Open Source	Kriterium	Kriterium	Gewichtung	Bewertung durch Auftraggeber	gewichtete Punktzahl	Aussagekräftige Antwort durch Bewerber
Mit Fördermitteln (mit-)finanzierte Softwarelösungen sind als Open Source/freie Software bereitzustellen und zu veröffentlichen.	Bieter kennzeichnet alle geförderten Softwarebestandteile und bestätigt Open-Source-Veröffentlichung.	A
Open-Source-Gebot sowie interoperable Lösungen und standardisierte Schnittstellen sind als Pflichtanforderung an Umsetzungspartner/Auftragnehmer weiterzugeben.	Vertrag/Unterauftragnehmerregelungen enthalten entsprechende Verpflichtungen.	A
Finaler Quellcode ist spätestens zur Bereitstellung an den Auftraggeber zur Veröffentlichung auf OpenCoDE.de zu übergeben/einzustellen.	Repository/Export vollständig, Build reproduzierbar, Veröffentlichungsvorbereitung nachgewiesen.	A
Es ist eine auf OpenCoDE.de im Bereich Lizenz-Compliance zulässige Lizenz zu verwenden; Auswahl in Abstimmung mit Auftraggeber, sofern nicht vorgegeben.	LICENSE-Datei und Lizenzprüfung; alle Eigenentwicklungen eindeutig lizenziert.	A
Lizenzkompatibilität aller verwendeten Open-Source-Komponenten ist sicherzustellen; Copyleft-Auswirkungen sind transparent darzustellen.	SBOM/Lizenzliste mit Kompatibilitätsbewertung und Konfliktfreiheit.	A
Quellcode muss frei zugänglich, lesbar/verständlich, kopier-, nutz-, veränder- und weiterverbreitbar im Rahmen der gewählten OSS-Lizenz sein.	Lizenz und Repository erlauben diese Nutzungen ohne zusätzliche proprietäre Restriktionen.	A
Software ist nachvollziehbar zu dokumentieren; finaler offener Quellcode muss durch Dritte verstanden, angewendet und modifiziert werden können.	README, Installations-, Betriebs-, Architektur-, Entwickler- und Nutzerdokumentation vorhanden.	A
Ein ausführbares Softwareprodukt bzw. ausführbares abgeschlossenes Teilprodukt muss reproduzierbar aus dem veröffentlichten Quellcode erzeugbar sein.	Clean-build aus Repository anhand Dokumentation erfolgreich.	A
Vendor-Lock-in-Effekte und Abhängigkeiten von Einzeltechnologien/Unternehmen sind zu vermeiden.	Exit-/Portabilitätskonzept, offene Formate/APIs, keine technisch unnötigen proprietären Bindungen.	A
Interoperable Lösungen und standardisierte/offene Schnittstellen sind zu entwickeln und zu nutzen.	API-Dokumentation, Standards, Datenformate und Referenzimplementierung offengelegt.	A
Schnittstellen zu proprietären Systemen können eingesetzt werden; geförderte Entwicklung der Schnittstelle muss grundsätzlich als Open Source veröffentlicht werden können.	Adapter-/Schnittstellencode separat identifizierbar und OSS-veröffentlichbar; proprietäre Abhängigkeit begründet.	A
Bei Geräten mit proprietärer Gerätesoftware müssen digitale Geräteschnittstellen offen und standardkonform sein, sofern Standards existieren; höherwertige Vernetzungs-/Steuerungssoftware ist Open Source.	Geräte-API-Standard dokumentiert; Plattform-/Integrationssoftware im OSS-Repository.	A
Nicht geförderte Software ist grundsätzlich nicht vom Open-Source-Gebot betroffen; Abgrenzung muss transparent sein.	Kosten-/Architekturabgrenzung gefördert vs. nicht gefördert nachvollziehbar.	A
Proprietäre Komponenten dürfen die Förderfähigkeit der geförderten Open-Source-Entwicklung nicht unterlaufen; Notwendigkeit und Abgrenzung sind zu begründen.	Komponentenliste mit Förderbezug, Lizenzart, Begründung und Exit-Option.	A
Repository soll übliche Einstiegspunkte und Metadaten enthalten, insbesondere README und Lizenzinformationen; weiterführende Doku darf extern verlinkt werden.	Repository-Review gegen Dokumentationscheckliste.	A
Eingesetzte OSS-Komponenten müssen regelmäßig aktualisiert und auf Sicherheitslücken/Bugs beobachtet werden, besonders im Gesundheitskontext.	Vulnerability-/Dependency-Management, Patch-SLAs, Verantwortlichkeiten und Nachweise.	A
Urheber-, Patent- und Lizenzrechte Dritter sind zu prüfen; Verantwortlichkeiten und Freistellungs-/Haftungsregelungen sind vertraglich zu klären.	OSS-Compliance-Prozess, SBOM, Scan-Berichte und vertragliche Zusicherungen.	A
Verantwortlichkeit für Veröffentlichung, Pflege, bekannte Mängel und Entwicklungsstand ist zwischen AG und AN eindeutig festzulegen.	RACI/Vertragsklausel und Release-Prozess vorhanden.	A
Lösung muss auf Übertragbarkeit, Skalierbarkeit und Nachnutzung durch andere Kommunen ausgelegt sein.	Deployment-/Konfigurationskonzept ohne Bad-Pyrmont-Hardcoding; Nachnutzungsleitfaden.	A

SC2.1 Use Case Information

Die Bewerber / Bieter sind aufgerufen, bei Fragen und Unklarheiten Fragen zu stellen.	Unnamed: 1	Unnamed: 2	Unnamed: 3	Unnamed: 4	Summe	Unnamed: 6
					0
Beispiel-Prozess	Anforderungen	Kriterium	Gewichtung	Bewertung durch Auftraggeber	gewichtete Punktzahl	Aussagekräftige Antwort durch Bewerber
	Die angestrebte Plattformlösung soll moderne Kommunikationsmöglichkeiten mitbringen, die es ermöglichen, eine hohe Anzahl von Anfragen und Nachfragen zu bearbeiten.	B	2		0
	Über die Plattformlösung soll es die Möglichkeit geben, die Beantragung mit einem in der Beantragung und der Maßnahme selbst erfahrenen Mediziner durchzuführen.	B	3		0
	Die Plattformlösung wird den Versicherten die Möglichkeit bieten, ihre individuellen Vorstellungen, Wünsche und Bedürfnisse im Rahmen einer digitalen Anfrage mit einzubringen.	B	3		0
	Unterlagen und Formulare können vorab auf direktem Weg zur Verfügung gestellt werden.	B	3		0
	Die Plattformlösung soll die Möglichkeit der telemedizinischen Konsultation bieten. Der Patient kann dann sein Aufnahmegespräch mit dem Badearzt optional bereits vorab von zu Hause aus durchführen, und gewinnt wertvolle Therapiezeit. Evtl. oder zusätzlich Chatfunktion mit Praxen	B	3		0
	Evaluation: Die Plattform soll dem Patienten eine geeignete Möglichkeit bieten, die Gesamtmaßnahme sowie die einzelnen Maßnahmenmodule in verschiedenen Qualitätsdimensionen differenziert zu bewerten. Der Fragenkatalog soll dabei die Strukturqualität, die Prozessqualität und die Ergebnisqualität abbilden. Die Bewertung soll dem Kurort in strukturierter Form mit modifizierbaren Berichten zur Verfügung stehen, und der kontinuierlichen Weiterentwicklung der Plattform dienlich sein.	A
	Um die angestrebten Ziele zu erreichen, soll die digitale Plattform den Versicherten umfassende Informationen zu den ambulanten Vorsorgeleistungen zur Verfügung stellen. Zudem soll die Möglichkeit bestehen, den Kurantrag im Rahmen einer telemedizinischen Beratung mit einem hierfür geschulten Arzt auszufüllen und bei der Krankenversicherung einzureichen, die Behandlung von zu Hause aus zu planen und das Aufnahmegespräch mit dem Kurarzt ebenfalls im Vorfeld der eigentlichen Vorsorgemaßnahme digital durchzuführen. Umsetzung Antragsformular	B	3		0
	Die Plattform soll einen durchgängigen Service bieten, der von der Begleitung bei der Antragsstellung, über die Begleitung des Aufenthaltes, Integration von digitalen Therapieangeboten am Heimatort bis hin zur Nachsorge nach der Behandlung reicht.	B	3		0
	Ziel ist es, eine Plattform zu entwickeln und zu implementieren, die zusätzliche digitale Therapieformen unterstützt, die bereits in der stationären Rehabilitation erfolgreich eingesetzt werden, und die für die Integration von Drittprodukten wie telemetrischen Gesundheitsüberwachungsgeräten und digitalen Trainingstherapiemodulen ausgelegt ist, um die therapeutischen Ergebnisse in den Alltag der Patientinnen und Patienten nachhaltig zu überführen. (Caspar Health etc...)	B	3		0
	Dazu gehört die Installation der erforderlichen Software, die vollständige Systemkonfiguration, die Einrichtung von Schnittstellen zu externen Systemen sowie der dauerhafte Betrieb der Plattform	B	3		0
Prüfung der Erfolgsaussichten der Antragstellung	Eine Pre-Screening-Funktion soll es dem Antragsteller ermöglichen, bei Einreichung seiner relevanten Daten und Dokumente vorab die Eignung und Wahrscheinlichkeit der Genehmigung seines Antrags durch die gesetzliche Krankenkasse prüfen zu können. Sollten Zweifel an der Eignung für die Beantragung einer ambulanten Vorsorgemaßnahme bestehen, oder relevante Voraussetzungen nicht erfüllt sein, sollten Vorschläge zur Optimierung der der Zugangsvoraussetzungen unterbreitet werden. Vorstellbar ist hierzu auch der Einsatz von KI.	B	3		0
Einreichung von Kuranträgen	Patienten welche den Pre-Screening-Prozess erfolgreich absolviert haben, können telemedizinische Konsultationen mit einem vom Kurort autorisierten und qualifizierten niedergelassenen Arzt planen. Die erforderlichen Antragsformulare sollten hierfür digital bereitgestellt und versendet werden können.	B	3		0
Buchung eines telemedizinischen Aufnahmegesprächs beim behandelnden Badearzt	Nach erfolgreicher Genehmigung der Maßnahme durch die Krankenkasse soll sich der Patient vorab einen Termin für ein ärztliches Aufnahmegespräch buchen können. Optional soll hierfür die Möglichkeit eines telemedizinischen Aufnahmegesprächs im Vorfeld der Maßnahme bereits am Heimatort geschaffen werden. Entsprechende Planungsmöglichkeiten der Ressourcen der autorisierten Ärzte als auch Kommunikationsmöglichkeiten zwischen Patient und Arzt, als auch das eigentliche Buchungssystem für die Termine sind zu berücksichtigen.	B	3		0
Buchung von Anwendungen und Terminen beim Staatsbad	Patienten können Ihren genehmigten Kurantrag beim Kurort/Staatsbad Pyrmont zur Bearbeitung einreichen. Zur gezielten Vorbereitung der Vorsorgemaßnahme sind Kommunikationsmöglichkeiten zwischen Patient und Kurort vorzusehen. Vorgaben und Wünsche für die Erstellung des Behandlungsplans sowie die Reservierung oder Buchung weiterer ergänzender Dienstleistungen sind zu berücksichtigen. Der Patient sollte den Status seines Behandlungsplans jeder Zeit nachverfolgen können.	B	3		0
Evaluation der ambulanten Vorsorgemaßnahme	Die Plattform soll dem Patienten eine geeignete Möglichkeit bieten, die Gesamtmaßnahme in verschiedenen Qualitätsdimensionen differenziert zu bewerten. Die Bewertung soll dem Kurort in strukturierter Form mit modifizierbaren Berichten zur Verfügung stehen.	B	3		0
Telemetrische Gesundheitsmessungen	In Ergänzung zu den medizinisch-therapeutischen Bestandteilen der ambulanten Vorsorgemaßnahme können Patienten vom Kurort autorisierte mobile Geräte verwenden, um Gesundheitsdaten, wie z.B. Telemetrie-Messwerte der Herzfrequenz direkt in die Plattform hochzuladen. Die Daten sollen gut auswertbar dem Badearzt und dem Therapieteam zur Verfügung stehen. Diese Funktion soll dem medizinisch-therapeutischen Team die Möglichkeit geben, den Gesundheitszustand des Patienten noch besser einschätzen und den Therapieprozess noch besser führen zu können.	B	2		0
Integration von digitalen therapeutischen Modulen	Die Standarddauer der ambulanten Vorsorgeleistung beträgt 21 Tage. Insbesondere für berufstätige Patienten soll die Maßnahme flexibler gestaltet werden. Eine optionale Teilung der Maßnahme wird ebenso angestrebt, wie die Implementierung von digitalen Therapiemodulen. Diese digitalen Therapiemodule werden bereits erfolgreich in Therapiekonzepten zur Prävention und Nachsorge für die Deutsche Rentenversicherung umgesetzt. Die Plattform soll die flexible Gestaltung der Aufenthaltsdauer im Kurort und die optionale Implementierung digitaler Therapiemodule berücksichtigen. Dies kann in Form eines selbst entwickelten Moduls für digitale Angebote geschehen, in Form einer Einbindung bereits am Markt etablierter Anbieter geschehen. Wesentliche Inhalte sind hier visuell angeleitete therapeutische Übungsprogramme, Online-Vorträge- und Seminare sowie ein Feedback- und Kommunikationsangebot für die Nutzer.	B	2		0
Buchung von Unterkünften und lokalen Dienstleistungen	Patienten können über die Plattform lokale Unterkünfte und weitere Dienstleistungen aus dem touristischen Angebot des Kurortes buchen. Z.B. Feratel Schnittstelle	B	2		0

SC3 Digitale Kur

Die Bewerber / Bieter sind aufgerufen, bei Fragen und Unklarheiten Fragen zu stellen.	Unnamed: 1	Unnamed: 2	Unnamed: 3	Unnamed: 4	Summe	Unnamed: 6
					0
Patientenadministration	Anforderungen SOLL	Kriterium	Gewichtung	Bewertung durch Auftraggeber	gewichtete Punktzahl	Aussagekräftige Antwort durch Bewerber
	Die Plattform muss es dem angeschlossenen Kurort ermöglichen, alle Datenbankinhalte bereitzustellen und zu verwalten, einschließlich der Anforderungen der gesetzlichen Krankenkassen, der Anbieter von DTTM und digitalen Anwendungen sowie dem Anbieter des aktuell vom Staatsbad genutzten KIS-Systems	A
	Die Plattform soll es dem angeschlossenen Kurort ermöglichen, die örtlichen Unterkunftsoptionen abzufragen, zu buchen und zu stornieren.	B	2		0
	Die Plattform muss den Auftraggeber in die Lage versetzen, die Regeln für Patienten und Dienstleister flexibel anzupassen. Dazu gehört die Möglichkeit, Verwaltungsregeln für die Verwaltung von Interaktionen mit Dienstleistern und Patienten festzulegen. Das System muss die Anpassung aller Patienten-Workflows in jeder Interaktionsphase unterstützen, von der Registrierung und Antragseinreichung bis zum Abschluss der Behandlung sowie aller Interaktionen mit Dienstleistern in diesen Phasen.	B	2		0
Customer Relationship Management (CRM)-System	Spezifikation Teil der Verhandlung: Ein CRM-System ermöglicht es dem Kurort, Patientenanfragen- und Kommunikation über Telefon, E-Mail, und geeignete Messenger-Dienste zu verwalten. Dieses System zentralisiert die Patientendaten und die Kommunikationshistorie, um eine einfache und lückenlose Verwaltung zu gewährleisten.	B	2		0
Telemedizinische Konsultation	Autorisierte Ärzte können telemedizinische Konsultationen durchführen und in geeigneter Form dokumentieren. Die Plattform unterstützt Echtzeit-Video- und Chat-Konsultationen, sowie eine Aufzeichnungs- und Speicherfunktion. Die Hardware ist nicht Teil der Beschaffung.	B	3		0
Datenaustausch mit dem KIS-System des Kurortes	Die Plattform muss den Datenaustausch mit dem KIS-System des Kurortes in geeigneter Form gewährleisten. Aktuell nutzt der Kurort CGM-Reha mit den Modulen GPM und GTP der CompuGroup Medical. Es kann sein, dass ein KIS-Wechsel 2027 durchgeführt wird. Moderne Schnittstellen wie FHIR sowie Anbindungs-Option openEHR, CDR sind zu berücksichtigen	A
Serviceplanung und Terminmanagement	Der Kurort wird in die Lage versetzt, Behandlungspläne zu verwalten, medizinische Dienstleistungen und Termine zu buchen und diese mit einem integrierten Kalendersystem zu synchronisieren. Die Plattform ermöglicht eine flexible Planung in Echtzeit sowohl für das Personal als auch für die Patienten. Die Planungssoftware des Kurortes ist aktuell GTP der CompuGroup Medical. Es kann sein, dass ein KIS-Wechsel 2027 durchgeführt wird. Moderne Schnittstellen wie FHIR sowie Anbindungs-Option openEHR, CDR sind zu berücksichtigen	B	2		0
Qualitätskontrolle und Leistungsanalyse	Die Plattform enthält Werkzeuge zur strukturierten Überwachung und Bewertung der Qualität und Kosten des Behandlungsprozesses. Datenanalyse-Dashboards bieten geeignete Auswertungen zur Behandlungsleistung, der Patientenzufriedenheit und der Servicequalität. Im Sinne der weiteren Entwicklung und Optimierung enthält die Plattform ein geeignetes Befragungstool zur Bewertung der Benutzerfreundlichkeit und Funktionalität. Ziel ist es, durch strukturierte und regelmäßige Auswertung des Nutzerfeedbacks die Benutzeroberfläche und die abgebildeten Prozesse an den Bedürfnissen der Patienten weiterzuentwickeln.	B	2		0
Telemetrische Gesundheitsdaten / Devices	Die Plattform ermöglicht es, von Patienten autorisierte telemetrisch erfasste Gesundheitsdaten, wie z.B. die Herzfrequenz und andere Vitaldaten, darzustellen und auszuwerten. Dies soll dem medizinisch-therapeutischenTeam dabei helfen, den Therapieprozess noch individueller und zielgerichteter zu steuern	B	2		0
Entwicklung und Betrieb der Plattform	Die Plattform ist vom Anbieter zu entwickeln und bereitzustellen. Wenn neue Datenanbieter oder Nutzergruppen hinzukommen, können neue Anforderungen entstehen, die eine technische Weiterentwicklung und Implementierung nötig machen. Die Entwicklungsphasen sollen im Konzept detailliert herausgearbeitet und dargestellt werden. Eine Modulare Architektur wird als vorteilhaft angesehen. Um die Plattform an die genannten Drittsysteme anzuschließen und den erforderlichen Datenverkehr gewährleisten zu können, bietet die Plattform geeignete Schnittstellen, welche im Konzept beschrieben werden sollen. Entsprechende Referenzen sind nach Möglichkeit zu nennen.	B	2		0
Patientendaten	In diesem Abschnitt werden die wesentlichen Informationen für das Patientenprofil aufgeführt, die zur Verwaltung der Patientendaten, einschließlich persönlicher Daten und Gesundheitsdaten, verwendet werden. Die Angaben sind nach Ermessen des Kurortes aufgeführt und beanspruchen, insbesondere im Sinne der Funktionalität der Plattform, keine Vollständigkeit. 8.1. Grundlegende Informationen • Patienten-ID • Fall-Nr. • Vorname • Nachname • Geburtsdatum • Geschlecht • Nationalität • Sprachpräferenz 8.2. Kontaktinformationen • E-Mail • Telefonnummer • Adresse • Stadt • Bundesland/Region • Land • Postleitzahl • Unterkunft während der Maßnahme, Kostenträger, Maßnahmeart 8.3. Gesundheitsinformationen • Krankengeschichte • Allergien und Unverträglichkeiten • Aktuelle Medikamente • Chronische Erkrankungen • Behandelnder Arzt am Heimatort • Behandelnder Badearzt während der Maßnahme 8.4. Informationen zur Krankenversicherung • versichert bei welcher Krankenversicherung • Versicherungs-Nr. • Genehmigungszeitraum für die Maßnahme	A
	Die _x0000_d_x0000_i_x0000_g_x0000_i_x0000_t_x0000_a_x0000_l_x0000_e_x0000_ _x0000_s_x0000_k_x0000_a_x0000_l_x0000_i_x0000_e_x0000_r_x0000_b_x0000_a_x0000_r_x0000_e_x0000_ _x0000_P_x0000_l_x0000_a_x0000_t_x0000_t_x0000_f_x0000_o_x0000_r_x0000_m_x0000_ _x0000_f_x0000_ür_x0000_ _x0000_d_x0000_e_x0000_n_x0000_ _x0000_K_x0000_u_x0000_r_x0000_o_x0000_r_x0000_t_x0000_ _x0000_B_x0000_a_x0000_d_x0000_ _x0000_P_x0000_y_x0000_r_x0000_m_x0000_o_x0000_n_x0000_t_x0000_ _x0000_stellt einen m_x0000_i_x0000_t_x0000_ _x0000_b_x0000_a_x0000_r_x0000_r_x0000_i_x0000_e_x0000_r_x0000_e_x0000_a_x0000_r_x0000_m_x0000_e_x0000_m_x0000_ _x0000_Z_x0000_u_x0000_g_x0000_a_x0000_n_x0000_g_x0000_ _x0000_f_x0000_ür_x0000_ _x0000_a_x0000_l_x0000_l_x0000_e_x0000_ _x0000_A_x0000_k_x0000_t_x0000_e_x0000_u_x0000_r_x0000_e_x0000_ _x0000_sicher	B	3		0

SC4 med. Daten, Architektur und

Die Bewerber / Bieter sind aufgerufen, bei Fragen und Unklarheiten Fragen zu stellen.	Unnamed: 1	Unnamed: 2	Unnamed: 3	Summe	Unnamed: 5
				0
Gesundheitsdaten / Unabhängigkeit von Daten und Anwendungen / zukunftssichere Architektur / KI	Kriterium	Gewichtung	Bewertung durch Auftraggeber	gewichtete Punktzahl	Aussagekräftige Antwort durch Bewerber
Wie binden Sie eine openEHR-Architektur / CDR ein? OpenEHR / CDR selbst als Plattform ist nicht Teil dieses Vorhabens, sondern ein komplementäres Projekt (separate Vergabe)	B	3		0
Wie gestalten Sie die technische Basis, um mit Gesundheitsdaten KI-gestützt zu arbeiten und die Einbindung unterschiedlicher Lösungen zu fördern?	B	3		0
Wie können Sie heute oder in Zukunft die „Trennung von Daten und Anwendungen“ realisieren (openEHR, CDR etc.)?	B	3		0
Wie arbeiten Sie mit der Klinischen Dokumentenklassenliste (KDL)?	B	3		0
Einbindung von Systemen für multimedialer Gesundheitsdaten (Röntgenbilder, MRT, EKG,…)	B	2		0
Nutzung von Patienten-Devices, Digital Health Daten (Smartwatches etc.)	B	3		0
Integration externer KI-Module/Services über standardisierte Schnittstellen (z. B. API, FHIR/HL7)	B	1		0
Arztbrief/Entlassungsbericht (Vorlagen, Bausteine, Versionierung, Signatur). Erstellung aus Daten; Version/Signatur; Export als PDF/A	B	3		0
KI-gestützte Anwendungen von Drittanbietern wie Apple einbinden: Intelligente Empfehlungen von Health Apps integrieren. Beispiele: Natives Food-Tracking: Eine der am meisten erwarteten Funktionen: Nutzer können Mahlzeiten direkt protokollieren, um Kalorien und Nährstoffe zu erfassen. Gesundheits-Chatbot: Ein KI-Assistent soll künftig Fragen zu Gesundheitsthemen beantworten können. Trainingsanalyse per Kamera: Die iPhone-Kamera könnte genutzt werden, um die Haltung bei Übungen zu analysieren und in Echtzeit Korrekturtipps zu geben	B	2		0
Einbindung von Therapie-Applikationen wie CASPAR Health	B	3		0
Einbindung Veranstaltungskalender und optional Einbindung/Schnittstelle zum Buchungsportal der Bad Pyrmont Tourismus ( feratel). Automatisierung von Hinweisen zu Veranstaltungskalendern durch Einbindung der Systeme etc.	B	2		0
Einbindung selbst entwickelter und zu entwickelnder Applikationen	B	3		0
Der Bieter / Bewerber bietet eine Anbindung des CGM Reha KIS an. Klarstellung: Das CGM Reha (GTP und GPM) läuft in den beiden Kliniken und den beiden Ambulanzen. Es ist eine Migration zu einem alternativen KIS in 2027 möglich, welches dann anzubinden wäre.	A			0
Der Bieter / Bewerber bestätigt die Verwendung von FHIR zum interoperablen Datenaustausch mit Informationssystemen	A			0

SC5 Technologie IT

Anforderungen System-Lösung	Unnamed: 1	Unnamed: 2	Unnamed: 3	Unnamed: 4	Die Bewerber / Bieter sind aufgerufen, bei Fragen und Unklarheiten Fragen zu stellen.
Anforderungen Technologie IT				Summe
				0
Anforderung	Kriterium	Gewichtung	Bewertung durch Auftraggeber	gewichtete Punktzahl	Aussagekräftige Antwort durch Bewerber
Client
Der Client ist vollständig als Web Client / Web App oder als Native Apps auf mobilen Geräten wie Smartphones und Tablets (Android, iOS) verfügbar.	A
Alle Teile der Lösung, auch ggf. integrierte Produkte, laufen läuft als Web-Applikation, im Browser oder es gibt eine verbindliche Roadmap, in der die vollständige Web-Technologie für alle Applikationen bis 2027 geliefert wird.	A
Parametrierbarkeit
Funktionen an der Software können durch Parametrierung individuell konfiguriert werden, ohne dass Programmierungen vorgenommen werden müssen.	B	3		0
Parametrisierungen können selbstständig durch 'Administratoren' (dedizierte Rolle, die definiert und vergeben wird) der Auftraggeber ausgeführt werden.	B	2		0
Reibungslose Zusammenarbeit zwischen Auftraggeberl IT und IT-Dienstleister ist sichergestellt.	B	2		0
Beschreibung wie Parametrierungen nach Best Practice deployed werden.	B	2		0
Protokollierung
Protokollierung bei Veränderungen oder Neuerfassung von Stammdaten ist möglich. – Zugriffe – Definierte Benutzeraktionen	B	3		0
Protokollierung der betroffenen Inhalte, die verändert wurden (alt - neu, Zeitstempel etc.) ist möglich.	B	3		0
Schnittstellen zu externen Partnern
Externe Dienste können angebunden oder integriert werden. (Bsp. Mobile Payment)	B	2		0
Datenintegrität
Die Übertragungswege sind verschlüsselt.	A
Wenn personenbezogene und vertrauliche Daten übermittelt werden, wird zur Übertragung von solchen Informationen ein Verschlüsselungsalgorithmus verwendet, welcher dem aktuellen Stand der Technik entspricht	A
Zur Übertragung von Informationen mit hohem Integritätsanspruch, wie z.B. personenbezogenen Daten, wird ein Verfahren zum Schutz gegen zufällige oder vorsätzliche Veränderungen eingesetzt. Dieses entspricht dem aktuellen Stand der Technik.	A
Interoperabilität
Offen dokumentierte Schnittstellen + Fehlerhandling (Retry/Queues/Monitoring). API-/Interface-Doku; Monitoring-Ansicht; Fehlerroutinen	A
FHIR R4 API (Patient, Encounter, Observation, DocumentReference etc.). FHIR CapabilityStatement; Auth-Mechanismus; Test-Endpoints	A
HL7 v2 (ADT/ORU/ORM/MDM) für Legacy-Integrationen. Nachweis unterstützter Message Types; MLLP/Integration Engine	A


Netzwerk
Redundantes Netzwerk WiFi – Anforderungen an Performance sind seitens des Bieters aus Erfahrungen darzustellen. WiFi selbst ist nicht anzubieten.	A
Offline-Fähigkeit der Anwendungen bei vorübergehenden Störungen / Ausfall WiFi / Internet	B	3		0
Weitere Anforderungen an Anbieter
Das Hosting findet auf einer zertifizierten Cloud Lösung (C5) statt. Welcher Cloud-Anbieter seitens des Auftraggebers ggf. separat bereitgestellt wird, ist Gegenstand des Verhandlungsverfahrens.	B	3		0
Die Daten in der Cloud werden unter Beachtung der in Deutschland / Niedersachsen gültigen und anzuwendenden gesetzlichen Regelungen (StGB, DSGVO, BDSG, Landesregelungen) und Rahmenbedingungen gehostet.	B	3		0
Der IT-Dienstleister / -Anbieter stellt sicher, dass gesetzliche Anforderungen in Zukunft (z.B. GeDIG, gematik,…) fristgerecht erfüllt sind, sofern es die eigenen Produkte, Eigenschaften und Zertifizierungen betrifft. Ansonsten werden Produkte fristgerecht eingebunden, um diese Verpflichtungen zu erfüllen.	A
In der angestrebten Lösung sind international Sprachen umschaltbar (z.B. KI-basiert): Englisch, Niederländisch, Russisch, Ukrainisch, Arabisch,…	A
Der Bieter / Bewerber bietet eine Integration von Archivsystemen. Darstellung / Eigenerklärung = 1 Punkt, Referenz = 2 Punkte	B	3		0

Parameter und Beratung

Unnamed: 1	Unnamed: 2	Beratung der Klinik
0.0	0	KUHLEMANN Medical IT Valley GmbH
1.0	1	Am Hoffeld 2
	2	D-83703 Gmund a. Tegernsee
	3

2026-09-22_Anforderungskatalog_Stadt Pyrmont V1.03.xlsx

Angaben zum Bewerber

Ausfüllhinweise!

1. EK

2. Konzepte und Personal

3. Erfüllung Rechtsgrundlagen

SC.1 Open Source

SC2.1 Use Case Information

SC3 Digitale Kur

SC4 med. Daten, Architektur und

SC5 Technologie IT

Parameter und Beratung