tomedo auf dem Mac

Stand: 12. Oktober 2026. Der Adapter und die verbundenen Import- und Zuordnungswege sind im Quellstand mit synthetischen Daten technisch geprüft. Die Verbindung zwischen tatsächlich bereitgestellter API und installierter Docunara-Laufzeit sowie eine Abnahme mit einer echten tomedo-Installation auf einem Mac sind noch offen. Die folgenden Schritte beschreiben einen Teststand, keine Betriebsfreigabe.

Was der lokale Quellstand abdeckt

Bevorzugt ist eine Patienten-CSV, wenn die Spalten und Geburtsdaten zum vereinbarten Profil passen. Sie kann einen Patienten aus der geöffneten Kartei oder mehrere Zeilen aus einer abgestimmten Statistik enthalten. Jede Datei bildet den Exportzeitpunkt ab; sie wird nicht laufend abgeglichen und zeigt nicht automatisch die gerade geöffnete Kartei. CSV-Prüfung, ausdrückliche Zuordnung und Neuanlage sind im technischen Teststand geprüft. Der Weg ist weiterhin nicht für den Praxisbetrieb freigegeben.

Der im Teststand geprüfte Ablauf übernimmt dieselbe Bedienung wie bei MedicalOffice: das passende PVS-Profil auswählen, über Patientendaten importieren die CSV auswählen, die Dateiprüfung kontrollieren und anschließend Patientenzuordnungen prüfen. Eine Zuordnung wird ausdrücklich bestätigt; gleiche Namen oder Patientennummern lösen keine automatische Zusammenführung aus. Die Prüfung zählt ungültige oder doppelte Zeilen, die beim Import übersprungen wurden.

Wenn noch kein passender Docunara-Patient vorhanden ist, sieht der Teststand die ausdrückliche Aktion Als neuen Patienten anlegen vor. Nach einer unklaren Antwort kann Neuanlage erneut prüfen denselben Anlageversuch klären, solange Sitzung, Praxis und Profil unverändert sind. Diese lokale Zuordnung oder Neuanlage bestätigt keinen nativen tomedo-Export. Der Ablauf steht erst nach Abnahme der tatsächlich installierten Version für den Praxisbetrieb bereit.

Die Herstelleranleitung beschreibt CSV-Export neu in der einzelnen Patientenkartei. Eine Testdatei sollte die Pflichtspalten PatientID, Vorname, Nachname und Geburtsdatum enthalten. Die lokale Zuordnung liest zusätzlich Strasse, PLZ und Ort, wenn sie vorhanden sind. tomedo kann auch Geschlecht exportieren; der lokale Mapper übernimmt dieses Feld derzeit nicht. Die Patienten-ID bleibt Text, sodass führende Nullen erhalten bleiben.

Eine Statistik-Ergebnisliste kann ebenfalls als CSV exportiert werden; sie kann mehrere Patienten enthalten, aber ihre Spalten hängen von der Abfrage und Konfiguration ab. Verwenden Sie sie nur, wenn die tatsächliche Datei dem vereinbarten Profil entspricht. Fehlt eine Pflichtspalte, passt das Profil nicht. Ungültige Geburtsdaten müssen vor der Übernahme geklärt werden. Als Alternative bleibt der ausdrücklich exportierte GDT-Datensatz des Typs 6301 für einen Patienten; er ersetzt keinen Import einer ganzen CSV-Liste.

Der lokale CSV-Vertrag akzeptiert strikt yyyy-MM-dd oder d.M.yyyy für das Geburtsdatum. Das ist eine Docunara-Prüfregel, keine Zusage, dass tomedo standardmäßig eines dieser Formate ausgibt. Prüfen Sie die tatsächliche synthetische Exportdatei mit dem Praxisadmin. Wenn Zeichen unleserlich erscheinen, lassen Sie die Originaldatei und ihre Verarbeitung prüfen, statt Daten zu übernehmen.

Der lokale Adapter kann aus einem bereits vorliegenden Docunara-Auftrag ein GDT-Ergebnis mit einer Referenz auf eine PDF-Datei vorbereiten. Ein nativer tomedo-Import, die Zuordnung in der echten tomedo-Zielkartei und die native PDF-Verarbeitung wurden noch nicht bestätigt. Bis die Berechtigung der installierten Laufzeit und der native Test mit synthetischen Daten belegt sind, steht auch dieser Rückweg nicht für den Praxisbetrieb bereit. Das Verschwinden einer Datei ist keine Importbestätigung.

Die allgemeine Einrichtung und der PVS-Wechsel bleiben der gemeinsame Weg für die Auswahl des PVS. Diese Tomedo-Seite ändert daran nichts.

Einen sicheren Test vorbereiten

Lassen Sie einen tomedo-Administrator eine isolierte Testumgebung und einen synthetischen Patienten verwenden. Für den bevorzugten CSV-Test erzeugt der Admin den dokumentierten Export aus genau dieser geöffneten Patientenkartei und prüft Pflichtspalten, tatsächliche Datumsdarstellung und Kodierung. Eine Statistik-CSV ist wegen ihrer variablen Spaltenkonfiguration kein gleichwertiger Ersatz ohne zusätzliche Abstimmung.

Falls die Praxis stattdessen den einzelnen GDT-Alternativweg prüft, kann der Admin einen Datensatz des Typs 6301 erzeugen und Exportordner, Dateinamen, enthaltene Felder, GDT-Version und Zeichensatz dokumentieren. Die Herstelleroberfläche beschreibt diese Angaben unter Admin → Geräteeinstellungen → GDT. Eine solche Datei allein schaltet den Docunara-Import noch nicht frei.

Der lokale Profilvertrag enthält Quell- und Zielpfade, GDT-Version, Kodierung und Zeichensatzkennzeichen, Sender- und Empfängerkennung sowie das Karteieintragskürzel. Für eine Rückgabe sind außerdem der vereinbarte Archivtyp (GDT-Feld 6302) und ein Empfänger-Referenzstamm nötig, der den Tomedo-Zielpfad auf den lokalen Sicherungspfad abbildet. Der Profilvertrag ist noch keine Zusage, dass diese Einstellungen in der installierten Docunara-Version angeboten oder mit tomedo verbunden sind. Übernehmen Sie keine Werte aus einem MedicalOffice-Profil. Wenn ein Admin die Integration oder die Freigabe nicht belegen kann, stoppen Sie den Test.

Erst wenn die installierte Version den CSV- oder GDT-Import und die Praxisfreigabe bereitstellt, vergleichen Sie die eingelesenen Patientendaten mit dem synthetischen Export: Patienten-ID, Vorname, Nachname und Geburtsdatum müssen übereinstimmen. Bei fehlender ID, abweichenden Pflichtfeldern oder unklarer Kodierung nicht anhand des Namens fortfahren. Bitten Sie den Praxisadmin, Export und Einstellungen im normalen Praxisverfahren zu prüfen. Die technischen Zuordnungstests ersetzen keine Abnahme der installierten Version und der echten tomedo-Daten.

Ergebnis oder PDF zurückgeben

Vor einem Test muss der tomedo-Administrator den nativen GDT-Import mit einem getrennten Rückgabeordner, einem festen Dateinamen und dem vereinbarten Karteieintragstyp einrichten. Das Kürzel für den Karteieintrag (GDT-Feld 8402) muss exakt abgestimmt sein. Der Adapter erzeugt im lokalen Quellstand ein GDT-Ergebnis; der native Import ist erst freigegeben, wenn die installierte Runtime es bereitstellt und der synthetische Test nachweislich im erwarteten Patientendatensatz erscheint.

Eine PDF kann nur über eine GDT-Dateireferenz zurückgegeben werden, wenn sie vor der Übergabe vollständig erzeugt und unter dem vereinbarten lokalen Sicherungspfad abgelegt wurde und tomedo den dazu passenden Empfängerpfad erreichen kann. Die Referenz wird aus diesen abgestimmten Pfaden gebildet; der lokale Adapter prüft, dass sich die Datei während der Übergabe nicht ändert. Ein PDF- oder ID-Mapping für eine konkrete Praxis ist nicht nativ abgenommen. Verwenden Sie keine frei gewählten Pfade und ordnen Sie ein Dokument nicht ersatzweise über den Namen zu.

Wenn der feste Ausgabepfad noch eine unbekannte oder frühere Datei enthält, wird die Ausgabe blockiert. Überschreiben oder löschen Sie die Datei nicht selbst. Der Praxisadmin muss genau Patient, Dokument und Übergabepaket abgleichen. Der Adapter entfernt oder bestätigt das Paket nicht; der zuständige Host-/Praxisprozess gibt den Ausgabepfad erst nach dieser manuellen Klärung wieder frei.

Nach dem Import kontrolliert der Praxisadmin das Ergebnis im tomedo-Datensatz des synthetischen Patienten. Solange diese Kontrolle fehlt, ist die Übergabe lediglich bereitgestellt und nicht bestätigt. Bei einer Unterbrechung oder unklarem Ergebnis nicht blind wiederholen, weil dadurch ein doppelter Karteieintrag entstehen kann.

Verwenden Sie für die Einrichtung nur synthetische Daten. Die Dateien bleiben lokal; laden Sie keine Patientendaten, GDT-Dateien oder PDFs in Supportanfragen oder öffentliche Ablagen.

Weitere Statusinformationen stehen unter Versionen und Freigabestatus und zum Apple-Silicon-Zielbetrieb.