gelöst – GDT Anbindung Noxturnal (nox medical)
Zitat von Maximilian Kallenbach am 6. September 2026, 23:03 UhrHi,
hat jemand eine Polygraphiegerät von Nox Medical und konnte die Noxturnal-Software erfolgreich via GDT anbinden? Bei mir klappt das leider nicht und der Support von NOX konnte auch noch nicht helfen.
G
M. Kallenbach
Hi,
hat jemand eine Polygraphiegerät von Nox Medical und konnte die Noxturnal-Software erfolgreich via GDT anbinden? Bei mir klappt das leider nicht und der Support von NOX konnte auch noch nicht helfen.
G
M. Kallenbach
Zitat von Maximilian Kallenbach am 11. September 2026, 13:15 UhrKeiner?
Keiner?
Zitat von Peter Quick am 11. September 2026, 16:28 Uhrso ein Gerät hab ich leider nicht. Wenn Sie mal eine GDT Datei posten und hier etwas mehr Details schreiben, also was genau geht nicht, wo hängt es…. Dann könnten wir Ihnen vielleicht etwas helfen
also können Sie das Gerät mit GDT nicht aufrufen? Kriegen Sie keine Imports zurück? Ist es ein falscher Zeichensatz?
so ein Gerät hab ich leider nicht. Wenn Sie mal eine GDT Datei posten und hier etwas mehr Details schreiben, also was genau geht nicht, wo hängt es…. Dann könnten wir Ihnen vielleicht etwas helfen
also können Sie das Gerät mit GDT nicht aufrufen? Kriegen Sie keine Imports zurück? Ist es ein falscher Zeichensatz?
Zitat von Maximilian Kallenbach am 15. September 2026, 8:33 UhrSo sieht mein Auftrag aus:
So dann die erzeugte GDT:
01380006302 014810000163 014921801.00 01030006 0133101Test 0133102Demo 017310301011980 022310648165 Mnster 0223107Marktallee 88 01031101 0158402APNO01und so die Einstellungen in Noxturnal
Und so die erzeugte GDT von Noxturnal
01380006310 014810000387 0158316NOX_T3 014921802.10 01092062 014300024795 0163101Oxxxx 0153102Ixxxx 0173103200119xx 01031102 011362382 0158402APNO01 017620009092026 0156201100003 017843209092026 0158439100003 0180103Noxturnal 0200102Nox Medical 0280132Version 7.2.1.40886 0156302000001 0096304 0126303PDF 0576305P:\Polygraphie Messungen\24795_260909T220003.pdfBeim Import wird leider nichts in die Akte übernommen.
Könnte es am GDT Versions-Unterschied liegen? Ich kann nur 2.0 oder 2.1 bei NOX einstellen, MO arbeitet ja noch mit 1.0
Oder hat jemand eine andere Idee?
So sieht mein Auftrag aus:
So dann die erzeugte GDT:
01380006302
014810000163
014921801.00
01030006
0133101Test
0133102Demo
017310301011980
022310648165 Mnster
0223107Marktallee 88
01031101
0158402APNO01
und so die Einstellungen in Noxturnal
Und so die erzeugte GDT von Noxturnal
01380006310
014810000387
0158316NOX_T3
014921802.10
01092062
014300024795
0163101Oxxxx
0153102Ixxxx
0173103200119xx
01031102
011362382
0158402APNO01
017620009092026
0156201100003
017843209092026
0158439100003
0180103Noxturnal
0200102Nox Medical
0280132Version 7.2.1.40886
0156302000001
0096304
0126303PDF
0576305P:\Polygraphie Messungen\24795_260909T220003.pdf
Beim Import wird leider nichts in die Akte übernommen.
Könnte es am GDT Versions-Unterschied liegen? Ich kann nur 2.0 oder 2.1 bei NOX einstellen, MO arbeitet ja noch mit 1.0
Oder hat jemand eine andere Idee?
Zitat von Leon Rosen am 15. September 2026, 8:48 UhrLiegt nach einer Untersuchung im Ordner C:\nox\gdt die Datei nox2mo.gdt und wartet auf Abholung, oder wird sie abgeholt aber nicht angezeigt?
Liegt nach einer Untersuchung im Ordner C:\nox\gdt die Datei nox2mo.gdt und wartet auf Abholung, oder wird sie abgeholt aber nicht angezeigt?
Zitat von Maximilian Kallenbach am 15. September 2026, 9:12 Uhrabgeholt und nichts angezeigt
abgeholt und nichts angezeigt
Zitat von Peter Quick am 15. September 2026, 9:54 UhrIch habe die gdt-Datei mal durch die KI gejagt, mit der ich auch meine eigenen gdt-Importer geschrieben habe. Das könnte es sein:
Die Datei ist formal (Satzaufbau, Längenbytes) korrekt – aber es fehlt ein Feld, das für Medical Office vermutlich der Grund für den fehlgeschlagenen Import ist.
Was stimmt
Jede Zeile folgt korrekt dem GDT-Schema
LLL(Länge)KKKK(Feldkennung)Wert, und die Längenangabe passt bei jeder Zeile exakt zu3+4+Inhaltslänge+2(für CR/LF) – also genau die Konvention, die auch euer eigenergdt_converter.pyverwendet (length = 9 + len(content_bytes)). Keine verstümmelten oder falsch berechneten Zeilenlängen.Was fehlt: FK 8001 (Satzende)
Ein GDT-Satz wird nach Spezifikation durch FK 8000 (Satzart, hier
6310) geöffnet und durch FK 8001 mit demselben Wert (6310) wieder geschlossen. In dieser Datei taucht FK 8000 auf, aber FK 8001 fehlt komplett – die Datei bricht nach der letzten Zeile (FK 6305, Dateipfad) einfach ab, ohne den Satz zu terminieren.Das ist genau das Muster, das auch euer eigener Konverter (
gdt_converter.py,GDT_FIELDS['RECORD_END'] = 8001) am Ende jeder erzeugten GDT-Datei anhängt – dort ist es also als Pflichtfeld behandelt.Ohne diese Abschlusszeile kann ein GDT-Parser wie der von Medical Office nicht zuverlässig erkennen, wo der Datensatz endet – das erklärt sehr plausibel, warum der Import beim Kollegen fehlschlägt (Datei wird als unvollständig/fehlerhaft zurückgewiesen).
Kurz gesagt: Die Ursache ist wahrscheinlich, dass der exportierende Gerätetreiber (Nox Medical / Noxturnal) die schließende FK 8001 nicht mitschreibt. Der Kollege müsste beim Gerätehersteller/Support nachfragen, ob sich das in der GDT-Exportkonfiguration von Noxturnal aktivieren lässt, oder händisch/per Skript eine Zeile
0136001 6310(Länge je nach genauem Wert) ergänzen, bevor die Datei importiert wird.
Ich würde mal eine Datei manuell nachbearbeiten und die letzte Zeile für den Abschluss der gdt-Datei selbst hinzufügen. Wenn das dann importiert wird, wäre das das Problem.
Ich habe die gdt-Datei mal durch die KI gejagt, mit der ich auch meine eigenen gdt-Importer geschrieben habe. Das könnte es sein:
Die Datei ist formal (Satzaufbau, Längenbytes) korrekt – aber es fehlt ein Feld, das für Medical Office vermutlich der Grund für den fehlgeschlagenen Import ist.
Was stimmt
Jede Zeile folgt korrekt dem GDT-Schema LLL (Länge) KKKK (Feldkennung) Wert, und die Längenangabe passt bei jeder Zeile exakt zu 3+4+Inhaltslänge+2 (für CR/LF) – also genau die Konvention, die auch euer eigener gdt_converter.py verwendet (length = 9 + len(content_bytes)). Keine verstümmelten oder falsch berechneten Zeilenlängen.
Was fehlt: FK 8001 (Satzende)
Ein GDT-Satz wird nach Spezifikation durch FK 8000 (Satzart, hier 6310) geöffnet und durch FK 8001 mit demselben Wert (6310) wieder geschlossen. In dieser Datei taucht FK 8000 auf, aber FK 8001 fehlt komplett – die Datei bricht nach der letzten Zeile (FK 6305, Dateipfad) einfach ab, ohne den Satz zu terminieren.
Das ist genau das Muster, das auch euer eigener Konverter (gdt_converter.py, GDT_FIELDS['RECORD_END'] = 8001) am Ende jeder erzeugten GDT-Datei anhängt – dort ist es also als Pflichtfeld behandelt.
Ohne diese Abschlusszeile kann ein GDT-Parser wie der von Medical Office nicht zuverlässig erkennen, wo der Datensatz endet – das erklärt sehr plausibel, warum der Import beim Kollegen fehlschlägt (Datei wird als unvollständig/fehlerhaft zurückgewiesen).
Kurz gesagt: Die Ursache ist wahrscheinlich, dass der exportierende Gerätetreiber (Nox Medical / Noxturnal) die schließende FK 8001 nicht mitschreibt. Der Kollege müsste beim Gerätehersteller/Support nachfragen, ob sich das in der GDT-Exportkonfiguration von Noxturnal aktivieren lässt, oder händisch/per Skript eine Zeile 0136001 6310 (Länge je nach genauem Wert) ergänzen, bevor die Datei importiert wird.
Ich würde mal eine Datei manuell nachbearbeiten und die letzte Zeile für den Abschluss der gdt-Datei selbst hinzufügen. Wenn das dann importiert wird, wäre das das Problem.
Zitat von Maximilian Kallenbach am 15. September 2026, 9:57 UhrDas probier ich mal, Danke
Das probier ich mal, Danke
Zitat von Maximilian Kallenbach am 15. September 2026, 10:35 Uhr01380006310 014810000387 0158316NOX_T3 014921802.10 01092062 014300024795 0163101Oxxxxxx 0153102Ixxxxx 0173103200119xx 01031102 011362382 0158402APNO01 017620009092026 0156201100003 017843209092026 0158439100003 0180103Noxturnal 0200102Nox Medical 0280132Version 7.2.1.40886 0156302000001 0096304 0126303PDF 0576305P:\Polygraphie Messungen\24795_260909T220003.pdf 01380016310wird so leider auch nicht übernommen
01380006310
014810000387
0158316NOX_T3
014921802.10
01092062
014300024795
0163101Oxxxxxx
0153102Ixxxxx
0173103200119xx
01031102
011362382
0158402APNO01
017620009092026
0156201100003
017843209092026
0158439100003
0180103Noxturnal
0200102Nox Medical
0280132Version 7.2.1.40886
0156302000001
0096304
0126303PDF
0576305P:\Polygraphie Messungen\24795_260909T220003.pdf
01380016310
wird so leider auch nicht übernommen
Zitat von Peter Quick am 15. September 2026, 10:52 UhrWobei, das glaube ich nicht, die ganze Wahrheit ist. Ich habe noch mal ein paar andere GDT-Dateien angeschaut, die bei mir importiert werden und die ich nicht selbst erzeuge. Die haben diese letzte Zeile auch nicht.
Aber gerade die GDT-Dateien mit PDF im Anhang sind nicht einfach. Da es ja auch keine Fehlermeldung gibt und man auch keine Log-Datei sehen kann, ist es schwierig zu sagen, wo der Fehler wirklich ist. Letztlich kann dann nur Indamed das sagen. Ich habe für mich immer erst einmal die GDT-Datei abgespeckt bis auf das absolute Minimum und habe dann langsam aufgebaut, bis es dann irgendwo sichtbar war, welche Zeile stellt das Problem darstellt.
Alternativ mal die GDT-Tools verwenden. findet man im Internet und kann man 30 Tage kostenlos testen.
Wobei, das glaube ich nicht, die ganze Wahrheit ist. Ich habe noch mal ein paar andere GDT-Dateien angeschaut, die bei mir importiert werden und die ich nicht selbst erzeuge. Die haben diese letzte Zeile auch nicht.
Aber gerade die GDT-Dateien mit PDF im Anhang sind nicht einfach. Da es ja auch keine Fehlermeldung gibt und man auch keine Log-Datei sehen kann, ist es schwierig zu sagen, wo der Fehler wirklich ist. Letztlich kann dann nur Indamed das sagen. Ich habe für mich immer erst einmal die GDT-Datei abgespeckt bis auf das absolute Minimum und habe dann langsam aufgebaut, bis es dann irgendwo sichtbar war, welche Zeile stellt das Problem darstellt.
Alternativ mal die GDT-Tools verwenden. findet man im Internet und kann man 30 Tage kostenlos testen.