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)

KI-Bilder zu generieren, erfordert normalerweise leistungsfähige Hardware – und man hat eher kein eigenes Rechenzentrum zu Hause stehen. Doch ein Projekt namens OnnxStream bringt die Bildgenerierungs-KI Stable Diffusion dank ausgefeilter Optimierungen auf dem Raspberry Pi zum Laufen.

Stable Diffusion gehört zu den besten Generierungs-Modellen für Bilder. Der Vorteil: Anders als Dall-E von OpenAI oder Nano Banana von Google ist Stable Diffusion Open Source. Der offene Ansatz ermöglicht es, die Modelle lokal zu nutzen, statt nur über Cloud-Dienste. Außerdem muss der Nutzer sich nicht mit Beschränkungen bei den Prompts und Abomodellen von KI-Firmen herumschlagen.

Die KI läuft dank OnnxStream sogar auf einem Raspberry Pi Zero 2 mit schwachbrüstigen 512 MByte Arbeitsspeicher. Wer mehrere Stunden wartet, erhält selbst auf dieser Minimalhardware ein generiertes KI-Bild. Alltagstauglicher ist der Einsatz hingegen auf einem Raspberry Pi 5 mit aktiver Kühlung. Hier reduziert sich die Warterei auf rund drei Minuten. Wir zeigen, wie Sie OnnxStream installieren und lokal eigene Bilder erzeugen.

Das war die Leseprobe unseres heise-Plus-Artikels „KI-Bilder lokal generieren: Stable Diffusion auf dem Raspberry Pi einsetzen“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.