Archiv- und Wechselschnittstelle, Verschlüsselte Datenbank, Software-Wechsel, Vertragsende
Archiv- und Wechselschnittstelle, Verschlüsselte Datenbank, Software-Wechsel, Vertragsende
Zitat von Johannes Neimann am 26. August 2025, 18:06 UhrWo ist die Archiv- und Wechselschnittstelle eigentlich in MO anzutreffen?
Wie ich höre betrachtet Indamed das Kennwort für die MariaDB als deren Eigentum. Daher ergeben sich ein paar Fragen:
- Erhalte ich das Kennwort nach Vertragsende, um dann mit meinen Daten machen zu können, was ich will?
- Erhalte ich Zugriff auf das Kennwort/ die Datenbank im Falle eines gewünschten Wechsel zu einem anderen PVS?
- Wer verwaltet während der Vertragslaufzeit das Kennwort und was passiert, wenn diese Person(en) oder diese Dienstleister vom Markt gehen?
- Haben sowohl Systemhaus als auch Hersteller Zugriff auf das Kennwort?
Wo ist die Archiv- und Wechselschnittstelle eigentlich in MO anzutreffen?
Wie ich höre betrachtet Indamed das Kennwort für die MariaDB als deren Eigentum. Daher ergeben sich ein paar Fragen:
- Erhalte ich das Kennwort nach Vertragsende, um dann mit meinen Daten machen zu können, was ich will?
- Erhalte ich Zugriff auf das Kennwort/ die Datenbank im Falle eines gewünschten Wechsel zu einem anderen PVS?
- Wer verwaltet während der Vertragslaufzeit das Kennwort und was passiert, wenn diese Person(en) oder diese Dienstleister vom Markt gehen?
- Haben sowohl Systemhaus als auch Hersteller Zugriff auf das Kennwort?
Zitat von Johannes Braun am 26. August 2025, 18:23 UhrIn den Selling Points für mariadb stand, dass die Praxis sich nun ein Datenbankpasswort aussuchen kann – auch wenn ich es bisher nur erlebt hab, dass die Dienstleister einfach das Standartpasswort verwendet haben, welches in der Anleitung steht …
Passwörter für Datenbanken lassen sich zurücksetzen, außerdem steht das Passwort verschlüsselt in einer Konfigurationsdatei (offiziell kann nur INDAMED das Passwort entschlüsseln)
Grundsätzlich sind das ihre Daten und ihre Systeme – wenn sie Zugangsdaten haben möchen sehe ich keinen Grund warum man dies nicht möglich sein soll, MariaDB ist ein Datenbanksystem welches mehere Benutzer mit unterschiedlichen Berechtigungen verwalten kann, man könnte da auch ein Benutzer mit nur „Lesezugriff“ anlegen
In den Selling Points für mariadb stand, dass die Praxis sich nun ein Datenbankpasswort aussuchen kann – auch wenn ich es bisher nur erlebt hab, dass die Dienstleister einfach das Standartpasswort verwendet haben, welches in der Anleitung steht …
Passwörter für Datenbanken lassen sich zurücksetzen, außerdem steht das Passwort verschlüsselt in einer Konfigurationsdatei (offiziell kann nur INDAMED das Passwort entschlüsseln)
Grundsätzlich sind das ihre Daten und ihre Systeme – wenn sie Zugangsdaten haben möchen sehe ich keinen Grund warum man dies nicht möglich sein soll, MariaDB ist ein Datenbanksystem welches mehere Benutzer mit unterschiedlichen Berechtigungen verwalten kann, man könnte da auch ein Benutzer mit nur „Lesezugriff“ anlegen
Zitat von Peter Quick am 26. August 2025, 18:32 UhrDa ich damals Maria-DB selbst aufgesetzt hatte, habe ich das Paßwort für die Datenbank. Das ist aber prinzipiell nicht geheim, dass kann man jederzeit bei seinem First Level Service erfragen. Von daher sehe ich da auch kein Problem. Ich würde den First Level Service bitten, mir das Passwort auszuhändigen und es dann selber gut verwahren.
Und im Übrigen ist Indamed nicht die CompuGroup. Ich habe immer ein vernünftiges Gespräch mit dem Support oder auch dem Second Level Support führen können. Immer gab es eine vernünftige Lösung für die Probleme.
Da ich damals Maria-DB selbst aufgesetzt hatte, habe ich das Paßwort für die Datenbank. Das ist aber prinzipiell nicht geheim, dass kann man jederzeit bei seinem First Level Service erfragen. Von daher sehe ich da auch kein Problem. Ich würde den First Level Service bitten, mir das Passwort auszuhändigen und es dann selber gut verwahren.
Und im Übrigen ist Indamed nicht die CompuGroup. Ich habe immer ein vernünftiges Gespräch mit dem Support oder auch dem Second Level Support führen können. Immer gab es eine vernünftige Lösung für die Probleme.
Zitat von Christian Schnell am 27. August 2025, 13:24 UhrHallo,
Sie sollten auf Ihre Passwörter auch selbst zugreifen können: das MariaDB Passwort steht nach meiner Erinnerung in der My.ini im MariaDB-Datenbank-Ordner und daneben in den Skripten zur Datenbank Sicherung drin.
Das Passwort für das Dokumentenarchiv steht in der MO Datenpflege.
Ist die angedachte Wechselschnittstelle denn von der KVB schon fertig entwickelt und ist sie schon irgendwo umgesetzt? Hatte noch nichts gehört. Wenn es nur ein PVS kann bringt es nix, gibt bestimmt eine Frist und dann können es die meisten.
LG C.Schnell
Hallo,
Sie sollten auf Ihre Passwörter auch selbst zugreifen können: das MariaDB Passwort steht nach meiner Erinnerung in der My.ini im MariaDB-Datenbank-Ordner und daneben in den Skripten zur Datenbank Sicherung drin.
Das Passwort für das Dokumentenarchiv steht in der MO Datenpflege.
Ist die angedachte Wechselschnittstelle denn von der KVB schon fertig entwickelt und ist sie schon irgendwo umgesetzt? Hatte noch nichts gehört. Wenn es nur ein PVS kann bringt es nix, gibt bestimmt eine Frist und dann können es die meisten.
LG C.Schnell
Zitat von Johannes Neimann am 18. Januar 2026, 8:54 UhrZu den wirklich wichtigen/ kritischen Themen ist Indamed hier im Forum eher still. Das trübt den Enthusiasmus und verhindert Weiterempfehlungen.
Zu den wirklich wichtigen/ kritischen Themen ist Indamed hier im Forum eher still. Das trübt den Enthusiasmus und verhindert Weiterempfehlungen.
Zitat von Martin Weinreich am 20. Januar 2026, 17:52 UhrHallo,
die AWS wurde von der KV eingestellt:Die AWST scheiterte an der unvollständigen Datenübertragung, hohem technischem Aufwand und Hardware-Anforderungen, weshalb der Softwarewechsel stattdessen oft über den Standard xBDT mit individueller Datenpaketsichtung erfolgt**.Hauptgründe für die Nichtnutzung der AWST:
- Unvollständige Datenübertragung: Sie erfasst oft nicht alle relevanten Patientendaten, wie z.B. Privat- oder Berufsgenossenschaftsfälle.
- Technische Hürden: Die Importzeiten und benötigte Hardware für komplexe Datenmengen sind zu hoch.
- Mangelnde Mehrwerte: Es wurden keine spürbaren Vorteile gegenüber den bestehenden Methoden gesehen.
Alternative und weiterhin genutzte Methode:
- xBDT (elektronischer Datenaustausch): Dieser etablierte Standard ermöglicht eine nahezu vollständige Migration, da die Praxis gemeinsam mit dem Hersteller die Datenpakete sichtet und migriert.
Fazit: Obwohl die AWST technisch eine Idee zur Vereinfachung war, hat sie sich nicht durchgesetzt; der Systemwechsel wird weiterhin meist mit dem bewährten und leistungsfähigeren xBDT-Standard durchgeführt.
Hallo,
die AWS wurde von der KV eingestellt:
- Unvollständige Datenübertragung: Sie erfasst oft nicht alle relevanten Patientendaten, wie z.B. Privat- oder Berufsgenossenschaftsfälle.
- Technische Hürden: Die Importzeiten und benötigte Hardware für komplexe Datenmengen sind zu hoch.
- Mangelnde Mehrwerte: Es wurden keine spürbaren Vorteile gegenüber den bestehenden Methoden gesehen.
- xBDT (elektronischer Datenaustausch): Dieser etablierte Standard ermöglicht eine nahezu vollständige Migration, da die Praxis gemeinsam mit dem Hersteller die Datenpakete sichtet und migriert.
Martin Weinreich
INDAMED Team
Zitat von bro am 21. Januar 2026, 8:38 UhrVielleicht noch ein Satz zu den Passwörtern bitte.
Zitat von Johannes Neimann am 26. August 2025, 18:06 UhrWie ich höre betrachtet Indamed das Kennwort für die MariaDB als deren Eigentum. Daher ergeben sich ein paar Fragen:
Vielleicht noch ein Satz zu den Passwörtern bitte.
Zitat von Johannes Neimann am 26. August 2025, 18:06 UhrWie ich höre betrachtet Indamed das Kennwort für die MariaDB als deren Eigentum. Daher ergeben sich ein paar Fragen:
Zitat von Martin Weinreich am 23. Januar 2026, 16:05 UhrHallo,
wir möchten Sie darüber informieren, dass ein direkter Zugriff auf die zugrunde liegende Datenbank aus Sicherheits-, Datenschutz- und Lizenzgründen nicht vorgesehen und nicht zulässig ist.
Die Datenbankstruktur sowie enthaltene Routinen sind integraler Bestandteil unseres Systems und unterliegen dem Schutz des geistigen Eigentums.Bitte seien Sie versichert, dass Ihnen selbstverständlich alle medizinisch und organisatorisch relevanten Daten über die dafür vorgesehenen Funktionen (z. B. Berichte, Exporte) zur Verfügung stehen.
Gerne unterstützen wir Sie dabei, bestimmte Informationen gezielt zu exportieren – etwa zur Weiterverarbeitung oder Archivierung.Wir danken für Ihr Verständnis und stehen Ihnen bei weiteren Fragen gerne zur Verfügung.
Hallo,
wir möchten Sie darüber informieren, dass ein direkter Zugriff auf die zugrunde liegende Datenbank aus Sicherheits-, Datenschutz- und Lizenzgründen nicht vorgesehen und nicht zulässig ist.
Die Datenbankstruktur sowie enthaltene Routinen sind integraler Bestandteil unseres Systems und unterliegen dem Schutz des geistigen Eigentums.
Bitte seien Sie versichert, dass Ihnen selbstverständlich alle medizinisch und organisatorisch relevanten Daten über die dafür vorgesehenen Funktionen (z. B. Berichte, Exporte) zur Verfügung stehen.
Gerne unterstützen wir Sie dabei, bestimmte Informationen gezielt zu exportieren – etwa zur Weiterverarbeitung oder Archivierung.
Wir danken für Ihr Verständnis und stehen Ihnen bei weiteren Fragen gerne zur Verfügung.
Martin Weinreich
INDAMED Team
Zitat von Johannes Neimann am 23. Januar 2026, 19:53 UhrSehr geehrter Herr Weinreich,
vielen Dank für Ihre Rückmeldung.
Ich möchte zwei Ebenen klar trennen – weil sie in Ihrer Antwort vermischt werden:
1) Datensicherung/ Wiederherstellbarkeit (Backup & Restore)
Ich verlange keinen „freien Bastelzugriff“ auf Ihre Datenbankstruktur, Routinen oder das Schema. Dass Sie Ihr geistiges Eigentum schützen und unkontrollierte Manipulationen vermeiden möchten, ist nachvollziehbar.
Worum es hier geht, ist etwas anderes: ein belastbarer, dokumentierter und praxistauglicher Backup- und Restore-Prozess, der im Notfall eine rasche, vollständige Wiederherstellung ermöglicht (beispielsweise nach Ransomware-Angriff, Hardware-Totalschaden, Datenkorruption). Das ist keine Komfortfrage, sondern Kernanforderung an Praxis-IT.
„Berichte/Exporte“ helfen bei Auswertungen – sie sind aber in der Regel kein Ersatz für ein konsistentes, wiederherstellbares Gesamtsystem-Backup (Datenbank + Archiv/Bilddaten + relevante Metadaten/Beziehungen + Konfigurationen, soweit diese für den Wiederanlauf erforderlich sind). Zudem gilt: Backups, die nie getestet zurückgespielt wurden, sind bestenfalls Hoffnungen.
Vor diesem Hintergrund bitte ich um eine konkrete, offizielle Klarstellung von INDAMED:
(A) Welche von INDAMED offiziell unterstützte Methode ist für MedicalOffice/MariaDB vorgesehen, um einen konsistenten Datenbank-Sicherungsstand zu erzeugen?
– Datenbank-Dump/ physical backup/ PVS-eigene Sicherungsfunktion/ anderes?(B) Wie sieht der von INDAMED vorgesehene Restore-Prozess aus (inkl. Prüfschritten zur Vollständigkeit/Integrität)? Gibt es dafür eine Hersteller-Dokumentation (Mindestanforderung + Best Practices + Test-Restore)?
(C) Wenn ein direktes DB-Login für Kunden „nicht zulässig“ sein soll: Welche Alternative stellt INDAMED bereit, damit die Praxis die Sicherung eigenständig und automatisiert durchführen kann?
Naheliegend wäre z. B. ein offiziell bereitgestellter Backup-Job/ Tooling (intern authentifiziert / minimal berechtigt), der Dumps/Backups erzeugt, ohne dass ein „Master-Passwort“ an Kunden herausgegeben werden muss – und der sich in etablierte Backup-Konzepte integrieren lässt.Damit wäre Ihr Sicherheits-/ Lizenzargument berücksichtigt, ohne die Wiederherstellbarkeit faktisch an „Wohlwollen“ oder Sonderwege zu knüpfen.
2) Datenportabilität/ Systemwechsel (Vendor-Lock-in, Metadaten)
Unabhängig davon gibt es die zweite Ebene: Migration/Wechsel.
Der Gesetzgeber zielt grundsätzlich auf systemneutrale Archivierung und Datenübertragung beim Systemwechsel ab (Archiv- und Wechselschnittstellen). In der Praxis erleben wir aber weiterhin, dass Wechselprozesse häufig nicht „sinnerhaltend“ sind, weil Metadaten/ Beziehungen/ systeminterne Strukturinformationen nicht vollständig übernommen werden. Das hat eine sehr praktische Folge: Für Haftungs-, Nachweis- und Dokumentationszwecke muss oft weiterhin eine lauffähige Kopie des Altsystems vorgehalten werden – mit allen Kosten, Sicherheits- und Betriebsrisiken.
Daher meine Bitte an INDAMED auch hier um eine klare, praxistaugliche Position:
(D) Welche Möglichkeit bietet INDAMED, beim Systemwechsel vollständig zu exportieren – nicht nur „Inhaltsdaten“, sondern auch die für eine rechtssichere Weiterverwendung/ Archivierung erforderlichen Metadaten (so weit technisch möglich)?
(E) Und wie kann eine Praxis diesen Export ohne zusätzliche Kosten und ohne zwingende Mitwirkung des Herstellers/ Systemhauses durchführen (mindestens: standardisiert, dokumentiert, reproduzierbar)?Mir geht es ausdrücklich nicht um „Reverse Engineering“, sondern um zwei legitime Praxisanforderungen:
Resiliente Wiederherstellbarkeit im Notfall, und
Wechselfähigkeit ohne Alt-System-Dauerbetrieb, soweit dies technisch/ standardseitig überhaupt erreichbar ist.
Ich würde mich freuen, wenn INDAMED zu den Punkten (A)–(E) konkret Stellung nimmt – idealerweise mit Verweis auf eine offizielle Dokumentation bzw. einem klaren, unterstützten Vorgehen.
Mit freundlichen Grüßen
Johannes Neimann
Sehr geehrter Herr Weinreich,
vielen Dank für Ihre Rückmeldung.
Ich möchte zwei Ebenen klar trennen – weil sie in Ihrer Antwort vermischt werden:
1) Datensicherung/ Wiederherstellbarkeit (Backup & Restore)
Ich verlange keinen „freien Bastelzugriff“ auf Ihre Datenbankstruktur, Routinen oder das Schema. Dass Sie Ihr geistiges Eigentum schützen und unkontrollierte Manipulationen vermeiden möchten, ist nachvollziehbar.
Worum es hier geht, ist etwas anderes: ein belastbarer, dokumentierter und praxistauglicher Backup- und Restore-Prozess, der im Notfall eine rasche, vollständige Wiederherstellung ermöglicht (beispielsweise nach Ransomware-Angriff, Hardware-Totalschaden, Datenkorruption). Das ist keine Komfortfrage, sondern Kernanforderung an Praxis-IT.
„Berichte/Exporte“ helfen bei Auswertungen – sie sind aber in der Regel kein Ersatz für ein konsistentes, wiederherstellbares Gesamtsystem-Backup (Datenbank + Archiv/Bilddaten + relevante Metadaten/Beziehungen + Konfigurationen, soweit diese für den Wiederanlauf erforderlich sind). Zudem gilt: Backups, die nie getestet zurückgespielt wurden, sind bestenfalls Hoffnungen.
Vor diesem Hintergrund bitte ich um eine konkrete, offizielle Klarstellung von INDAMED:
(A) Welche von INDAMED offiziell unterstützte Methode ist für MedicalOffice/MariaDB vorgesehen, um einen konsistenten Datenbank-Sicherungsstand zu erzeugen?
– Datenbank-Dump/ physical backup/ PVS-eigene Sicherungsfunktion/ anderes?
(B) Wie sieht der von INDAMED vorgesehene Restore-Prozess aus (inkl. Prüfschritten zur Vollständigkeit/Integrität)? Gibt es dafür eine Hersteller-Dokumentation (Mindestanforderung + Best Practices + Test-Restore)?
(C) Wenn ein direktes DB-Login für Kunden „nicht zulässig“ sein soll: Welche Alternative stellt INDAMED bereit, damit die Praxis die Sicherung eigenständig und automatisiert durchführen kann?
Naheliegend wäre z. B. ein offiziell bereitgestellter Backup-Job/ Tooling (intern authentifiziert / minimal berechtigt), der Dumps/Backups erzeugt, ohne dass ein „Master-Passwort“ an Kunden herausgegeben werden muss – und der sich in etablierte Backup-Konzepte integrieren lässt.
Damit wäre Ihr Sicherheits-/ Lizenzargument berücksichtigt, ohne die Wiederherstellbarkeit faktisch an „Wohlwollen“ oder Sonderwege zu knüpfen.
2) Datenportabilität/ Systemwechsel (Vendor-Lock-in, Metadaten)
Unabhängig davon gibt es die zweite Ebene: Migration/Wechsel.
Der Gesetzgeber zielt grundsätzlich auf systemneutrale Archivierung und Datenübertragung beim Systemwechsel ab (Archiv- und Wechselschnittstellen). In der Praxis erleben wir aber weiterhin, dass Wechselprozesse häufig nicht „sinnerhaltend“ sind, weil Metadaten/ Beziehungen/ systeminterne Strukturinformationen nicht vollständig übernommen werden. Das hat eine sehr praktische Folge: Für Haftungs-, Nachweis- und Dokumentationszwecke muss oft weiterhin eine lauffähige Kopie des Altsystems vorgehalten werden – mit allen Kosten, Sicherheits- und Betriebsrisiken.
Daher meine Bitte an INDAMED auch hier um eine klare, praxistaugliche Position:
(D) Welche Möglichkeit bietet INDAMED, beim Systemwechsel vollständig zu exportieren – nicht nur „Inhaltsdaten“, sondern auch die für eine rechtssichere Weiterverwendung/ Archivierung erforderlichen Metadaten (so weit technisch möglich)?
(E) Und wie kann eine Praxis diesen Export ohne zusätzliche Kosten und ohne zwingende Mitwirkung des Herstellers/ Systemhauses durchführen (mindestens: standardisiert, dokumentiert, reproduzierbar)?
Mir geht es ausdrücklich nicht um „Reverse Engineering“, sondern um zwei legitime Praxisanforderungen:
-
Resiliente Wiederherstellbarkeit im Notfall, und
-
Wechselfähigkeit ohne Alt-System-Dauerbetrieb, soweit dies technisch/ standardseitig überhaupt erreichbar ist.
Ich würde mich freuen, wenn INDAMED zu den Punkten (A)–(E) konkret Stellung nimmt – idealerweise mit Verweis auf eine offizielle Dokumentation bzw. einem klaren, unterstützten Vorgehen.
Mit freundlichen Grüßen
Johannes Neimann
Zitat von bro am 23. Januar 2026, 20:06 UhrNaheliegend wäre z. B. ein offiziell bereitgestellter Backup-Job/ Tooling (intern authentifiziert / minimal berechtigt), der Dumps/Backups erzeugt, ohne dass ein „Master-Passwort“ an Kunden herausgegeben werden muss – und der sich in etablierte Backup-Konzepte integrieren lässt.
So ein Backuptool out of the Box mit Null MOA Treffer Ergebnis wäre mein Wunsch.
Naheliegend wäre z. B. ein offiziell bereitgestellter Backup-Job/ Tooling (intern authentifiziert / minimal berechtigt), der Dumps/Backups erzeugt, ohne dass ein „Master-Passwort“ an Kunden herausgegeben werden muss – und der sich in etablierte Backup-Konzepte integrieren lässt.
So ein Backuptool out of the Box mit Null MOA Treffer Ergebnis wäre mein Wunsch.