XPipe liegt in Version 22.0 vor. Das Update bringt vor allem eine flexiblere Authentifizierung, eine ausgebaute Integration von Passwordmanagern und Verbesserungen bei Containern. Im Zentrum stehen Multi-Identitäten und die direkte Nutzung von SSH-Agenten aus gängigen Passwort-Tools.

Das Open-Core-Projekt richtet sich an Administratoren, DevOps-Teams und alle Nutzer, die viele Remote-Verbindungen und Shells einsetzen. Es dient als zentrale Oberfläche zum Starten und Verwalten von SSH-, Container-, VM- und weiteren Infrastruktur-Verbindungen.

Nutzer können jetzt mehrere Identitäten pro Zielsystem hinterlegen und zwischen ihnen wechseln. In Team-Vaults wählt XPipe automatisch eine verfügbare lokale Identität, wenn referenzierte Identitäten für den aktuellen Anwender nicht verfügbar sind. Statt mehrere Verbindungen für denselben Host anzulegen, können unterschiedliche Nutzer oder Rollen innerhalb einer Verbindung koexistieren.

Passwordmanager mit SSH-Agent-Support

XPipe unterstützt nun die SSH-Agenten von 1Password, Bitwarden, KeePassXC, Keeper und Proton Pass direkt. Laufende Agenten erkennt das Tool automatisch – eine manuelle Socket-Konfiguration entfällt. Zugangsdaten und SSH-Keys bezieht es gemeinsam aus dem Passwordmanager, was lokale Key-Dateien überflüssig machen kann. Schlüssel lassen sich im Agent-Feld auch über ihren Namen referenzieren, sofern der eingesetzte Passwortmanager das unterstützt. Darüber hinaus unterstützt XPipe jetzt mehrere 1Password-Konten gleichzeitig, zusätzliche Paketierungsformen von Bitwarden, KeePassXC und Keeper sowie nun auch Proton Pass; außerdem kann XPipe Secrets aus HashiCorp Vault abrufen.

Für Incus und LXD erkennt XPipe nun Container über alle Projekte, also getrennte Verwaltungsbereiche ähnlich Namensräumen, hinweg. Wenn ein Container eine IP-Adresse meldet, kann XPipe diese zum direkten Öffnen von Diensten nutzen, etwa für RDP- oder VNC-Verbindungen.

Für Podman verbessert Version 22.0 den Umgang mit Quadlets, also systemd-basierten Containerdefinitionen. XPipe erkennt zugehörige Unit-Files und erlaubt deren Bearbeitung. Ein Neustart greift korrekt auf den systemd-Service durch, statt nur den Container isoliert neu zu starten.

Erweiterte Suche und Schnellzugriff

Die Suchleiste nimmt jetzt direkte Befehle entgegen. Wer etwa ssh user@host eingibt, startet sofort die passende Verbindung oder landet in einem Quick-Connect-Dialog. Die Filterung soll zudem spürbar schneller bei großen Verbindungslisten reagieren.

Kategorien lassen sich jetzt mit eigenen Icons versehen. Theme-Wechsel laufen flüssiger, und der neue Shortcut Strg+T öffnet das Terminal-Dock, das in der Vorgängerversion eingeführt wurde. Hinzu kommen zahlreiche Bugfixes, unter anderem bei SSH-Aliasen, gemischten Shell-Umgebungen und auf Windows-Systemen. Alle Informationen zu XPipe 22.0 finden sich in den Release Notes.

(fo)

Die interaktive Unix-Shell fish kann ab Version 4.6.0 Prompt-Informationen direkt aus Umgebungsvariablen übernehmen, stellt Emoji im Terminal breiter dar und akzeptiert mit |& eine aus Bash vertraute Pipe-Schreibweise. fish richtet sich an Administratoren und Entwickler, die eine interaktive Shell mit gut lesbarer Syntax und vielen Komfortfunktionen bevorzugen. Anders als Bash oder Zsh priorisiert fish dies gegenüber strikter POSIX-Konformität.

Prompt- und Sitzungsintegration

fish wertet ab sofort drei neue Umgebungsvariablen aus: SHELL_PROMPT_PREFIX, SHELL_PROMPT_SUFFIX und SHELL_WELCOME. Präfix und Suffix erscheinen automatisch vor und nach dem linken Prompt, die Welcome-Variable blendet beim Start eine zusätzliche Meldung ein. Damit lassen sich zum Beispiel privilegierte oder speziell gestartete Sitzungen klar kennzeichnen, ohne eigene Prompt-Logik schreiben zu müssen. Die Entwickler nennen systemd run0 als typischen Anwendungsfall.

Ferner behandelt fish Emoji jetzt standardmäßig als zwei Zellen breit statt bisher eine. Das korrigiert eine häufige Fehlerquelle bei der Terminaldarstellung, wobei die Shell seit kurzem UTF-8 als Standard voraussetzt: Stimmt die angenommene Zeichenbreite nicht mit der tatsächlichen Darstellung überein, verrutschen Prompts, Einrückungen und tabellarische Ausgaben. Die Umstellung hilft vor allem Nutzern, die von modernen Desktops auf ältere Systeme zugreifen. Gegen Fehlausrichtungen auf älteren Terminals hilft es, fish_emoji_width auf 1 zurückzusetzen.

Bash-kompatible Pipe-Syntax

fish akzeptiert ab Version 4.6.0 |& als alternative Schreibweise zu &|. Beide leiten Standardausgabe und Standardfehler gemeinsam in eine Pipe. Ein typisches Beispiel: make |& less schickt Build-Ausgaben und Fehlermeldungen zusammen in den Pager. Die Ergänzung verringert Stolperfallen für Nutzer, die regelmäßig zwischen Bash und fish wechseln.

set_color schaltet Stilattribute wie Kursiv, Unterstreichung, Reverse und Durchstreichen jetzt gezielt ab – etwa mit --italics=off. Neu sind außerdem die Optionen --foreground und --reset. Sie erleichtern Theme-Autoren und Prompt-Frameworks die präzise Steuerung von Terminalattributen.

Fixes und kleinere Verbesserungen

Signale wie SIGWINCH, die das System etwa beim Ändern der Fenstergröße sendet, unterbrechen Builtin-Ausgaben nicht mehr. Einen Absturz beim Suspendieren bestimmter Pipelines per Ctrl-Z haben die Entwickler ebenfalls behoben. Unter macOS beseitigt das Release einen Fehler, den langsame Terminalantworten beim Start auslösten.

Version 4.6.0 korrigiert zudem mehrere Fehler aus den Releases 4.3 bis 4.5: ein Zwischenartefakt beim Neuzeichnen des Prompts, die ignorierte Option --color= bei history, Probleme im Vi-Modus bei dl und dh sowie fehlerhafte Completion bei Befehlen, die mit - beginnen.

Der Completion-Pager richtet Beschreibungen jetzt linksbündig aus. fish_indent bewahrt nun Kommentare und Leerzeilen direkt vor einem Brace-Block. Für Entwickler und Distributoren: cargo xtask-Subkommandos brechen bei Testfehlern nicht mehr mit einem Panic ab. Die Maintainer weisen in den Release Notes darauf hin, dass Nutzer den Quellcode über fish-4.6.0.tar.xz beziehen sollen – das generische tar.gz-Archiv von GitHub lasse sich nicht korrekt bauen.

(fo)

Krankenhausinformationssysteme wie Epic von Epic Systems bieten zwar eine schnelle Integration, standardisierte Prozesse und eine solide Grundlage für KI. Gleichzeitig schaffen sie Abhängigkeiten und begrenzen Flexibilität. Über Krankenhaussoftware wie Epic wurde jüngst auf dem Digital Health Innovation Forum des Hasso-Plattner-Instituts diskutiert.

Jorge Juan Fernández, Chief Innovation Officer am Hospital Clínic de Barcelona, stellte Epic in seinem Vortrag „The European Third Way: Examples and lessons in re-engineering our healthcare systems through European innovation to drive shared prosperity“ in den Kontext unterschiedlicher globaler Modelle und bezeichnete die Plattform als „monolithic stack“, der vieles ermögliche, aber nicht alles erlaube. Zugleich verwies er darauf, dass Epic längst in vielen großen Gesundheitssystemen im Einsatz sei, insbesondere in den USA, und zunehmend auch in Europa eingeführt werde oder geplant sei.

Epic wird zur Milliardenfrage

Als Beispiel für diesen Trend gilt auch Deutschland. Wie das Fachmedium kma berichtet, darf die Berliner Charité nach einer Gesetzesänderung bis 2035 Kredite in Höhe von bis zu 400 Millionen Euro aufnehmen, um unter anderem den Einsatz von Epic zu finanzieren, dessen Einführung alleine mit rund 200 Millionen veranschlagt wird. Bislang setzte die Charité auf SAP, das seinen Rückzug aus dem KIS-Markt angekündigt hatte.

Fernández stellte dem ein alternatives Modell gegenüber: Offene Plattformen auf Basis von Standards wie openEHR, einem offenen internationalen Standard für elektronische Patientenakten (Electronic Health Record, EHR), der eine standardisierte Speicherung, Verwaltung und den Austausch von Gesundheitsdaten ermöglicht. Diese Ansätze böten mehr Flexibilität und Interoperabilität, erforderten jedoch auch deutlich höheren Koordinationsaufwand. Fernández geht davon aus, dass sich diese beiden Modelle in den kommenden Jahren auseinanderentwickeln werden.

Im Rahmen seines „European Third Way“ plädierte er dafür, dass Europa einen eigenständigen Ansatz zwischen dem US-Modell – geprägt von finanzgetriebener, technologiezentrierter Krankenhausversorgung – und dem chinesischen Modell, das stark auf Skalierung und industrielle Effizienz setze, entwickeln müsse. Europa solle dabei stärker auf Prävention, Primärversorgung sowie die Integration von Gesundheits- und Sozialdaten setzen.

Epic und KI

Chenzhe Cao, Principal Technology Strategist bei Mass General Brigham, beschrieb Epic in seinem Vortrag „Operationalizing Intelligence: A Systems Approach to AI Enablement for an Integrated Academic Health System“ als zentrale Infrastruktur seines Klinikverbunds. Ohne strukturierte Dokumentation keine Abrechnung, ohne Daten keine Prozesse. Gerade diese Integration ermögliche es, KI-Anwendungen in großem Maßstab in den klinischen Alltag zu bringen.

Im Kontext von KI sei das ein entscheidender Vorteil, weil Daten in großer Menge und konsistenter Struktur vorliegen. Gleichzeitig verwies Cao auf den wirtschaftlichen Druck im US-System: Viele Kliniken bewegen sich nahe an der Rentabilitätsgrenze oder darunter, ähnlich ist es auch in Deutschland. KI muss Cao zufolge jetzt in die Versorgung integriert werden, um die wirtschaftlichen und personellen Probleme der Gesundheitssysteme überhaupt bewältigen zu können. Entscheidend sei dabei nicht nur die Technologie, sondern deren Einbettung in klinische Prozesse, klare Governance-Strukturen und die Einbindung des Personals. KI solle die Arbeit von Ärzten und Pflegekräften unterstützen, nicht ersetzen.

Wie unterschiedlich die Ausgangslagen in Europa sind, wurde am Beispiel deutscher Klinikbetreiber deutlich. Vertreter großer Krankenhausgruppen beschrieben historisch gewachsene IT-Landschaften mit mehreren parallelen Kernsystemen und hunderten bis tausenden Subsystemen. Diese seien oft nur selten interoperabel. Statt eines radikalen Systemwechsels setzen viele Häuser daher auf eine zusätzliche Datenebene – eine Art „Clinical Data Layer“, die Informationen aus verschiedenen Quellen zusammenführt. Ähnliche Ansätze verfolgt beispielsweise auch die Software von Palantir.

Einen weiteren Einblick habe das Beispiel Dänemark geboten. Malene Fischer, Deputy Chief Executive für Research, Innovation & Education am Rigshospitalet in Kopenhagen, habe die Einführung von Epic als konfliktreichen Prozess geschildert. Die Anfangsphase habe sie rückblickend als „nahe an einem Bürgerkrieg“ beschrieben. Hintergrund seien massive Umstellungen im Klinikalltag und erhebliche Widerstände im Personal gewesen.

Heute verfolge das Rigshospitalet einen pragmatischeren Ansatz. Epic diene als Kernsystem, während Innovation häufig in parallelen Systemen stattfinde. Neue Anwendungen, insbesondere im KI-Bereich, würden in separaten Umgebungen entwickelt, griffen auf die Daten zu und spielten Ergebnisse zurück. So entstehe eine hybride Architektur. Gerade im Bereich KI zeigte die Diskussion, dass die größten Effekte nicht unbedingt in der klassischen Medizin liegen, sondern in der Organisation. Durch datenbasierte Prognosen ließen sich Ressourcen gezielter einsetzen und Abläufe verbessern.

Wert von Gesundheitsdaten

Auch beim Thema Datennutzung wurden deutliche Unterschiede sichtbar. Michael Hübner, verantwortlich für Innovation und Digitalisierung bei den Sana Kliniken, betonte, dass Gesundheitsdaten zwar einen erheblichen wirtschaftlichen Wert hätten, deren direkter Verkauf in Deutschland jedoch rechtlich nicht zulässig und kulturell schwierig sei. Stattdessen entstünden Modelle, die rechtlich zulässig und ethisch besser seien, bei denen Daten in Kooperationen mit Forschung und Industrie genutzt würden, um sowohl Innovation zu fördern als auch die eigene Dateninfrastruktur zu finanzieren – eine „win-win situation“.

Diskussion um Risiken und Nutzen von Innovation gefordert

Ian Abbs, Strategic Advisor beim Guy’s and St Thomas’ NHS Foundation Trust, kritisierte eine Schieflage im Umgang mit Risiken. Das Risiko, nichts zu tun, werde komplett ignoriert oder nicht ernst genommen. Es brauche daher „eine sehr viel offenere und transparentere Debatte“ über Risiken und Nutzen von Innovation.

Abbs verwies zudem auf politische Initiativen wie den „10-year plan for the UK health system“, in denen technologische Innovation und Dateninfrastrukturen eine zentrale Rolle spielen sollen. Voraussetzung dafür seien große, sichere Datenräume, die gemeinsam mit Regulierungsbehörden genutzt werden, um Innovation kontrolliert einzuführen. Der Einsatz von Palantir im englischen Gesundheitssystem oder Cybervorfälle wurden nicht diskutiert.

Timo Minssen, Professor an der Universität Kopenhagen, betonte in einer anschließenden Diskussion, dass Innovation im Gesundheitswesen historisch nie durch vollständige Absicherung entstanden sei, sondern durch kontrolliertes Experimentieren. Ziel sei es, neue Technologien unter Aufsicht zu testen und schrittweise in die Anwendung zu bringen.

Er verwies auf internationale Beispiele wie in Singapur und ein KI-Reallabor in Utah. Dort wird gerade der Chatbot des Start-ups Doctronic getestet, um Folgeverschreibungen gemäß definierten Leitlinien automatisiert zu verlängern, Sicherheitsexperten wiesen jedoch bereits auf Schwächen hin. Auch in Deutschland entstehen zunehmend weitere KI-Reallabore, beispielsweise in Baden-Württemberg.

„Europa muss sich beeilen“

Laut Minssen muss sich Europa beeilen, da es drohe, im internationalen Wettbewerb um digitale Technologien zurückfallen. Gleichzeitig müssten die Reallabore robust gestaltet werden und dabei flexibel in den Prozessen, aber klar in Bezug auf Sicherheit, Werte und Haftung sein.

Organisationen arbeiten derzeit an Leitlinien und Standards für den Einsatz von KI im Gesundheitswesen. Dabei gehe es auch darum, solche Ansätze nicht nur national, sondern europaweit zu koordinieren.

Bettina Goerner, Chief Data Officer der cloud-basierten Praxissoftware Eterno, verwies zugleich auf die wachsende regulatorische Komplexität und sprach von einem „perfect storm“ aus sich überlagernden Regelwerken – von der DSG-VO über MDR bis zum AI Act, deren Anforderungen Rechtsexperten zufolge in Konflikt stehen. ,Unternehmen benötigen daher nicht nur Regeln, sondern vor allem klare Interpretationshilfen.

Thomas Renner aus dem Bundesgesundheitsministerium verwies auf neue Förderprogramme, darunter rund 650 Millionen Euro für die nächsten zehn Jahre für Dateninfrastrukturen und regulatorische „Sandboxes“ in Deutschland. Ziel sei es, den Datenzugang zu verbessern, regulatorische Prozesse zu strukturieren und Innovation schneller in die Anwendung zu bringen.

(mack)