Privates LLM im Krankenhaus on-premise: klinische Dokumentation, Gesundheitsdaten und Dimensionierung der GPU-Server

Privates LLM im Krankenhaus: was on-premise läuft

Ein Krankenhaus mit 1.000 bis 5.000 Mitarbeitern kann seine LLM-Workloads on-premise auf eigenen GPU-Servern betreiben; so bleiben jeder Prompt, jedes abgerufene Dokument und jeder Protokolleintrag im eigenen Netz. Klinischer Text enthält Gesundheitsdaten, die die DSGVO in Artikel 4 Nummer 15 als personenbezogene Daten bestimmt, die sich auf die körperliche oder geistige Gesundheit einer natürlichen Person beziehen, und deren Verarbeitung Artikel 9 Absatz 1 untersagt, sofern nicht eine Ausnahme nach Artikel 9 Absatz 2 greift. Die üblichen Workloads sind Entwürfe von Arzt- und Entlassbriefen und anderer Dokumentation, die Transkription von Arzt-Patienten-Gesprächen, Leitliniensuche und Kodierunterstützung. Mit den Beispielwerten dieses Artikels tragen zwei Server mit je vier RTX PRO 6000 oder zwei H200 NVL ein Krankenhaus, das 1.500 Mitarbeitern Zugang gibt, und jeder der beiden Server kann ausfallen, ohne dass der Dienst stoppt.

Workloads der klinischen Dokumentation und Modellklassen

Ein Entwurf für einen Entlassbrief geht von den Notizen, Laborwerten und der Medikationsliste eines Aufenthalts aus, die die Integration mit der elektronischen Krankenakte (EHR) an das Modell übergibt; eine Ärztin oder ein Arzt bearbeitet und unterschreibt den Entwurf. Diese Prompts sind lang, daher deklarieren wir für sie in der Dimensionierung unten einen Kontext von 32K (Beispielwert). Die Transkription wandelt den Ton der Gespräche mit einem Spracherkennungsmodell in Text um, und das LLM strukturiert ihn zu einer Notiz; unser Leitfaden zu Spracherkennungs-Servern für Whisper und Parakeet dimensioniert diesen Teil. Die Leitliniensuche ist Retrieval-Augmented Generation (RAG): Ein Embedding-Modell und ein Reranker finden Passagen im Leitlinienindex, und das LLM antwortet mit Angabe der Quelle. Die Kodierunterstützung schlägt aus einem fertigen Brief Diagnose- und Prozedurencodes vor, die das Kodierpersonal prüft.

Model Cards von gpt-oss-120b und MedGemma 27B auf Hugging Face, gelesen am 10. Oktober 2026; Embedding-Modelle und MIG wie in unserem Leitfaden zur Dimensionierung nach Unternehmensgröße; Kontexte und Karten sind unsere Beispiele.

gpt-oss-120b ist ein Checkpoint mit 65,3 GB, der auf eine Karte mit 96 GB passt. Googles Model Card zum auf Gesundheit abgestimmten MedGemma 27B sagt, das Modell „wurde ausschließlich mit medizinischen Texten trainiert“, nennt eine gesamte Eingabelänge von 128K Token und stellt die Nutzung unter die Nutzungsbedingungen der Health AI Developer Foundations. In BF16 belegen seine 27B Parameter nach unserer Rechnung rund 54 GB, was mit Platz für den Cache auf eine RTX PRO 6000 passt. Laut Model Card sind die Ausgaben des Modells „nicht dafür vorgesehen, klinische Diagnosen, Entscheidungen zum Patientenmanagement“, Behandlungsempfehlungen oder andere direkte klinische Anwendungen unmittelbar zu stützen. Vergleichen Sie beide Modelle vor der Wahl an einem Evaluierungsset anonymisierter Briefe.

Gesundheitsdaten nach Artikel 9 DSGVO und die Datenschutz-Folgenabschätzung

Artikel 9 Absatz 2 Buchstabe h DSGVO erlaubt eine Verarbeitung, die für Zwecke erforderlich ist, zu denen die medizinische Diagnostik sowie die Versorgung oder Behandlung im Gesundheits- oder Sozialbereich gehören, und Artikel 9 Absatz 3 bindet dies an Daten, die von Fachpersonal oder unter dessen Verantwortung verarbeitet werden, das dem Berufsgeheimnis unterliegt. Sobald ein Prompt Patienteninformationen enthält, enthalten auch die zugehörigen abgerufenen Passagen, Antworten, Caches und Gateway-Logs Gesundheitsdaten, wo immer sie gespeichert sind.

Artikel 35 Absatz 1 verpflichtet den Verantwortlichen, vor einer Verarbeitung, die voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat, eine Datenschutz-Folgenabschätzung (DSFA) durchzuführen, und Artikel 35 Absatz 3 Buchstabe b nennt unter den Fällen die umfangreiche Verarbeitung besonderer Kategorien personenbezogener Daten gemäß Artikel 9 Absatz 1. Artikel 32 Absatz 1 verlangt geeignete Maßnahmen, die unter anderem „die Pseudonymisierung und Verschlüsselung personenbezogener Daten“ einschließen sowie die Fähigkeit, die Verfügbarkeit der personenbezogenen Daten und den Zugang zu ihnen rasch wiederherzustellen. Die IT liefert der DSFA die Datenflüsse, den Ort, an dem das Modell läuft, die Aufbewahrung und das Zugriffsmodell; unser Leitfaden zur Datenschutz-Folgenabschätzung für ein internes LLM führt jede Angabe auf.

Wann Software nach der MDR ein Medizinprodukt wird

Nach Artikel 2 Nummer 1 der Medizinprodukteverordnung (EU) 2017/745 ist Software ein Medizinprodukt, wenn ihr Hersteller sie für Zwecke bestimmt, zu denen „Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheiten“ gehören. Nach Artikel 2 Nummer 12 ist die Zweckbestimmung die Verwendung, für die ein Produkt nach den Angaben des Herstellers bestimmt ist. Erwägungsgrund 19 ergänzt, dass „Software für allgemeine Zwecke, auch wenn sie in Einrichtungen des Gesundheitswesens eingesetzt wird,“ kein Medizinprodukt ist.

Regel 11 in Anhang VIII, wie sie die Leitlinie MDCG 2019-11 rev.1 vom Juni 2025 wiedergibt, stuft Software, die Informationen liefert, auf deren Grundlage Entscheidungen zu diagnostischen oder therapeutischen Zwecken getroffen werden, in Klasse IIa ein, in Klasse IIb, wenn solche Entscheidungen eine schwerwiegende Verschlechterung des Gesundheitszustands oder einen chirurgischen Eingriff verursachen können, und in Klasse III, wenn sie den Tod oder eine irreversible Verschlechterung verursachen können. Die Regel schließt damit, dass alle andere Software der Klasse I zugeordnet wird. Dieselbe Leitlinie sagt, dass Krankenhausinformationssysteme „für sich genommen nicht als Medizinprodukte einzustufen sind“ und dass Software, die nur speichert, archiviert, kommuniziert oder eine „einfache Suche“ ausführt, nicht als Medizinprodukt gilt. Sie fügt hinzu, dass „Module, die in EHR-Systeme integriert sind oder neben ihnen arbeiten, als MDSW gelten können, wenn sie einen medizinischen Zweck erfüllen“. Der Vorschlag der Kommission vom 16. Dezember 2025 zur Änderung der MDR (COM(2025) 1023 final) passt einige Klassifizierungsregeln an, darunter die für Software, was für bestimmte Produkte zu niedrigeren Risikoklassen führt. Arnold & Porter schrieb am 7. August 2026, die Abstimmung des Parlaments im Plenum über seinen Standpunkt werde „gegen oder kurz nach Neujahr“ erwartet; die hier wiedergegebene Regel ist die geltende.

Ob ein bestimmtes Werkzeug ein Medizinprodukt ist, in welche Klasse es fällt, ob die KI-Verordnung es als hochriskant behandelt und auf welcher Rechtsgrundlage Gesundheitsdaten verarbeitet werden, sind Bewertungen für die für Recht und Regulatorik zuständigen Stellen des Krankenhauses; die Wahl des Servers ändert daran nichts. Für die IT heißt das, die Zweckbestimmung jedes Werkzeugs zu dokumentieren und einen Schreibassistenten von jedem Werkzeug mit erklärter medizinischer Zweckbestimmung getrennt zu halten.

Risikoklassen der KI-Verordnung und der Europäische Gesundheitsdatenraum

Nach Artikel 6 Absatz 1 der KI-Verordnung ist ein KI-System hochriskant, wenn es selbst ein Produkt nach den in Anhang I aufgeführten Rechtsvorschriften oder ein Sicherheitsbauteil eines solchen Produkts ist und dieses Produkt einer Konformitätsbewertung durch Dritte unterzogen werden muss. MDCG 2025-6, im Juni 2025 von der MDCG und dem KI-Gremium gebilligt, wendet dies auf KI-Medizinprodukte an, wenn „das MDAI einer Konformitätsbewertung durch Dritte durch eine Benannte Stelle gemäß MDR/IVDR unterliegt“. Nach Artikel 113 in der durch die Verordnung (EU) 2026/1744 geänderten Fassung gelten diese Vorschriften ab dem 2. August 2028 und die für Verwendungen nach Anhang III ab dem 2. Dezember 2027. Anhang III Nummer 5 Buchstabe d nennt „Systeme für die Triage von Patienten bei der Notfallversorgung“. Ein Schreib- oder Suchassistent außerhalb dieser Kategorien trägt die Pflichten zu KI-Kompetenz und Transparenz, die unser Beitrag zu den Pflichten nach dem AI Act für Unternehmen, die LLMs betreiben erklärt.

Die Verordnung über den Europäischen Gesundheitsdatenraum (EHDS), Verordnung (EU) 2025/327 vom 11. Februar 2025, ist am 26. März 2025 in Kraft getreten. Die Kommission sagt auf ihrer EHDS-Seite über die Verordnung, sie „führt strenge Sicherheits- und Interoperabilitätskriterien für EHR-Systeme ein“. Nach dem Zeitplan der Seite gilt der Austausch von Patientenkurzakten und elektronischen Verschreibungen in allen Mitgliedstaaten ab März 2029, und der Austausch von „medizinischen Bildern, Laborergebnissen und Krankenhausentlassungsberichten“ soll bis März 2031 in allen Mitgliedstaaten funktionieren. Der Assistent schreibt seine Entwürfe in die elektronische Krankenakte, die das maßgebliche System bleibt. NIS2 nennt Gesundheitsdienstleister in Anhang I, und wenn ein Krankenhaus in ihren Anwendungsbereich fällt, erfassen die Maßnahmen nach Artikel 21 die KI-Server als Teil seiner Netz- und Informationssysteme.

Verordnungen (EU) 2016/679, 2017/745 und 2024/1689 (Artikel 113 in der durch 2026/1744 geänderten Fassung) und Richtlinie (EU) 2022/2555, Artikel 21 Absatz 2 Buchstaben i und j, auf eur-lex.europa.eu mit Stand Oktober 2026; nur allgemeine Information.

GPU-Server für 1.000 bis 5.000 Mitarbeiter dimensionieren

Wir dimensionieren nach der Spitzenzahl der Anfragen in Bearbeitung, mit der Methode und den Beispielwerten unseres Leitfadens zur Auslegung eines privaten ChatGPT-Servers nach Unternehmensgröße: 40 Prozent der Nutzer mit Zugang sind in der Spitzenstunde aktiv, mit je 6 Anfragen pro Stunde, 30 Sekunden je Anfrage und einem Spitzenfaktor von 2. Wir nehmen an, dass die Hälfte der Mitarbeiter Zugang erhält (Beispielwert). Nach der Schätzung in diesem Leitfaden hält gpt-oss-120b bei deklarierten 32K Kontext mit einem 16-Bit-Cache rund 19 Gespräche auf einer RTX PRO 6000 und rund 55 auf einer H200 NVL.

Beispielwerte aus unserem Leitfaden zur Dimensionierung nach Unternehmensgröße, dazu 50 Prozent der Mitarbeiter mit Zugang (Beispielwert); Sitzungen je Server aus seiner Schätzung für gpt-oss-120b bei 32K; die L4 trägt das Embedding-Modell und den Reranker; Karten für die Spracherkennung kommen hinzu.

Bei 3.000 Mitarbeitern ergeben 1.500 Nutzer mit Zugang 600 in der Spitzenstunde und 3.600 Anfragen, eine pro Sekunde, also im Mittel 30 in Bearbeitung und 60 in der Beispielspitze. Jeder Server hält die ganze Spitze, damit der Dienst den Ausfall eines Servers übersteht. Mit diesen Beispielwerten braucht ein Krankenhaus mit 5.000 Mitarbeitern sechs RTX PRO 6000 je Server oder zwei H200 NVL. Ein anderes Modell ändert die Werte je Karte; wiederholen Sie die Rechnung daher mit seinen Gewichten und seinem Cache.

Wir bauen Inferenzserver mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Schicken Sie uns Ihre Mitarbeiterzahlen, Workloads und die Modelle, die Sie prüfen, über das Formular unten.

Die LLM-Plattform von Bildgebungs-KI und klinischen Netzen trennen

Ein Inferenzserver der Radiologie übernimmt 3D-Untersuchungen aus dem PACS, und sein GPU-Speicher richtet sich nach der Größe des Volumens, wie unser Leitfaden zum KI-Server für medizinische Bildgebung darlegt. Getrennte Server lassen sich jeweils für sich aktualisieren, testen und dokumentieren, was zählt, wenn nur ein Werkzeug eine erklärte medizinische Zweckbestimmung hat.

Stellen Sie die LLM-Server in eine eigene Netzwerkzone. Die Nutzer erreichen nur das Gateway, mit Single Sign-on und Multi-Faktor-Authentifizierung. Die Integrations-Engine ist das einzige System, das Patientendaten an das Modell übergibt, und das Retrieval prüft die Rechte jedes Nutzers im Quellsystem, bevor eine Passage in den Prompt gelangt. Die Modellserver brauchen keinen ausgehenden Internetzugang; Checkpoints kommen über einen kontrollierten Import mit Prüfsummen herein, und die Management-Controller stehen im Verwaltungsnetz.

Das Gateway-Log erfasst Nutzer, Zeit, Modell, Prompt und Antwort. Es enthält Gesundheitsdaten, daher ist der Zugriff darauf beschränkt und seine Aufbewahrungsdauer wird in der DSFA festgelegt. Für eine Hochrisiko-Verwendung verlangt Artikel 26 Absatz 6 der KI-Verordnung von Betreibern, die Protokolle mindestens sechs Monate aufzubewahren.

Unsere Leistung Private AI/ML stellt private LLMs und RAG mit Protokollierung der Anfragen und den Zugriffsrechten jedes Nutzers bereit, mit Engineering von unserem Engineering-Partner Vixen.UNO. Beschreiben Sie Ihre Workloads und die Netzwerkzone im Formular unten.

Was wir liefern

Wir liefern die Karten, die eine LLM-Plattform im Krankenhaus nutzt, die H200 NVL, RTX PRO 6000 Server Edition, L40S und L4, als Karten oder in auf Bestellung gebauten KI-Servern, montiert und im Burn-in getestet, mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung; unser GPU-Sortiment führt jede Karte auf. NVIDIA-AI-Enterprise- und vGPU-Lizenzen kommen auf dieselbe Rechnung. Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Deployment der Modelle, RAG, Protokollierung und Zugriffskontrolle darauf ist unsere Leistung Private AI/ML, auf Ihren Servern oder in einem Tier-3-Rechenzentrum in Litauen, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ