Das gematik-Hospitationsnetzwerk sichtbar machen.
Der Versorgungs-Kompass ist ein Tool für das gematik-Hospitationsnetzwerk. Er bündelt Informationen so, dass aus einzelnen Kontakten ein gemeinsames Bild entsteht: Wer gehört zu unserem Netzwerk? Wo sind Einrichtungen, Praxen, Kliniken, Apotheken und Pflegeeinrichtungen verortet? Welche Regionen sind bereits gut sichtbar und wo fehlen uns noch Perspektiven?
Im Mittelpunkt steht die Karte. Sie soll schnell erfassbar machen, wie unser Netzwerk verteilt ist. Sie zeigt weiße Flecken, regionale Schwerpunkte und mögliche Nachbarschaften zwischen Akteuren. Damit bietet sie einen ersten Überblick: Wie können Hospitationen sinnvoll gebündelt werden? Welche Versorgungsbereiche sind in einer Region vertreten? Welche Kontakte liegen nahe beieinander und könnten gemeinsam gedacht werden?
Das Modul Hospitationen ermöglicht Terminplanung und Dokumentation - mit dem Ziel, die Erkenntnisse aus dem Versorgungsalltag strukturiert zur weiteren Nutzung aufzubereiten.
- Version: v0.16.0
- Stand: 27. Juni 2026
- Kurznotiz: Erstes GitHub Release, harmonisiert mit dem App-Changelog bis Version 0.16.
Kurz erklärt:
- Die Anwendung ist für die interne Arbeit am gematik-Hospitationsnetzwerk gedacht.
- Die Karte ist der wichtigste Einstieg und zeigt, wo Kontakte und Organisationen zu finden sind.
- Für die Nutzung gibt es drei Wege: die Demo mit Testdaten für Vorführungen, das Live System als laufendes System und die Deployment-Dokumentation für Betrieb und Migration.
| Ordner | Zweck |
|---|---|
frontend/ |
Oberfläche, Login, Karten, Datenadapter, Zusatzseiten und fiktive Demo |
api/ |
REST-API für produktionsnahe Backend-Zugriffe im Zielbild |
supabase/ |
Legacy- und Migrationsquelle bis zur abgeschlossenen Datenmigration |
public/ |
Logos, Icons und statische Assets |
scripts/ |
Prüf-, Sync- und Importskripte |
tests/ |
Browser-Smoke-Tests |
docs/ |
Publish-Kopie für das Live System, nicht direkt pflegen |
dokumentation/ |
Einstieg, Design, QA, Architektur, Betrieb und Deployment |
Wichtige Einstiege in die Dokumentation sind dokumentation/README.md, dokumentation/architektur/ und dokumentation/betrieb-und-deployment/.
Im Repository liegen Oberfläche, technische Adapter, Dokumentation und fiktive Demo-Daten. Produktive Daten werden im geschützten Backend geführt. So bleibt der gemeinsame Datenstand zentral, nachvollziehbar und getrennt vom öffentlichen Quellcode.
Administrative Schlüssel und andere sensible Betriebszugriffe werden im Zielbetrieb über das geschützte Secret-Management der jeweiligen Umgebung bereitgestellt.
Weitere Details:
dokumentation/architektur/API_CONTRACT.md: API-Grenzen und Sicherheitsmodell.dokumentation/architektur/DATA_MODEL.md: fachliches Datenmodell.supabase/README.md: Legacy-Backend und Quelle für die Datenmigration.
Die drei Wege unterscheiden sich vor allem bei Zielgruppe, Datenstand und technischer Umgebung. Die Tabelle ordnet sie ein, danach folgen die konkreten Hinweise.
| Variante | Wofür gedacht | Umgebung und Hinweis |
|---|---|---|
| Demo | Öffentliche Vorführung mit Testdaten | GCP Cloud Run mit eigenem Cloud-SQL-Backend |
| Live System | Laufendes Tool im bestehenden Setup | GitHub Pages liefert das Frontend, Supabase liefert Daten und Funktionen |
| Zielbetrieb | Übernahme in die gematik-Infrastruktur | Kubernetes mit Jenkins, Helm, API, Datenbank und Secrets |
Die Demo ist der öffentliche Vorführstand mit Testdaten. Sie läuft auf Google Cloud Run und nutzt ein eigenes Cloud-SQL-Backend.
Sie ist der passende Link für Vorführung, Abstimmung und erste fachliche Rückmeldungen, wenn kein Zugriff auf das Repository oder das Live System besteht.
Die Demo enthält keine produktiven Daten und kann vom aktuellen Arbeitsstand des Live Systems abweichen.
Das Live System ist das aktuell nutzbare Tool im bestehenden Setup. GitHub Pages liefert das Frontend aus dem Ordner docs/ aus. Die Anwendung arbeitet mit der angebundenen Supabase-Konfiguration und ist dadurch mehr als eine statische Oberfläche.
Das Live System kann mit Anmeldung, Berechtigungen und Backend-Daten arbeiten, soweit die aktuelle Konfiguration dies zulässt. Es ist damit der wichtigste laufende Stand vor dem Zielbetrieb.
Änderungen an der Oberfläche werden aus den Quellordnern nach docs/ synchronisiert und danach über GitHub Pages sichtbar gemacht. Änderungen an Daten, Rechten oder Backend-Struktur müssen zusätzlich in der angebundenen Backend-Umgebung berücksichtigt werden.
Im Zielbetrieb wird der Versorgungs-Kompass in der gematik-Infrastruktur betrieben. Dafür sind im Repository bereits konkrete Build- und Deployment-Bausteine vorhanden. Es kann also direkt mit Jenkins-Build, Kubernetes-Deployment, Helm-Konfiguration, Frontend-Konfiguration, API-Anbindung, Datenbank-Anbindung, Secret-Handling und Preflight-Checks weitergearbeitet werden.
Der einfache Ablauf ist:
- Jenkins-Build starten.
- Helm-Chart und Kubernetes-Konfiguration anpassen.
- Frontend-Konfiguration für die Zielumgebung vorbereiten.
- API und Datenbank anbinden.
- Secrets und Umgebungskonfiguration setzen.
- Anmeldung, Navigation, Karte und Backend-Zugriffe testen.
Die wichtigsten Startpunkte für die Implementierung sind:
- Build:
dokumentation/betrieb-und-deployment/artefakte/Jenkinsfile.gematik - Helm-Chart:
Chart.yamlundvalues.yaml - Kubernetes-Templates:
deployment.yaml,service.yaml,ingress.yamlundconfigmap.yaml - Frontend-Konfiguration:
scripts/prepare_target_frontend_config.mjs - Preflight-Check:
scripts/preflight_target_deployment.mjs - Betriebsunterlagen:
DEPLOYMENT_GEMATIK_K8S.md,DEPLOYMENT_CHECKLIST.md,BETRIEB.mdundDEPLOYMENT_UEBERSICHT.md
Die aktuelle Einordnung der Auslieferungswege steht in der Deployment-Übersicht.
Das Repository enthält automatisierte Prüfungen. Sie helfen dabei, einfache Fehler früh zu finden und Änderungen verlässlich zu überprüfen. Die schnellen Prüfungen achten auf Syntax, fehlende Dateien und offensichtliche Formatprobleme. Die technischen Checks prüfen zum Beispiel öffentliche Assets, API-Regeln, wichtige Datenfelder und die Backend-Anbindung. Die Browser-Tests öffnen die Oberfläche wie ein Nutzer und prüfen typische Wege, etwa Navigation, Kartenaufruf, Tabellen, Detailansichten und mobile Ansichten.
Die detaillierten QA-Regeln stehen in dokumentation/entwicklung-und-qa/QA_WORKFLOW.md.
Quellcode und technische Dokumentation stehen unter der Apache License 2.0.
Fiktive Demo- und Beispieldaten dürfen für Entwicklung, Tests und Demonstrationen genutzt werden, sofern in einer Datei nichts anderes angegeben ist. Echte Daten aus angebundenen Systemen, Marken, Logos, Profilbilder, Drittinhalte und andere externe Assets sind nicht Teil dieser Repository-Lizenz. Weitere Hinweise stehen in NOTICE und DATA_NOTICE.md.