Schneller Service
Kostenlose Rückmeldung innerhalb von 24 Stunden
Erfolg durch Erfahrung
Aus über 15.000 Projekten im Jahr wissen wir, worauf es ankommt
Der digitale Marktführer
Unsere Kunden sprechen für uns:
4,9 von 5 Sternen auf Google
Abstract – Praxissoftware Linux: Kompatible PVS-Lösungen im Überblick
- Nur wenige KBV-zertifizierte Praxisverwaltungssysteme unterstützen Linux nativ: t2med ist das einzige vollständig KOB-zertifizierte System (§ 372 SGB V) mit plattformübergreifendem Betrieb unter Linux, Windows und macOS; Open-Source-Systeme wie GNUmed und Elexis sind nicht für die GKV-Abrechnung zugelassen.
- Seit März 2024 gilt das Konformitätsbewertungsverfahren (KOB) der gematik als gesetzliche Pflicht für alle im Vertragsarztbetrieb eingesetzten PVS; ein nicht-zertifiziertes System schließt die KV-Abrechnung aus, Übergangsfristen greifen nur unter engen Voraussetzungen.
- GNUmed (Open Source, GPL, PostgreSQL-Backend) und Elexis (Java-basiert, modular) eignen sich für Privatpraxen oder als Ergänzungssystem, nicht jedoch für Praxen mit GKV-Vertrag; fehlende Support-SLA und lückenhafte TI-Integration (ePA, eAU, eRezept, KIM) sind die zentralen operativen Risiken.
- Vor einem Betriebssystemwechsel sind KOB-Status, TI-Kompatibilität, Peripherie-Treiber (Kartenterminals, Laborgeräte nach GDT/xDT), Datenmigration und ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO schriftlich zu klären.
Inhaltsverzeichnis
Warum Linux in der Arztpraxis ein Sonderfall ist
Marktanteil: Windows-Dominanz und die Folgen für PVS-Hersteller
Der deutsche Markt für Praxisverwaltungssoftware wird von wenigen großen Anbietern dominiert — CGM Medistar, Medatixx, Medical Office und Tomedo halten zusammen den überwiegenden Anteil der Installationen. Ihr fast durchgängiger Nenner: Bis auf Tomedo sind alle primär für Windows zertifiziert – Tomedo hingegen hat sich als führende Praxissoftware für Mac und Apple etabliert. Linux spielt im PVS-Markt eine Randrolle — das folgt schlicht der Nachfragestruktur. Die meisten KBV-zertifizierten PVS wurden primär für Windows entwickelt — nur wenige Anbieter unterstützen Linux nativ.
Das hat direkte Konsequenzen für die Entwicklungsprioritäten der Hersteller. Eine native Linux-Unterstützung erfordert separate Testumgebungen, eigene Zertifizierungsläufe und langfristigen Wartungsaufwand. Diese Kosten scheuen die meisten Anbieter, solange die Nachfrage gering bleibt. Praxen, die dennoch auf Linux setzen wollen, stehen deshalb vor einer eingeschränkten, aber klar umrissenen Produktlandschaft.
Zertifizierungspflicht nach § 372 SGB V und Betriebssystemabhängigkeit
Seit Inkrafttreten des Gesetzes zur Beschleunigung der Digitalisierung des Gesundheitswesens im März 2024 gilt für PVS-Hersteller die Pflicht zur Konformitätsbewertung (KOB) nach § 372 SGB V. Die gematik prüft dabei, ob das jeweilige System definierte technische Anforderungen erfüllt — insbesondere die korrekte Umsetzung der Medikationsliste in der elektronischen Patientenakte. Ohne KOB-Zertifikat darf ein PVS nicht für die Abrechnung über die Kassenärztlichen Vereinigungen eingesetzt werden.
Die Zertifizierung bezieht sich auf das Produkt in einer bestimmten Version und Konfiguration, nicht auf das Betriebssystem als solches. Ein Anbieter, der seine Software nur für Windows zertifiziert hat, darf dieselbe Software unter Linux nicht als KOB-zertifiziertes PVS betreiben. Praxen müssen deshalb vor einem Linux-Einsatz beim Hersteller schriftlich anfragen, ob genau ihre geplante Konfiguration unter den zertifizierten Betrieb fällt.
Haftungsrisiko: Wer ein nicht-zertifiziertes PVS im KV-Abrechnungsbetrieb einsetzt, riskiert Abrechnungsausschlüsse. Die KBV hat Übergangsfristen von bis zu 18 Monaten für bestimmte Praxen erlassen — diese greifen jedoch nur unter engen Voraussetzungen (z. B. bevorstehende Praxisaufgabe, Krankheit, Elternzeit). Klären Sie den KOB-Status vor jeder Systemumstellung schriftlich mit dem Hersteller ab.
Telematikinfrastruktur-Kompatibilität als Entscheidungskriterium
Seit der verpflichtenden Einführung der Telematikinfrastruktur (TI) sind alle Vertragsarztpraxen zur Anbindung verpflichtet. Der Konnektor — physisch in der Praxis installiert oder als Cloud-Variante — kommuniziert mit dem PVS über standardisierte Schnittstellen. Die gematik schreibt hierfür KIM, ePA, eAU und eRezept vor.
Technisch sind diese Schnittstellen betriebssystemunabhängig spezifiziert. Ob die Kompatibilität in der Praxis funktioniert, hängt aber davon ab, ob der PVS-Hersteller seinen Linux-Client vollständig gegen die TI-Schnittstellen implementiert hat. t2med bietet eine vollständige TI-Integration — zertifiziert für ePA, eAU, eRezept, KIM, eArztbrief und weitere Fachanwendungen. GNUmed und Elexis sind hier noch nicht vollständig. Die TI-Tauglichkeit ist deshalb neben dem KOB-Zertifikat das zweite entscheidende Kriterium bei der Softwareauswahl.
Welche Praxissoftware läuft unter Linux?
Die folgende Tabelle zeigt den Stand der aktuell relevanten Systeme mit Linux-Unterstützung. Angaben basieren auf Herstellerdokumentation und der KBV-Zulassungsübersicht.
| PVS-Anbieter | Linux-Unterstützung | KOB-Zertifizierungsstatus | Lizenzmodell |
|---|---|---|---|
| GNUmed | Nativ (alle gängigen Distributionen) | Nicht KOB-zertifiziert | Open Source (GPL) |
| Elexis | Nativ via Java-Runtime | Keine KBV-Zertifizierung für DE | Open Source + kommerziell |
| t2med | Server + Client: Linux, Windows, macOS | KOB-zertifiziert (KVDT, TI) | Proprietär, Pauschale/BSNR |
| EPIKUR e-medico | Nativ Linux — TI-Konnektor (Epikur Telematik PRO) nur Windows/macOS | KBV-zertifiziert (KVDT) | Proprietär, nutzerbezogen |
| Data Vital (CGM) | Server: Linux-Option; Client: Windows | KOB-zertifiziert | Proprietär |
| APRIS | Nativ Linux | Herstellerangabe prüfen | Proprietär |
| Cloud-PVS (z. B. Doctolib u. a.) | Vollständig browserbasiert — betriebssystemunabhängig | Je nach Anbieter: KOB-Status prüfen | SaaS, nutzungsbasiert |
GNUmed: Open-Source-PVS mit nativer Linux-Unterstützung
GNUmed ist das bekannteste quelloffene Praxisverwaltungssystem mit dezidierter Linux-Unterstützung. Das Projekt wird seit 2000 von einer internationalen Entwicklergemeinschaft gepflegt und läuft stabil unter Debian, Ubuntu, Fedora und anderen gängigen Distributionen. Die Datenbankebene basiert auf PostgreSQL, der Client ist in Python geschrieben.
Für den deutschen Kassenarztbetrieb hat GNUmed einen entscheidenden Nachteil: Das System hat keine KOB-Zertifizierung durchlaufen. Eine Nutzung für die GKV-Abrechnung ist damit ausgeschlossen. In der Privatpraxis, in der Forschung oder als ergänzendes Dokumentationssystem ist GNUmed einsatzfähig — mehr dazu im Artikel zu kostenloser Praxissoftware. Die Community-Dokumentation ist auf Englisch; Support beschränkt sich auf Foren und Mailinglisten.
Elexis: Java-basierte Plattformunabhängigkeit
Elexis entstand ursprünglich für den Schweizer Markt und wird heute auch in Deutschland eingesetzt. Die Java-Basis ermöglicht den Betrieb unter Linux, Windows und macOS ohne größere Anpassungen. Das System ist modular aufgebaut: Kernfunktionen sind kostenfrei, spezifische Module — für Labor, Bildgebung oder Fachrichtungen — werden kommerziell angeboten.
Für den deutschen Vertragsarztbetrieb gilt analog zu GNUmed: Eine KBV-Zertifizierung für den deutschen Markt liegt nicht vor. Praxen, die Elexis in Deutschland einsetzen wollen, müssen den aktuellen Zertifizierungsstatus direkt beim Anbieter erfragen. Die TI-Integration ist in Entwicklung, aber noch nicht für alle Anwendungsfälle produktiv verfügbar.
EPIKUR e-medico: Native Linux-Unterstützung mit TI-Einschränkung
EPIKUR e-medico läuft laut Herstellerangabe ohne Virtualisierungssoftware nativ unter Linux, Windows und macOS — auch im Mischbetrieb innerhalb einer Praxis. Das gilt für alle Fachrichtungen, nicht nur für den Bereitschaftsdienst. EPIKUR ist in der KBV-Zulassungsübersicht für die vertragsärztliche Abrechnung (KVDT) gelistet und damit grundsätzlich für den GKV-Betrieb geeignet.
Die entscheidende Einschränkung betrifft die TI-Anbindung: Der herstellereigene Dienst Epikur Telematik PRO unterstützt offiziell nur Windows und macOS. Praxen, die EPIKUR unter Linux betreiben und den eigenen TI-Dienst von EPIKUR nutzen wollen, stoßen hier an eine Grenze. Technisch ist eine Umgehung über einen TI-Konnektor eines Drittanbieters möglich — dessen Linux-Kompatibilität muss dann separat geprüft werden.
t2med und Data Vital (CGM): Serverbasierte Lösungen mit Linux-Option
t2med ist KOB-zertifiziert und offiziell plattformübergreifend — Server und Client laufen unter Linux, Windows und macOS. Laut KBV-Installationsstatistik (Q1/2025) belegt t2med innerhalb aller PVS-Systeme für die Allgemeinmedizin Rang 5 mit dem höchsten absoluten Zuwachs unter den Top 5. Die TI-Integration deckt alle Pflichtanwendungen ab: ePA, eAU, eRezept, KIM, eArztbrief und weitere.
Data Vital (CGM) bietet ebenfalls eine serverbasierte Architektur mit Linux-Option für den Datenbankserver. Der Client setzt jedoch Windows voraus. Eine vollständige Linux-Praxis-IT ist damit mit Data Vital nicht realisierbar.
Cloud-PVS: Browserbasierte Systeme als betriebssystemunabhängige Option
Eine Kategorie wird in der Linux-Diskussion häufig übersehen: vollständig browserbasierte Cloud-Praxissoftware. Systeme wie Doctolib oder cloudbasierte Varianten etablierter PVS laufen ausschließlich im Webbrowser — damit sind sie technisch betriebssystemunabhängig und funktionieren unter Linux ebenso wie unter Windows oder macOS, solange ein aktueller Browser (Chrome, Firefox) installiert ist.
Das klingt nach der einfachsten Linux-Lösung — ist aber an drei Voraussetzungen geknüpft:
- KOB-Zertifizierung: Auch Cloud-PVS müssen das Konformitätsbewertungsverfahren nach § 372 SGB V durchlaufen, wenn sie für die vertragsärztliche Abrechnung eingesetzt werden. Nicht alle am Markt verfügbaren Cloud-Anbieter haben die KOB bereits vollständig absolviert. Prüfen Sie den aktuellen Status direkt beim Anbieter oder über die gematik-Übersicht der KOB-zertifizierten Systeme.
- Peripherie bleibt ein lokales Linux-Problem: Der Browser läuft unter Linux — Kartenterminals, Laborgeräte und Drucker benötigen aber weiterhin funktionierende Treiber auf dem lokalen Betriebssystem. Die im Abschnitt zum Betriebssystemwechsel beschriebenen Treiberprobleme gelten damit auch für Cloud-PVS-Installationen unter Linux.
- TI-Konnektor-Anbindung: Cloud-PVS kommunizieren mit dem lokalen Konnektor in der Regel über eine kleine lokale Connector-App oder direkt über den Browser. Diese Komponente muss unter Linux lauffähig und vom Hersteller explizit unterstützt sein. Fragen Sie vor der Implementierung, ob eine Linux-kompatible Konnektor-Anbindung offiziell getestet und freigegeben ist.
Open-Source-PVS vs. proprietäre Praxissoftware unter Linux
Kriterien: KOB-Zertifizierung, DSGVO-Konformität, Support-SLA
Die Entscheidung zwischen Open-Source- und proprietärer Praxissoftware hat konkrete rechtliche und betriebliche Konsequenzen.
KOB-Zertifizierung ist für GKV-Praxen nicht verhandelbar. Unter den Linux-kompatiblen Systemen sind aktuell nur proprietäre Lösungen vollständig zertifiziert. Open-Source-Systeme wie GNUmed eignen sich ausschließlich als Praxissoftware für Privatpraxen oder als Ergänzungssystem.
DSGVO-Konformität ist betriebssystemunabhängig. Sie hängt von Konfiguration, Zugriffsrechten, Verschlüsselung und Auftragsverarbeitungsverträgen ab. Open-Source-Systeme bieten vollständige Quellcode-Transparenz; proprietäre Systeme liefern in der Regel fertige AVV-Vertragswerke und dokumentierte TOMs. Grundlegendes zum Datenschutz in der Arztpraxis gilt hier unabhängig vom gewählten Betriebssystem.
Support-SLA ist bei Open Source nicht standardisiert. GNUmed und Elexis haben keine garantierten Reaktionszeiten. Das ist ein kritischer Faktor: Ein Systemausfall stoppt den Behandlungsablauf direkt. Proprietäre Anbieter wie t2med bieten vertraglich vereinbarte Support-Fenster.
Open Source vs. proprietär — Kosten, Wartung, Updatezyklus
| Kriterium | Open Source (z. B. GNUmed) | Proprietär (z. B. t2med) |
|---|---|---|
| Lizenzkosten | 0 € | 1.200–4.000 €/Jahr (je Ausbaustufe) |
| KOB-Zertifizierung | Nein | Ja |
| TI-Integration | Eingeschränkt / in Entwicklung | Vollständig |
| Support-SLA | Community / keine Garantie | Vertraglicher Support |
| Updatezyklus | Community-getrieben | Quartalsweise |
| Datenhaltung | Selbst gehostet (PostgreSQL) | Lokal oder Managed Service |
| DSGVO-AVV | Selbst konfigurieren | Fertige Vertragswerke |
Selbst-Hosting vs. Managed Service
Wer Linux-basierte Praxissoftware selbst hostet, übernimmt Verantwortung für Betriebssystem-Updates, Datenbankwartung, Backup-Prozesse und Sicherheitskonfiguration. Das setzt eigenes IT-Wissen voraus oder erfordert einen externen IT-Dienstleister mit Erfahrung im Gesundheitsbereich — inklusive schriftlichem Auftragsverarbeitungsvertrag gemäß Art. 28 DSGVO. Hinweise zur sicheren Praxis-IT gelten beim Linux-Betrieb in besonderem Maße.
Managed-Service-Modelle gibt es auch für Linux-basierte Backends. t2med bietet diese Option an. Der Vorteil: Die Praxis wird von Betriebspflichten entlastet. Der Nachteil: Die Daten verlassen die Praxis-IT und müssen sorgfältig vertraglich abgesichert werden.
Tipp: Lassen Sie sich vor Vertragsabschluss schriftlich bestätigen, in welchem Rechenzentrum die Daten liegen, ob es sich im EWR befindet und ob Subauftragnehmer involviert sind.
Praxissoftware unter Linux: Kosten realistisch einschätzen
Lizenzkosten entfallen — aber welche Folgekosten entstehen?
Die Entscheidung für Open-Source-Praxissoftware unter Linux erzeugt keine Lizenzkosten, aber nennenswerte Folgekosten. Wer GNUmed in einer Privatpraxis betreiben will, braucht mindestens eine initiale Servereinrichtung, eine Backup-Lösung und regelmäßige Systemwartung. Ohne eigene IT-Kompetenz fallen externe IT-Kosten von schätzungsweise 1.000–2.500 € jährlich an.
Proprietäre Linux-kompatible Lösungen wie t2med kalkulieren nach Nutzern und Betriebsstätten. Eine Einzelarztpraxis zahlt je nach Ausbaustufe zwischen 1.500 und 3.000 € jährlich. Hinzu kommen einmalige Einrichtungskosten und Schulungsaufwand. Wer sein System grundsätzlich hinterfragt, findet im Ratgeber zum Praxissoftware wechseln eine strukturierte Entscheidungshilfe.
Interne IT-Kompetenz vs. externer Support
| Szenario | Interne IT vorhanden | Externer IT-Dienstleister |
|---|---|---|
| GNUmed Privatpraxis | Realistisch, mittlerer Aufwand | 1.000–2.500 €/Jahr |
| t2med mit Linux-Server | Erfahrung empfohlen | Im Herstellervertrag oder separat |
| Hybrid (Linux-Server, Windows-Client) | Höherer Konfigurationsaufwand | 1.500–3.500 €/Jahr |
TCO: Linux-PVS vs. Windows-PVS im Vergleich
Über fünf Jahre betrachtet nähern sich die Gesamtkosten einer Linux-basierten Open-Source-Lösung und einer Windows-PVS stärker an, als es die Lizenzkosten allein suggerieren. Windows-Server-Lizenzen (ca. 800–1.500 € einmalig) entfallen bei Linux. Dafür entstehen höhere Administrationskosten, wenn kein hausinternes Linux-Know-how vorhanden ist.
Proprietäre PVS unter Windows bieten den Vorteil eines einzigen Ansprechpartners für Software, Updates und Hardware-Empfehlungen. Linux-Installationen verteilen die Verantwortung auf mehrere Parteien — Betriebssystem-Community, Datenbank-Community und PVS-Hersteller. Das kann Fehleranalyse und Support verkomplizieren. Wer die Buchhaltungsintegration seiner Praxissoftware mitdenken muss, findet dazu ergänzende Hinweise im Artikel Praxissoftware und Buchhaltung.
Wechsel zu Linux: Worauf Praxisinhaber achten müssen
Datenmigration und Schnittstellenkompatibilität (GDT, xDT, FHIR)
Jeder PVS-Wechsel erfordert eine strukturierte Datenmigration. Im deutschen Praxisumfeld sind die relevanten Formate GDT (Gerätedatentransfer für Laborgeräte), xDT (Datenaustausch zwischen PVS und Laboren) sowie FHIR (HL7 Fast Healthcare Interoperability Resources) für die Interoperabilität mit der ePA. Die technischen Grundlagen der GDT-Schnittstelle sind für den reibungslosen Gerätebetrieb unter Linux besonders relevant.
GNUmed unterstützt GDT und xDT; die FHIR-Implementierung ist lückenhaft. t2med unterstützt alle drei Standards. Sichern Sie bei einem Wechsel den Datenbestand im xDT-Format und testen Sie den Import im Zielsystem mit realen, anonymisierten Datensätzen vor der Migration.
Tipp: Lassen Sie sich schriftlich bestätigen, welche Datenkategorien vollständig übertragen werden und welche manuell nachgepflegt werden müssen — insbesondere Dauerdiagnosen, Dauermedikation und Befunddokumente.
Peripheriegeräte: Drucker, KVK-Leser, Laborgeräte unter Linux
Die größte praktische Hürde beim Umstieg liegt nicht bei der PVS-Software, sondern bei der Peripherie.
Kartenterminals: Geräte der Hersteller Cherry und Reiner SCT bieten Linux-Treiber an. Ältere Geräte oft nicht. Prüfen Sie die Treiberunterstützung Ihrer spezifischen Hardware vor dem Wechsel.
Laborgeräte: GDT-kompatible Geräte kommunizieren über serielle Schnittstellen oder Netzwerk — in der Regel betriebssystemunabhängig, sofern der GDT-Empfänger des PVS korrekt konfiguriert ist.
Drucker: CUPS (Common Unix Printing System) deckt die meisten Netzwerkdrucker ab. Einzelblattzuführung für Formulare kann systemspezifisch abweichen.
Checkliste: 6 Schritte vor dem Betriebssystemwechsel
- [ ] KOB-Zertifizierungsstatus der Ziel-PVS für Linux schriftlich beim Hersteller anfragen
- [ ] TI-Kompatibilität (Konnektor, KIM, ePA) für die Linux-Konfiguration bestätigen lassen
- [ ] Treiberkompatibilität aller Peripheriegeräte (Kartenterminals, Drucker, Laborgeräte) prüfen
- [ ] Datenexport aus dem bisherigen PVS im xDT-Format erstellen und sichern
- [ ] Testimport im Zielsystem mit realen (anonymisierten) Datensätzen durchführen
- [ ] DSGVO-Auftragsverarbeitungsvertrag mit neuem Anbieter und IT-Dienstleister abschließen
FAQ: Häufige Fragen zu Praxissoftware unter Linux
Ist eine KOB-zertifizierte Praxissoftware unter Linux zugelassen?
Ja — sofern der Hersteller seine Software explizit in einer Linux-Konfiguration zertifiziert hat. Das Konformitätsbewertungsverfahren nach § 372 SGB V bezieht sich auf das Produkt in einer definierten Version und Konfiguration, nicht auf das Betriebssystem. t2med ist ein Beispiel für ein vollständig zertifiziertes System mit Linux-Betrieb. Entscheidend ist die schriftliche Herstellerbestätigung, dass genau Ihre geplante Konfiguration unter den zertifizierten Betrieb fällt.
Kann ich einen bestehenden Patientendatenbestand nach GNUmed migrieren?
Technisch ist eine Migration möglich, wenn das bisherige System einen xDT- oder strukturierten CSV-Export liefert. Praktisch ist der Prozess aufwendig und setzt technische Kenntnisse voraus. Eine vollautomatische Migration ohne Datenverlust ist nicht garantiert — insbesondere bei Freitextdokumentation, Bilddaten und eingebetteten Befunden. Für eine Privatpraxis mit überschaubarem Datenbestand ist die Migration realistisch. Wer ohnehin über einen Praxissoftware-Wechsel nachdenkt, findet dort auch allgemeine Migrationshinweise.
Welche Auswirkungen hat Linux auf die Anbindung an die Telematikinfrastruktur?
Die TI-Anbindung erfolgt über einen Konnektor — physisch oder als Cloud-Konnektor. Die Kommunikation zwischen Konnektor und PVS ist über standardisierte APIs spezifiziert und grundsätzlich betriebssystemunabhängig. Ob die TI-Tauglichkeit in der Praxis gegeben ist, hängt davon ab, ob der PVS-Hersteller seinen Linux-Client vollständig gegen die TI-Schnittstellen implementiert hat. t2med erfüllt diese Voraussetzung; GNUmed und Elexis sind hier noch nicht vollständig. Klären Sie bei einem Wechsel alle TI-Pflichtfunktionen (eGK, KIM, eAU, ePA, eRezept) konkret mit dem Hersteller ab.