Quelloffen · selbst gehostet · air-gap-fähig
EBM-Kodierung,
die Ihnen gehört.
openEBM liest Arztberichte, schlägt EBM-Ziffern mit Textbeleg vor – und lässt jede einzelne von einem nachvollziehbaren Regelwerk prüfen, bevor sie abgerechnet wird. Vollständig auf eigener Hardware. Ohne Cloud-Pflicht.
Für wen
Drei Perspektiven, ein System
openEBM ist gleichzeitig ein Praxiswerkzeug, eine IT-Infrastrukturentscheidung und ein offenes Software-Projekt — und für jede dieser Rollen aus einem anderen Grund überzeugend.
Ärzt:innen & Praxisinhaber:innen
Sie kodieren nicht mehr auswendig aus dem EBM-Katalog. Das System liest den Bericht, markiert die Textstelle je Ziffer – Sie entscheiden, in Sekunden statt Minuten.
- Textbeleg direkt im Bericht farblich markiert
- Mensch entscheidet immer zuletzt (Human-in-the-Loop)
- Lückenloses Audit-Log jeder Annahme/Ablehnung
IT-Verantwortliche in Praxis, MVZ & Klinik
Kein Patiententext verlässt Ihr Netzwerk. openEBM läuft air-gap-fähig auf eigener Hardware, mit eigenem Sprachmodell und eigener Datenbank.
- Docker-Compose-Deployment, on premise
- GDT-2.1-Anbindung an bestehende PVS-Systeme
- HL7-FHIR-R4-Schnittstelle für moderne KIS
Entwickler:innen & Health-Tech-Community
Der komplette Quellcode liegt offen. Jede Regel im Validierungsgraphen ist einsehbar, jede Entscheidung nachvollziehbar – keine Black Box.
- Vollständiges Repository unter github.com/h3rb3rn/openEBM
- MCP-Tool-Schnittstelle für eigene KI-Agenten
- Issues & Pull Requests willkommen
Digitale Souveränität
Medizinische Daten sind keine Trainingsdaten.
„Ein Abrechnungsassistent, der Patiententexte an eine US-Cloud schickt, ist kein Werkzeug der Praxis mehr — er ist ein Werkzeug des Anbieters, der die Praxis benutzt.“— Leitgedanke hinter der Architektur von openEBM
| Herkömmlicher Cloud-Copilot | openEBM | |
|---|---|---|
| Datenverarbeitung | Patiententext verlässt die Praxis, i.d.R. in Drittstaaten-Rechenzentren | Bleibt vollständig in Ihrer Infrastruktur, air-gap-fähig |
| Modellkontrolle | Fest an einen Anbieter gebunden, Modell wechselt ohne Ankündigung | Frei wählbares LLM-Backend, inkl. vollständig lokaler Ollama-Modelle |
| Nachvollziehbarkeit | Abrechnungsentscheidung ist Modell-Black-Box | Jede Ziffer regelbasiert im Graphen geprüft & protokolliert |
| Betriebsmodell | SaaS-Abo, Verfügbarkeit hängt vom Anbieter ab | Selbst gehostet, läuft auch ohne Internetzugang |
| Lizenz & Prüfbarkeit | Closed Source, Verhalten nicht auditierbar | Quelloffen — Code, Regeln & Prompts einsehbar |
Wie es funktioniert
Vorschlag ist Meinung. Prüfung ist Regel.
openEBM trennt bewusst zwei Systeme: ein sprachverstehendes Modell, das Vorschläge macht, und einen regelbasierten Validator, der jeden Vorschlag gegen echtes Abrechnungsrecht prüft.
Semantische Suche
ChromaDB findet passende EBM-Ziffern-Kandidaten aus dem Katalog zum Berichtstext.
Vorschlag mit Beleg
Das Sprachmodell schlägt Ziffern vor und markiert die exakte Textstelle als Beleg — source_text, confidence.
Deterministische Prüfung
Drei Regelwerke prüfen gegen den Neo4j-Graphen: Ausschlüsse, Tagesbudget, Demografie.
Entscheidung & Audit
Eine Person akzeptiert oder lehnt ab. Jede Entscheidung wird unveränderlich protokolliert.
In der Praxis
Kein Mockup. Echte Ergebnisse.
Erprobt mit einem lokal gehosteten qwen3.6:35b — die Analyse unten ist ein echtes Modellergebnis, keine gestellte Abbildung.
Technische Architektur
Für alle, die es genau wissen wollen.
Kein Marketing-Diagramm — die tatsächliche Systemarchitektur, wie sie im Repository dokumentiert und deploybar ist.
Stack
| Komponente | Technologie | Rolle |
|---|---|---|
| API | FastAPI (Python 3.12) | Web-Framework, REST + Jinja2-Frontend |
| DB | PostgreSQL 16 / SQLAlchemy 2 | Fallakten, Nutzer, Audit-Log, Mandanten |
| Vektor | ChromaDB | Semantische Suche im EBM-Katalog |
| Graph | Neo4j 5 | Ausschlüsse, Zeit- & Demografie-Regeln |
| Cache | Valkey (Redis-kompatibel) | Instant-Sessions, TTL-gesteuert |
| LLM | frei wählbar | Ollama lokal oder OpenAI-kompatible API |
| Validator | MCP-Server (Starlette/SSE) | Deterministische Regelprüfung |
| Betrieb | Docker Compose | Multi-Service, air-gap-fähig |
Deterministische Regeln (MCP)
Gegenseitige Ausschlüsse nach § 1 Abs. 3 EBM — prüft, ob zwei vorgeschlagene Ziffern im selben Quartal kollidieren.
Zeitprofilprüfung nach § 46 BMV-Ä — summiert Zeitwerte aller Ziffern gegen das physiologische Tagesmaximum.
Alters-, Geschlechts- und Kassenart-Restriktionen je Ziffer gegen die Patientendaten.
Interoperabilität
Bestehende Praxissoftware
ISO-8859-1-Dateiaustausch mit gängigen PVS-Systemen — Upload, Analyse, validierter GDT-Export.
Moderne KIS-Systeme
Custom Operation $analyze-ebm für DocumentReference, Composition und Parameters.
Eigene KI-Agenten
analyze_clinical_text_for_ebm als Werkzeug für externe Agenten im Kliniknetz, per HTTP/SSE.
Betriebssicherheit
- Mandantentrennung auf Anwendungsebene, pro Zeile geprüft
- httpOnly-Session-Cookie, serverseitig geprüft vor Rendering
- Unveränderliches Audit-Log — § 203 StGB & DSGVO-konform
- Air-Gap-fähig: kein CDN, keine externen Skripte oder Styles
- API-Schlüssel mit Scopes für externe Systemanbindung
- Lokal kompiliertes Frontend, keine Laufzeit-Abhängigkeit von Drittanbietern
Quellcode, Issues,
Beiträge.
git clone https://github.com/h3rb3rn/openEBM.git