V.connect Fremdaufruf — Übersicht
V.connect Fremdaufruf ermöglicht es einem KIS, ein vorausgefülltes V.ap-Produktformular (DUBA, ELIM+, …) im Browser des Arbeitsplatzes zu öffnen — auch dann, wenn das KIS selbst den HTTPS-POST-Aufruf, den V.ap normalerweise erwartet, nicht ausführen kann. Die Komponente läuft neben dem KIS auf dem Arbeitsplatz, nimmt die GET-URL entgegen, die das KIS erzeugen kann, und überbrückt die Lücke zu V.aps POST-basierter Sitzungsinitialisierung.
Dieses Dokument ist die kundenorientierte Übersicht: wofür die Komponente da ist, was sie leistet und was ihre Einführung umfasst. Für die tiefergehende Architektur und Designentscheidungen siehe Architecture (englischsprachig). Für den Arbeitsablauf des KIS-Integrators beim Erzeugen von URL-Vorlagen siehe den V.ap Fremdaufruf URL-Builder.
1. Zweck
V.ap-Produktmodule stellen POST-Endpunkte bereit, die strukturierte JSON-Daten (Patientenidentifikation, Berichtsdaten, Justizmeldungs-Referenzen, …) entgegennehmen und mit einem einmaligen Login-Link auf ein vorausgefülltes Formular antworten. KIS-Systeme, die HTTPS-POST-Aufrufe ausführen können, integrieren sich direkt mit diesen Endpunkten.
Viele KIS-Konfigurationen können das nicht. Die Integrationsschnittstelle, die sie bereitstellen, kennt nur ein einziges Primitiv: "Öffne diese URL mit den angehängten Parametern". Der naheliegende Umweg — denselben Inhalt per GET auf einem V.ap-Endpunkt entgegen zu nehmen — scheitert aus Datenschutzgründen: URLs hinterlassen Spuren in Browser-Verläufen, in Proxy-Protokollen, in Server-Zugriffs-Logs und im Referer-Header jedes nachfolgend angeklickten Links.
Fremdaufruf schließt diese Lücke auf der Arbeitsplatzseite. Die Komponente läuft lokal, nimmt die vom KIS erzeugte GET-URL entgegen, übersetzt sie in den von V.ap erwarteten authentifizierten POST-Aufruf und leitet den Browser per 303-Redirect auf den resultierenden Login-Link weiter. Die V.ap-Module selbst bleiben unverändert; nur die lokale Komponente kommt hinzu.
2. Auf einen Blick
Was die Komponente dem Kunden bietet:
- Ein einzelnes, schlankes Binary auf jedem KIS-Arbeitsplatz oder ein Container im Krankenhausnetz — als Windows-Dienst oder Linux-Container betrieben. Einstellige MB Arbeitsspeicher, keine Laufzeit-Abhängigkeiten.
- Kompatibilität mit KIS-Systemen, die nur die einfache "Externe URL öffnen"-Funktion bieten — keine KIS-seitige Entwicklung erforderlich.
- Endnutzer-Erlebnis bleibt erhalten: das vorausgefüllte Formular erscheint im eingebetteten Browser des KIS, kein Fenster-Wechsel, keine separate Anmeldung.
- Modul-unabhängig: eine Komponente, alle V.ap-Module. Ein zusätzliches Modul in die Integration aufzunehmen ist eine Konfigurationsänderung, keine neue Bereitstellung.
3. Integrationsfreiheit
Das Integrations-Primitiv, auf dem Fremdaufruf aufsetzt — eine externe URL mit angehängten Parametern öffnen — ist eine der am weitesten verbreiteten KIS-Fähigkeiten. Praktisch jedes Klinik-Informationssystem unterstützt sie; sie ist älter als jede anbieterspezifische Integrations-API. Dadurch hängen Integrationen mit V.ap-Modulen nicht davon ab, dass der KIS-Anbieter modul-spezifische Unterstützung bereitstellt, eigene Adapter baut oder kostenpflichtige Integrations-Stufen freischaltet. Das Krankenhaus entscheidet, welche Module integriert werden; der KIS-Anbieter steuert diese Entscheidung weder, noch stellt er sie in Rechnung.
4. Bereitstellungsvarianten
V1 unterstützt zwei Varianten aus demselben Binary, unterschieden durch die Konfiguration:
Pro Arbeitsplatz, Loopback-gebunden. Jeder KIS-Arbeitsplatz
betreibt eine eigene Instanz, gebunden an 127.0.0.1. Betrieblich
einfach — ein Arbeitsplatz, eine Installation. Vertrauensgrenze:
das Betriebssystem des Arbeitsplatzes. Bereitgestellt als
signierter Windows-Installer, der einen nativen Windows-Dienst
registriert.
Zentral im Krankenhausnetz. Eine einzige Installation im
Krankenhausnetz, an eine routbare Adresse gebunden, bedient mehrere
KIS-Arbeitsplätze. Vertrauensgrenze: ein konfiguriertes Access
Secret, das jeder Aufrufer in jeder Anfrage mitliefern muss.
Bereitgestellt als Container-Image unter
ghcr.io/mcp-health/v.connect/fremdaufruf (linux/amd64), mit einer
Docker-Compose-Beispieldatei als Ausgangspunkt.
Beide Varianten nutzen dasselbe Binary, dasselbe Konfigurations-Schema und denselben Upstream-Vertrag mit V.ap. Die Wahl ist eine betriebliche Entscheidung, keine Produkt-Entscheidung.
5. Einführung
5.1 Voraussetzungen
| Punkt | Anforderung |
|---|---|
| Plattform | Windows 10 oder neuer (x64) für Arbeitsplatz-Bereitstellungen; Linux x86-64 über Container (Docker / Podman) für zentrale Bereitstellungen. macOS ausschließlich für Entwicklung. |
| Ausgehendes Netzwerk | HTTPS-Erreichbarkeit vom Arbeitsplatz (oder LAN-Host) zur V.ap-Basis-URL. |
| V.ap-API-Benutzer | Bereitgestellt durch Ihren Vertama-Kontakt, mit den Modul-Berechtigungen, die die Integration erfordert. |
| Dienst-Installationsrechte | Administrator (Windows) bzw. root (Linux) für die Dienst-Registrierung. Der reguläre Betrieb läuft unprivilegiert. |
| Festplatte | Weniger als 50 MB für das Binary, die Konfiguration und das Audit-Log. |
Die Komponente ist ein einzelnes, statisches Binary ohne Laufzeit-Abhängigkeiten — kein JRE, keine .NET-Runtime, keine gemeinsam genutzten Bibliotheken über das Betriebssystem hinaus.
5.2 Installationswege
- Windows. Signierter Installer registriert den Windows-Dienst,
legt das Binary in
%PROGRAMFILES%ab und schreibt eine Konfigurations-Vorlage. Authenticode-Signatur ist vor der Installation überprüfbar. - Linux / Container. Container-Image mit einer Docker-Compose-Beispieldatei als Ausgangspunkt. Konfiguration per Umgebungsvariablen (12-Faktor) oder per eingebundener Konfigurationsdatei.
- macOS. Nur Entwicklung.
5.3 Im laufenden Betrieb
Nach der Installation läuft die Komponente als langlaufender Dienst
und stellt ein browserbasiertes Admin-Dashboard unter
http://127.0.0.1:8811/admin auf dem Host bereit. Der Administrator
legt den Admin-Zugangscode fest, passt die Konfiguration an die
V.ap-Instanz an, lädt die Konfiguration aus dem Dashboard neu und
bestätigt, dass der V.ap-Konnektivitätstest erfolgreich ist. Die
Installation ist in wenigen Minuten abgeschlossen; der erste
erfolgreiche KIS-Aufruf erfolgt in der Regel am selben Tag, sobald
die Konfiguration steht.
Der tägliche Betrieb läuft ohne aktive Begleitung. Das Dashboard zeigt aktuelle Aktivitäts-Zähler, die effektive Konfiguration (mit redigierten Geheimnissen) und die jüngsten Aufrufe.
Das vollständige Betriebshandbuch — Installationsablauf, vollständiges Konfigurations-Schema, Fehlersuche, Audit-Log-Details — wird mit dem Binary ausgeliefert als Betriebshandbuch und ist über das Admin-Dashboard erreichbar. Vertama stellt es auf Anfrage bereits vor der Bereitstellung für die IT-Sicherheits-Prüfung zur Verfügung.
6. Sicherheit & Compliance — Zusammenfassung
Betreiber-Souveränität. Nach der Installation läuft die Fremdaufruf-Komponente vollständig unter Ihrer Kontrolle. Vertama betreibt keine Fernwartungs-Oberfläche, keinen Phone-Home-Kanal, keinen eingehenden Zugang in Ihre Bereitstellung. Die gesamte Konfiguration ist lokal. Das Netzwerk-Verhalten der Komponente entspricht genau dem, was Sie konfigurieren: ausgehend ausschließlich zur konfigurierten V.ap-Basis-URL (die Komponente greift nicht in Ihr Intranet hinein, selbst wenn Ihr Netzwerk dies zulassen würde), und eingehend nur an der von Ihnen gewählten Bind-Adresse und dem Port.
Was Vertama bereitstellt und wo es läuft:
| Artefakt | Läuft wo | Kontrolliert von |
|---|---|---|
| Fremdaufruf-Komponente (Windows-Dienst) | KIS-Arbeitsplatz | Krankenhaus-Administrator |
| Fremdaufruf-Komponente (Linux-Container) | Im Krankenhaus betriebener Host | Krankenhaus-Administrator |
| V.ap-Produktmodule + URL-Builder | Vertama-Cloud | Vertama betreibt; Krankenhaus-Administrator richtet API-Benutzer ein und nutzt diese |
Drei unabhängige Steuerungen regeln, was über Fremdaufruf möglich ist:
- V.ap-seitige Autorisierung (primär) — der Geltungsbereich des konfigurierten API-Benutzers bei V.ap bestimmt, welche V.ap-Aktionen überhaupt erreichbar sind.
- Lokale Pfad-Allowlist (zusätzliche Absicherung) — Krankenhaus-Administratoren können die Oberfläche auf eine Liste zulässiger Upstream-Pfade einschränken.
- Access Secret (Vertrauensgrenze im Intranet) — erforderlich
für nicht-Loopback-Bereitstellungen; jede Anfrage muss den
passenden
_s-Parameter mitliefern.
Auf der Übertragungsebene: HTTPS ausschließlich zur konfigurierten V.ap-Basis-URL; TLS-Verifizierung gegen den System-Trust-Store; Parameter-Werte und -Schlüssel werden auf keiner Log-Stufe protokolliert (ausschließlich deren Anzahl); Anmeldedaten und Access Secrets werden niemals protokolliert.
Für die vollständige Sicherheitsbetrachtung — Autorisationsmodell, Wire-Level-Garantien je Bereitstellungsvariante, Vertrauensgrenzen, Audit-Log-Garantien — siehe Architecture §8 (englischsprachig).
7. Support
Vertama unterstützt Fremdaufruf direkt. Das Team dahinter ist klein, was bedeutet: wenn Sie uns erreichen, erreichen Sie das Engineering, keine Ticket-Warteschlange. Reaktion erfolgt zügig bei installations-blockierenden Problemen; funktionale Verbesserungen fließen in die reguläre Release-Kadenz ein.
8. In V1 enthalten — und was nicht
In V1 enthalten:
- Beide Bereitstellungs-Varianten (pro Arbeitsplatz Loopback, zentral im Krankenhausnetz).
- Signierter Windows-Installer und Linux-Container-Distribution.
- Browserbasiertes Admin-Dashboard für Status, Konfigurations- Neuladen und V.ap-Konnektivitäts-Test.
- TOML-Konfiguration mit Umgebungsvariablen-Überschreibungen.
- Stderr- und Datei-Audit-Log-Ziele.
- URL-Vorlagen-Werkzeug bei V.ap für die vom Kunden gewählten Module (DUBA, ELIM+ und weitere V.ap-Module nutzen denselben URL-Vorlagen-Workflow ohne zusätzliche Komponenten-Kosten).
Was bewusst nicht im aktuellen Umfang ist, mit Begründung, siehe Architecture §9 (englischsprachig).
Begleitdokumente:
- Architecture — vollständige Design-Begründung, Bereitstellungs-Details, Sicherheits-Posture, Umfang und Roadmap (englisch).
- V.ap Fremdaufruf URL-Builder — KIS-Integrator-Anleitung zum Erzeugen von URL-Vorlagen.
- Betriebshandbuch — Betriebsanleitung; wird mit dem Binary ausgeliefert und ist nach der Installation über das Admin-Dashboard erreichbar.
Stand: 11.06.2026 Gilt für: V.connect Fremdaufruf V1