Archiv- und Wechselschnittstelle, Verschlüsselte Datenbank, Software-Wechsel, Vertragsende
Archiv- und Wechselschnittstelle, Verschlüsselte Datenbank, Software-Wechsel, Vertragsende
Zitat von Tim Brösse am 26. Januar 2026, 12:26 UhrZitat von Martin Weinreich am 23. Januar 2026, 16:05 Uhr[…]
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.
[…]
Naja, kann ich nicht bestätigen. Wenn z.B. im Rahmen einer Plausibilitätsprüfung der KV Alle Krankenblätter eines bestimmten Datumsbereiches angefordert werden, gibt es leider keine Möglichkeit, das automatisiert zu erstellen… Da sitzt dann eine MFA und arbeitet die angeforderten Patienten ab… Exportiert jedes Krankenblatt als PDF. Die Serienbrief-Funktion ist da keine Lösung.
VG.
Zitat von Martin Weinreich am 23. Januar 2026, 16:05 Uhr[…]
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.
[…]
Naja, kann ich nicht bestätigen. Wenn z.B. im Rahmen einer Plausibilitätsprüfung der KV Alle Krankenblätter eines bestimmten Datumsbereiches angefordert werden, gibt es leider keine Möglichkeit, das automatisiert zu erstellen… Da sitzt dann eine MFA und arbeitet die angeforderten Patienten ab… Exportiert jedes Krankenblatt als PDF. Die Serienbrief-Funktion ist da keine Lösung.
VG.
Zitat von Privacy am 26. Januar 2026, 17:00 UhrDie Möglichkeit des LESENDEN Zugriffs auf die Datenbank war ein WESENTLICHES Argument für die Wahl von Indamed. Ich schreibe etliche SQl-Abfragen selbst – neuerdings wurde ja auch ein brauchbares Tools mit GUI dafür mit MO ausgeliefert. Sollte sich dies in Zukunft ändern, kann ich MO nicht mehr empfehlen. Hier in Sachsen habe ich sicher ziemlich zur Verbreitung beigetragen, da ich es der Firma, die die Bereitschaftspraxen der KV betreut, schmackhaft gemacht habe – und damit kennt fast jeder niedergelassene Kollege in Sachsen Medical Office.
Sollten diese auf security by obscurity setzen – dann wird es Zeit sich in der OS-Community zu noch mehr zu engagieren.
Bettina Müller
Die Möglichkeit des LESENDEN Zugriffs auf die Datenbank war ein WESENTLICHES Argument für die Wahl von Indamed. Ich schreibe etliche SQl-Abfragen selbst – neuerdings wurde ja auch ein brauchbares Tools mit GUI dafür mit MO ausgeliefert. Sollte sich dies in Zukunft ändern, kann ich MO nicht mehr empfehlen. Hier in Sachsen habe ich sicher ziemlich zur Verbreitung beigetragen, da ich es der Firma, die die Bereitschaftspraxen der KV betreut, schmackhaft gemacht habe – und damit kennt fast jeder niedergelassene Kollege in Sachsen Medical Office.
Sollten diese auf security by obscurity setzen – dann wird es Zeit sich in der OS-Community zu noch mehr zu engagieren.
Bettina Müller
Zitat von Dubbebub am 27. Januar 2026, 8:19 UhrZitat von Johannes Neimann am 23. Januar 2026, 19:53 UhrVor 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.
An wechseln der PVS denke ich nicht, von daher habe ich diesen Thread eigentlich nur kurz überfliegen wollen. ABER:
Ich verlange auch, dass ich in die Lage versetzt werde, eine saubere Datensicherung zu machen, mit der ich ohne kostspieligen FLS auch selbst in der Lage bin, nach einem Abrauchen meines Servers (wahlweise der ganzen Praxis 😉 ) schnellstmöglich einen neuen Server aufsetzen und weiterarbeiten kann.
Dazu muss doch Indamed einen Masterplan haben. Diesen hätte ich bitteschön auch gerne, wie vom Kollegen Neimann gefordert. Und wenn mir sonst vieles nicht eilt in der Umsetzung: DIESES THEMA SCHON !
Bitte eine zeitnahe Rückmeldung von Indamed ! Das wäre sehr beruhigend !!!
Zitat von Johannes Neimann am 23. Januar 2026, 19:53 UhrVor 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.
An wechseln der PVS denke ich nicht, von daher habe ich diesen Thread eigentlich nur kurz überfliegen wollen. ABER:
Ich verlange auch, dass ich in die Lage versetzt werde, eine saubere Datensicherung zu machen, mit der ich ohne kostspieligen FLS auch selbst in der Lage bin, nach einem Abrauchen meines Servers (wahlweise der ganzen Praxis 😉 ) schnellstmöglich einen neuen Server aufsetzen und weiterarbeiten kann.
Dazu muss doch Indamed einen Masterplan haben. Diesen hätte ich bitteschön auch gerne, wie vom Kollegen Neimann gefordert. Und wenn mir sonst vieles nicht eilt in der Umsetzung: DIESES THEMA SCHON !
Bitte eine zeitnahe Rückmeldung von Indamed ! Das wäre sehr beruhigend !!!
Zitat von Ulrich Fickweiler am 27. Januar 2026, 9:15 UhrWir sichern MO nach Beendigung der laufenden Dienste mit einem normalen Backup-Programm. Das funktioniert problemlos, eine Wiederherstellung auf einem neuen Server hatten wir schon und hat problemlos funktioniert. Sie können auf diese Weise natürlich gleich alle anderen relevanten Praxisdaten sichern. Am Sprechstundenende wird inkrementiell gesichert (1-2 min), dann RDX-Medium entnommen und mitgenommen, dann auf neues Medium komplette Sicherung. Darauf wird am nächsten Tag wieder inkrementiell gesichert, somit hat man immer den aktuellen Datenbestand in der Tasche.
Zusätzlich lassen wir noch ein verschlüsseltes Cloud-Backup laufen.
Da ich kein SQL-Experte bin, lasse ich von Dumps o.ä. lieber die Finger, zumal das letztendlich keine Zeitersparnis bringt.
Wir sichern MO nach Beendigung der laufenden Dienste mit einem normalen Backup-Programm. Das funktioniert problemlos, eine Wiederherstellung auf einem neuen Server hatten wir schon und hat problemlos funktioniert. Sie können auf diese Weise natürlich gleich alle anderen relevanten Praxisdaten sichern. Am Sprechstundenende wird inkrementiell gesichert (1-2 min), dann RDX-Medium entnommen und mitgenommen, dann auf neues Medium komplette Sicherung. Darauf wird am nächsten Tag wieder inkrementiell gesichert, somit hat man immer den aktuellen Datenbestand in der Tasche.
Zusätzlich lassen wir noch ein verschlüsseltes Cloud-Backup laufen.
Da ich kein SQL-Experte bin, lasse ich von Dumps o.ä. lieber die Finger, zumal das letztendlich keine Zeitersparnis bringt.
Zitat von Dubbebub am 27. Januar 2026, 11:19 UhrZitat von Ulrich Fickweiler am 27. Januar 2026, 9:15 UhrWir sichern MO nach Beendigung der laufenden Dienste mit einem normalen Backup-Programm. Das funktioniert problemlos, eine Wiederherstellung auf einem neuen Server hatten wir schon und hat problemlos funktioniert.
Haben Sie schon Maria-DB ?
Zitat von Ulrich Fickweiler am 27. Januar 2026, 9:15 UhrWir sichern MO nach Beendigung der laufenden Dienste mit einem normalen Backup-Programm. Das funktioniert problemlos, eine Wiederherstellung auf einem neuen Server hatten wir schon und hat problemlos funktioniert.
Haben Sie schon Maria-DB ?
Zitat von Ulrich Fickweiler am 27. Januar 2026, 15:34 UhrJa, haben wir.
Ja, haben wir.
Zitat von Marcel Patzer am 28. Januar 2026, 17:33 Uhr
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 NeimannHallo Herr Neimann,
in diesem Wiki-Artikel sollten sie die Antworten zu ihren Fragen finden.
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
Hallo Herr Neimann,
in diesem Wiki-Artikel sollten sie die Antworten zu ihren Fragen finden.
Marcel Patzer
INDAMED Team
Zitat von Johannes Neimann am 28. Januar 2026, 18:30 UhrLeider nicht.
Denn das vorgesehene Standardvorgehen erfordert bei MariaDB den Befehl mysqldump, der aber das Datenbankkennwort benötigt.
Leider nicht.
Denn das vorgesehene Standardvorgehen erfordert bei MariaDB den Befehl mysqldump, der aber das Datenbankkennwort benötigt.
Zitat von Peter Quick am 29. Januar 2026, 12:18 UhrZitat von Dubbebub am 27. Januar 2026, 11:19 UhrZitat von Ulrich Fickweiler am 27. Januar 2026, 9:15 UhrWir sichern MO nach Beendigung der laufenden Dienste mit einem normalen Backup-Programm. Das funktioniert problemlos, eine Wiederherstellung auf einem neuen Server hatten wir schon und hat problemlos funktioniert.
Haben Sie schon Maria-DB ?
Habe auch Maria DB seit längerer Zeit und arbeite genau so. habe erst im Sommer meinen Server selbst ersetzt. Ging so problemlos…
Also kein Dump, sondern Festplatten Backup (kein File, sondern Partition)… Tools hatten wir ja schon mehrfach besprochen
Zitat von Dubbebub am 27. Januar 2026, 11:19 UhrZitat von Ulrich Fickweiler am 27. Januar 2026, 9:15 UhrWir sichern MO nach Beendigung der laufenden Dienste mit einem normalen Backup-Programm. Das funktioniert problemlos, eine Wiederherstellung auf einem neuen Server hatten wir schon und hat problemlos funktioniert.
Haben Sie schon Maria-DB ?
Habe auch Maria DB seit längerer Zeit und arbeite genau so. habe erst im Sommer meinen Server selbst ersetzt. Ging so problemlos…
Also kein Dump, sondern Festplatten Backup (kein File, sondern Partition)… Tools hatten wir ja schon mehrfach besprochen
Zitat von Peter Quick am 29. Januar 2026, 12:22 UhrZitat von Peter Quick am 29. Januar 2026, 12:18 UhrZitat von Dubbebub am 27. Januar 2026, 11:19 UhrZitat von Ulrich Fickweiler am 27. Januar 2026, 9:15 UhrWir sichern MO nach Beendigung der laufenden Dienste mit einem normalen Backup-Programm. Das funktioniert problemlos, eine Wiederherstellung auf einem neuen Server hatten wir schon und hat problemlos funktioniert.
Haben Sie schon Maria-DB ?
Habe auch Maria DB seit längerer Zeit und arbeite genau so. habe erst im Sommer meinen Server selbst ersetzt. Ging so problemlos…
Also kein Dump, sondern Festplatten Backup (kein File, sondern Partition)… Tools hatten wir ja schon mehrfach besprochen
Aber ich gebe allen Vorrednern Recht: Das Einbehalten des Passworts finde ich keinen guten Schritt. Das schafft kein Vertrauen, ganz im Gegenteil. Man kann vieles vertraglich regeln, ich will kein geistiges Eigentum von Indamed stehlen. Aber es sind MEINE Daten. Ich habe diese erhoben und gespeichert. Also habe ich auch ein Recht zum Zugriff auf diese Daten. Falls jemand so bescheuert ist, auf die Datenbank zu schreiben, ohne sich auszukennen, muß er halt mit den Folgen leben. Das nennt sich Eigenverantwortung!
Zitat von Peter Quick am 29. Januar 2026, 12:18 UhrZitat von Dubbebub am 27. Januar 2026, 11:19 UhrZitat von Ulrich Fickweiler am 27. Januar 2026, 9:15 UhrWir sichern MO nach Beendigung der laufenden Dienste mit einem normalen Backup-Programm. Das funktioniert problemlos, eine Wiederherstellung auf einem neuen Server hatten wir schon und hat problemlos funktioniert.
Haben Sie schon Maria-DB ?
Habe auch Maria DB seit längerer Zeit und arbeite genau so. habe erst im Sommer meinen Server selbst ersetzt. Ging so problemlos…
Also kein Dump, sondern Festplatten Backup (kein File, sondern Partition)… Tools hatten wir ja schon mehrfach besprochen
Aber ich gebe allen Vorrednern Recht: Das Einbehalten des Passworts finde ich keinen guten Schritt. Das schafft kein Vertrauen, ganz im Gegenteil. Man kann vieles vertraglich regeln, ich will kein geistiges Eigentum von Indamed stehlen. Aber es sind MEINE Daten. Ich habe diese erhoben und gespeichert. Also habe ich auch ein Recht zum Zugriff auf diese Daten. Falls jemand so bescheuert ist, auf die Datenbank zu schreiben, ohne sich auszukennen, muß er halt mit den Folgen leben. Das nennt sich Eigenverantwortung!