GDT 3.1 Gerätedaten-Träger - QMS€¦ · GDT 3.1 Gerätedaten-Träger Schnittstellenbeschreibung zum systemunabhängigen Datentransfer zwischen Arzt-Informations-Systemen und med

GDT 3.1 Gerätedaten-Träger Schnittstellenbeschreibung zum systemunabhängigen Datentransfer zwischen Arzt-Informations-Systemen und med. Messgeräten

© QMS Qualitätsring Medizinische Software e. V.

Düsseldorf, 2016 Version: 3.1 Stand: 01.12.2016 Freigabe: Freigegeben

GDT- Gerätedatenträger, Version:3.1 Seite 2 von 60 Stand: 01.12.2016

Version 3.1 Datensatzbeschreibung

Autor Ralf Franke (Arbeitskreisleiter GDT)

Editoren Silke Hochheim, Ralf Franke

Beiträge von: QMS Arbeitskreis BDT/GDT/LDT und zusätzliche Beiträge: Arzt & Praxis GmbH, Awinta GmbH, CareFusion GmbH, DGN Deut-sches Gesundheitsnetz Service GmbH, HABEL GmbH & Co. KG, Kassenärztliche Bundesvereinigung, ktberger-consulting, medatixx GmbH & Co. KG, Reinhold Mainz

Status Freigegeben

Freigegeben am / von 01.12.2016 / Qualitätsring Medizinische Software e.V.

Abgestimmt mit Arbeitskreis GDT/BDT des QMS e.V.

Änderungshistorie:

Version Datum Geändert von Änderungsgrund / Beschreibung

3.1 01.12.2016 Ralf Franke Anpassungen eGK, Redaktionelle Überarbeitung

Vorwort

Nur durch die engagierte Vereinsarbeit im Qualitätsring Medizinische Software

e.V., im Folgenden kurz QMS genannt, ist die hier vorliegende GDT-

Datensatzbeschreibung möglich geworden. Jeder, der von den Ergebnissen profitie-

ren möchte, ist daher aufgerufen, mitzuarbeiten und sich ebenfalls an der Konsens-

arbeit zu beteiligen.

Leider sind in der Vergangenheit immer wieder unter dem Deckmantel "GDT-

Schnittstelle" fehlerhafte und nicht zertifizierte Versionen der GDT-Schnittstellen auf-

getaucht, die das Ziel des standardisierten Datentransfers zwischen den Systemen

aufzuweichen drohen und letztlich die Bemühungen des QMS nach Qualitätsstan-

dards unterlaufen.

Wir haben uns deshalb entschlossen, zunächst auf den vereinsinternen schwarzen

Brettern die fehlerhaften Implementationen und deren Herausgeber aufzuführen und

damit zunächst innerhalb des QMS zu outen. Begleitet wird diese Maßnahme durch

ein Anschreiben des QMS-Vorstandes an die verantwortliche Firma, sich dem Stan-

dard zu unterwerfen und die Software anzupassen oder aber den Begriff "GDT-

Schnittstelle" nicht mehr zu verwenden.

Daher: Werden Sie Mitglied, arbeiten Sie mit und lassen sich zertifizieren!!

(www.qms-standards.de)


Inhaltsverzeichnis

1 EINFÜHRUNG 6

1.1 Allgemeines .................................................................................................................................... 6

1.2 Begriffsdefinition ............................................................................................................................ 6

1.3 Kommunikation .............................................................................................................................. 7

1.4 Kennzeichnung der Schnittstellen-Eigenschaften ..................................................................... 8

1.4.1 Allgemeines ............................................................................................................................ 8

1.4.2 Mindestanforderungen für AIS und GERÄT ........................................................................... 8

1.4.3 Kennzeichnung für AIS ........................................................................................................... 8

1.4.4 Kennzeichnung für GERÄT .................................................................................................... 8

1.4.5 Beispiele für mögliche Kombinationen AIS / GERÄT ............................................................. 9

2 SCHNITTSTELLEN-BESCHREIBUNG 9

2.1 Identifikation der Komponenten (GDT-ID) ................................................................................... 9

2.2 Zeichensatz ..................................................................................................................................... 9

2.3 Kommunikation über Datei ........................................................................................................... 9

2.3.1 Dateinamen ............................................................................................................................ 9

2.3.2 Verzeichnis ...........................................................................................................................11

2.4 Kommunikation über serielle Schnittstelle ...............................................................................11

2.4.1 Hardware ..............................................................................................................................11

2.4.2 Ablauf der Kommunikation ...................................................................................................12

2.5 Beispiele zum Ablauf ...................................................................................................................12

2.6 Kommentierte Beispiel-Dateien ..................................................................................................15

2.6.1 Aufbau einer GDT-Zeile: .......................................................................................................15

2.6.2 Beispieldatei: Stammdaten übermitteln SA 6301 .................................................................15

2.6.3 Beispieldatei: Daten einer Untersuchung übermitteln SA 6310 ...........................................16

3 SATZTABELLE 18

3.1 Definition der Satzarten: Stammdaten anfordern „6300“ ........................................................20

3.2 Definition der Satzarten: Stammdaten übermitteln „6301“ ......................................................20

3.3 Definition der Satzarten: Neue Untersuchung anfordern „6302“ ............................................20

3.4 Definition der Satzarten: Angeforderte Untersuchung stornieren „6303“ .............................21


3.5 Definition der Satzarten: Daten einer Untersuchung übermitteln „6310“ ..............................21

3.6 Definition der Satzarten: Daten einer Untersuchung zeigen „6311“ ......................................22

4 FELDTABELLE 23

5 REGELTABELLE 29

6 ANHANG 29

6.1 Anhang A: Blockformat zur seriellen Datenübertragung mit Beispielen ...............................29

6.1.1 Übertragungsprotokoll ..........................................................................................................29

6.1.2 Übertragungsblock ...............................................................................................................29

6.1.3 Bedeutung der einzelnen Felder ..........................................................................................29

6.1.4 Beispiele ...............................................................................................................................31

6.2 Anhang B: Geräte- und verfahrensspezifisches Kennfeld „8402“ ..........................................34

6.3 Anhang C: Übermittlung von Messdaten ...................................................................................40

6.4 Anhang D: Building Blocks / Objekte .........................................................................................44

6.5 Beispieldateien „Best Practice“ .................................................................................................44

6.5.1 Stammdaten anfordern „6300“ (GERÄT an AIS)..................................................................44

6.5.2 Stammdaten übermitteln „6301“ (AIS an GERÄT) ...............................................................45

6.5.3 Neue Untersuchung anfordern „6302“ (AIS an GERÄT) ......................................................45

6.5.4 Angeforderte Untersuchung stornieren „6303“ .....................................................................46

6.5.5 Daten einer Untersuchung übermitteln „6310“ (GERÄT an AIS) .........................................46

6.5.6 Daten einer Untersuchung anzeigen „6311“ (AIS an GERÄT) .............................................47

6.5.7 Terminanforderung „6302“ (AIS an GERÄT) ........................................................................47

6.5.8 Überweisung an Facharzt „6302“ (AIS an GERÄT) .............................................................47

6.5.9 Krankenhauseinweisung „6302“ (AIS an GERÄT) ...............................................................48

6.5.10 Notfalldatensatz übermitteln „6302“ (AIS an GERÄT) ......................................................49

7 DARSTELLUNG DES WORKFLOWS 50

7.1 Basis-Workflow ............................................................................................................................50

7.1.1 Anforderung ..........................................................................................................................50

7.1.2 Anzeige von Ergebnisdaten ..................................................................................................51

7.2 Speicherung von Patientenstammdaten ....................................................................................52

7.2.1 Einfache bzw. direkte Datenübertragung .............................................................................52

7.2.2 Stapelübertragung von Stammdaten ....................................................................................53


7.3 Trivialform GDT-Anforderung .....................................................................................................54

7.3.1 Ergebnis ................................................................................................................................55

7.4 Asynchrone Kommunikation ......................................................................................................55

7.5 Asynchrone Kommunikation in einer Gerätegemeinschaft.....................................................57

7.5.1 Ablauf ....................................................................................................................................57

7.5.2 Erweiterungen des GDT .......................................................................................................58

7.5.3 Erfordernis der Definition von Übertragungswegen .............................................................58

8 ÄNDERUNGEN ZUR VORVERSION 3.0 59


1 Einführung

1.1 Allgemeines

Die vorliegende Schnittstellenbeschreibung wurde vom QMS (Qualitätsring Medizini-

sche Software e.V.) erarbeitet um eine standardisierte Schnittstelle zwischen Arzt-

Informations-Systemen und medizintechnischen Geräten zu definieren.

Die Schnittstelle (Geräte-Daten-Träger - GDT) ist daher neutral verfasst und ist von

allen Marktteilnehmern im Gesundheitswesen verwendbar. Sie kann sowohl von

Standalone-Geräten, wie auch von PC-gestützten Messgeräten realisiert werden.

Sollte eine direkte Kommunikation gemäß dieser Beschreibung technisch nicht reali-

sierbar sein (z.B. ältere Standalone-Geräte mit herstellerspezifischer Schnittstelle),

so sollte vom Gerätehersteller ein geeignetes GDT-Treiberprogramm zur Verfügung

gestellt werden.

Die neue Fassung soll sich zu einem freiwilligen Standard für Hersteller von Arzt-

Informations-Systemen und Herstellern von Medizintechnikgeräten entwickeln. Eine

Zertifizierung findet durch den QMS statt. (Die Schnittstellenbeschreibung wird durch

das Zentralinstitut als Anhang zur BDT-Satzbeschreibung übernommen.)

Zielsetzung für die Weiterentwicklung dieser Schnittstellenbeschreibung ist die Reali-

sierung einer Plug & Play-Fähigkeit zur Anbindung von medizintechnischen Geräten

an Arzt-Informations-Systeme.

Hierdurch wird die Qualität der Anbindungen erhöht und der Installationsaufwand

verringert.

1.2 Begriffsdefinition

Die folgenden Begriffe werden im Rahmen dieser Schnittstellenbeschreibung ver-

wendet:

GDT Geräte-Daten-Träger (Schnittstellen-Bezeichnung in Anlehnung an

BDT, LDT, ADT, KVDT, …)

GERÄT Medizintechnisches Gerät (bzw. zugehöriges Treiberprogramm),

Standalone-Einheit oder PC-gestütztes Messgerät

AIS Arzt-Informations-System

KOMPONENTE Jeder Teilnehmer am Datenaustausch AIS oder GERÄT


SERVER KOMPONENTE, die auf externe Anfragen und Kommandos wartet

und diese bearbeiten kann (Anm.: Auch der Server in einem PC-

Netzwerk reagiert nur auf Anfragen der Workstations)

CLIENT KOMPONENTE, die Anfragen und Kommandos versendet.

Die Bezeichnungen CLIENT / SERVER werden hier ausschließlich zur Beschreibung

des Sende- und Empfangsverhaltens verwendet, sind also unabhängig von AIS und

GERÄT.

Zum Installationszeitpunkt ist für die eingesetzten Komponenten festzulegen, wer als

SERVER und wer als CLIENT arbeitet, um Konflikte zu vermeiden.

Da der eigentliche Sinn einer Geräte-Anbindung in der Übermittlung von Untersu-

chungsdaten liegt, sollte ein AIS mindestens als SERVER (Verarbeiten von Untersu-

chungs-Daten) und ein GERÄT mindestens als CLIENT (Senden von Untersu-

chungs-Daten) arbeiten können (vgl. 1.4).

1.3 Kommunikation

Prinzipiell ist eine Datenkommunikation über drei verschiedene Mechanismen mög-

lich:

Datei-Schnittstelle

Die Kommunikation zwischen GERÄT und AIS erfolgt über Dateien, die in be-

stimmten Verzeichnissen unter bestimmten Namen (s.u.) angelegt werden.

Serielle Schnittstelle

Das angeschlossene GERÄT (bzw. Treiberprogramm) kommuniziert über eine

serielle Schnittstelle mit dem AIS.

Programm-Programm-Schnittstelle

GERÄT und AIS unterstützen Programm-Programm-Schnittstellen (z.B. Clip-

board, DDE, OLE, UNIX-Pipes)

Die vorliegende Version der Schnittstellenbeschreibung beschränkt sich auf die bei-

den Mechanismen: Datei-Schnittstelle und Serielle Schnittstelle.

Eine Erweiterung auf Programm-Programm-Schnittstellen ist geplant.

Da alle Nachrichten in Form von GDT-Sätzen übermittelt werden, ist das verwendete

Datenformat unabhängig vom verwendeten Kommunikationsweg.


1.4 Kennzeichnung der Schnittstellen-Eigenschaften

1.4.1 Allgemeines

Um die technische Beschreibung der Schnittstellenfähigkeit verschiedener

KOMPONENTEN eindeutig festzulegen, wird eine spezielle Kennzeichnung verwen-

det, die für AIS und GERÄT unterschiedlich definiert ist.

Um festzustellen, ob ein bestimmtes AIS mit einem GERÄT kommunizieren kann,

müssen lediglich die Schnittstellen-Kennzeichnungen überprüft werden.

Eine Kommunikation ist dann möglich, wenn mindestens ein Übertragungsweg (seri-

ell oder Datei) und mindestens eine SERVER-/CLIENT-Angabe übereinstimmen.

Die technische Dokumentation eines GDT-fähigen GERÄTES, bzw. AIS muss daher

eine entsprechende Angabe über die Art der realisierten Schnittstelle enthalten.

1.4.2 Mindestanforderungen für AIS und GERÄT

Das AIS sollte mindestens als SERVER arbeiten können, d.h. auf Satzart 6300 mit

Satzart 6301 antworten und die Satzarten 6310 verarbeiten können.

GERÄT sollte mindestens als CLIENT arbeiten, d.h. Satzart 6310 senden können.

1.4.3 Kennzeichnung für AIS

GDT-<xx>-<nn> <xx> = S Serieller Datentransfer gem. GDT wird unterstützt

= D Datentransfer über Dateien gem. GDT wird unterstützt

= SD Beide Verfahren werden unterstützt

<nn> = 10 AIS kann als SERVER arbeiten

= 01 AIS kann als CLIENT arbeiten

= 11 AIS kann als SERVER oder CLIENT arbeiten

Beispiel: GDT-S-10 /

GDT-D-11

AIS kann seriell nur als SERVER,

über Datei aber als SERVER und CLIENT arbeiten

1.4.4 Kennzeichnung für GERÄT

GDT-<xx>-<nn> <xx> = S Serieller Datentransfer gem. GDT wird unterstützt

= D Datentransfer über Dateien gem. GDT wird unterstützt

= SD Beide Verfahren werden unterstützt

<nn> = 01 GERÄT kann als SERVER arbeiten

= 10 GERÄT kann als CLIENT arbeiten

= 11 GERÄT kann als SERVER oder CLIENT arbeiten

Beispiel: GDT-D-10 GERÄT kann nur über Datei als CLIENT arbeiten


1.4.5 Beispiele für mögliche Kombinationen AIS / GERÄT

Folgende Komponenten können z.B. miteinander kommunizieren:

AIS GERÄT

GDT-S-11 GDT-SD-01

GDT-D-10 GDT-D-11

GDT-SD-01 GDT-S-01

Folgende Komponenten können z.B. nicht miteinander kommunizieren:

AIS GERÄT

GDT-S-11 GDT-D-11

GDT-SD-10 GDT-S-01

2 Schnittstellen-Beschreibung

2.1 Identifikation der Komponenten (GDT-ID)

Die GDT-ID dient der eindeutigen Identifikation, der an der Kommunikation beteilig-

ten Komponenten und wird bei der Installation festgelegt.

Die ID besteht aus insgesamt 8 beliebigen Zeichen, die hersteller- und gerätespezi-

fisch vergeben werden. Da die gesamte Nachrichtenzuordnung auf Basis dieser ID

geschieht, ist unbedingt auf eine eindeutige Vergabe zu achten, insbesondere bei

GERÄTEN, die in einem Raum mehrfach vorhanden sind (z.B. EKG-Schreiber des

gleichen Herstellers).

2.2 Zeichensatz

Der innerhalb des GDT erlaubte Zeichensatz wurde, analog zu den Vorgaben aus

der KVDT Datensatzbeschreibung der KBV, mit ISO/IEC 8859-15 festgelegt.

Als Feldinhalt sind grundsätzlich Zeichenfolgen dieses Zeichensatzes zugelassen, die in der Zeichentabelle auf den Plätzen 32 – 127 (dezimal) und 161 – 255 (dezimal) stehen.

2.3 Kommunikation über Datei

2.3.1 Dateinamen

Die Übermittlung von Informationen erfolgt über (Text-)Dateien, deren Datei-Name

bei der Installation eindeutig festzulegen ist.


Für den Aufbau des Dateinamens kann eine der folgenden drei Varianten verwendet

werden:

Variante 1:

<Empfänger-Kürzel>_<Sender-Kürzel>.GDT (z.B. AIS_GER.GDT)

der

Variante 2:

<Empfänger-Kürzel>_<Sender-Kürzel>.<fortlaufende Nr.> (z.B. AIS_GER.005)

oder

Variante 3:

<Empfänger-Kürzel>_<Sender-Kürzel>_<fortlaufende Nr.>.GDT (z.B. AIS_GER_4711.GDT)

Für das Kürzel des Empfängers bzw. des Senders sind max. 4 Zeichen vorgesehen.

Hinweis: Bei entsprechender Kompatibilität des Betriebssystems von Sender und

Empfänger auch länger.

Die Dateinamenserweiterung (bei Variante 2) ist eine 3stellige, fortlaufende Nummer,

die für einen bestimmten Dateinamen vergeben wird. Die Dateizählung beginnt bei

fortlaufender Extension mit .001 (führende Nullen sind zu beachten). Damit ist si-

chergestellt, dass auch mehrere Dateien (z.B. von einem GERÄT) an das AIS ge-

schickt werden können.

Hinweis: Ist abzusehen, dass die drei Stellen der Extension nicht für die fortlaufende

Nummerierung ausreichend sind, so kann diese auch in den Dateinamen eingefügt

werden (siehe Variante3), sofern der Empfänger dieses verarbeiten kann. Manche

Betriebssysteme haben Restriktionen in Bezug auf die Länge der Extension von Da-

teinamen!

Kann von bestimmten Systemen nur ein fester Dateiname konfiguriert werden, so ist

für diese die Extension „GDT“ vorzusehen.

Der verwendete Dateityp (fest oder hochzählend) ist bei Installation gerätespezifisch

festzulegen.

Die Dateien werden vom jeweiligen Sender erzeugt, wobei die Extension entspre-

chend hochgezählt wird. Sollte noch eine Datei mit der Extension „GDT“ vorhanden

sein (Empfänger hat Datei noch nicht gelesen/verarbeitet) darf diese vom Sender

nicht überschrieben werden (Datenverlust).

Die Verarbeitung durch den Empfänger hat sortiert nach Datum/Zeit (FIFO) zu erfol-

gen. Nach dem Lesen sind die Dateien durch den Empfänger zu löschen.

Um Kommunikationsprobleme zu verhindern, sollte der Sender die Kommunikations-

datei ohne Pausen beschreiben. Ist eine Verzögerung erforderlich, muss eine neue

Datei mit fortlaufender Extension generiert werden. Falls die Kommunikationsdatei


eine Dateianlage enthält, sollte diese Datei zunächst mit einem temporären Datei-

namen (z.B. Dateiname ohne Extension) erstellt werden. Erst nach vollständigem

Schreiben wird diese auf den, für den Empfänger konfigurierten, Namen umbenannt.

Hierdurch wird sichergestellt, dass die Kommunikationsdatei erst verarbeitet wird,

nachdem der gesamte Inhalt der Datei geschrieben ist.

Es dürfen auch mehrere Sätze in einer Datei hintereinander vorkommen. In einer

Datei dürfen mehrere unterschiedliche Satzarten auch von verschiedenen Patienten

verwendet werden.

2.3.2 Verzeichnis

Das Laufwerk und Verzeichnis, in dem die Kommunikationsdateien abgelegt werden,

werden zum Installationszeitpunkt festgelegt und sind bei der Geräte-/AIS-

Konfiguration anzugeben.

2.4 Kommunikation über serielle Schnittstelle

2.4.1 Hardware

Die Kommunikation sollte als Mindestanforderung mit einem dreiadrigen seriellen

Kabel (RxD, TxD, GND) ohne Hardware-Handshake möglich sein.

Optional können weitere Schnittstellen-Signale (RTS, CTS, DTR etc.) unterstützt

werden.

Schnittstellen-Parameter (Minimal-Anforderung)

Baudrate = 2400 Baud (optional andere)

Datenbits = 8

Parität = keine

Startbits = 1

Stopbits = 1

Verbindungskabel (Minimal-Anforderung)

(Pin-Belegung für 25 polige Stecker / in Klammern für 9 polige

a) TxD Pin 2 (3) ─────── (2) Pin 3 RxD (Receive Data)

b) RxD Pin 3 (2) ─────── (3) Pin 2 TxD (Transmit Data)

c) GND Pin 7 (5) ─────── (5) Pin 7 GND (Signal Ground)

d) RTS Pin 4 (7) ─┐ ┌─ (7) Pin 4 RTS (Request To Send)

e) CTS Pin 5 (8) ─┘ └─ (8) Pin 5 CTS (Clear To Send)


f) DTR Pin 20 (4) ─┐ ┌─ (4) Pin 20 DTR (Data Terminal Ready)

g) DSR Pin 6 (6) ─┤ ├─ (6) Pin 6 DSR (Data Set Ready)

h) DCD Pin 8 (1) ─┘ └─ (1) Pin 8 DCD (Data Carrier Detect)

Für eine einfache Verbindung sind nur die Leitungen a) + b) + c) erforderlich.

Um nur ein Softwareprotokoll zu verwenden sind zusätzlich jeweils auf beiden Seiten

die Leitungen d) + e) sowie die Leitungen f) + g) + h) zu überbrücken.

Die maximale Kabellänge ist abhängig von der Baudrate die zum Einsatz kommen

soll.

Wichtig:

Die abgebildete Beschreibung ist die „gekreuzte“ Version a) + b)!

Es ist aber je nach Gerätetyp (Schnittstellentyp) auch eine „1:1“ Variante möglich, bei

der Pin 2 des 1. Gerätes auf Pin 2 des 2. Gerätes gelegt wird. Gleiches gilt dann

auch für Pin 3 (kommt aber eher seltener vor). Bitte nehmen Sie zur Klärung der rich-

tigen Polung sicherheitshalber Kontakt zu dem entsprechenden Hersteller auf.

2.4.2 Ablauf der Kommunikation

Als Datenfelder werden die definierten Satz- und Feldkennungen verwendet.

Alle Datenfelder werden dabei in einem festen Blockformat übertragen (vgl. Anhang

A). Da innerhalb des Protokolls ein eigener Software-Handshake definiert ist, kann

auf eine zusätzliche, externe Handshake-Prozedur (XON-XOFF) verzichtet werden.

Um die Kompatibilität zu erhalten, werden die Satz- und Feldlängen der übermittelten

Dateien immer mit CR / LF berechnet (siehe Kapitel 2.6.1). Statt dieser beiden Zei-

chen wird aber lediglich ein Fieldseparator (1Ch) gesendet, da CR als Trennzeichen

für die serielle Übertragung definiert ist (vgl. Beispiele in Anhang A).

2.5 Beispiele zum Ablauf

Die Beispiele basieren auf der folgenden Praxis-Zusammenstellung mit den aufge-

führten Komponenten.

Die Praxis arbeitet mit dem AIS „PRAX_AIS“ (GDT-SD-11) und hat daran drei Geräte

angebunden:

(1) Ein Phoropter (GDT-S-10), der über eine serielle Leitung angeschlossen ist, und

nur auf Tastendruck Untersuchungsdaten an das AIS schicken kann (ohne eige-

ne Stammdatenverwaltung) (AIS ist SERVER / GERÄT ist CLIENT).

(2) Ein PC-gestützter EKG-Schreiber (GDT-D-01), der eine eigene Stammdatenver-

waltung hat, und von der Karteikarte aus aufgerufen wird (AIS ist CLIENT /


GERÄT ist SERVER). Das entsprechende PC-Programm zum Starten des EKG

liegt auf C:\REST_ECG und heißt ECG.BAT.

(3) Ein Lungenfunktions-Messplatz (GDT-D-10), mit eigener Stammdatenverwaltung,

der vom Gerät aus bedient wird und mit dem AIS kommuniziert (AIS ist SERVER /

GERÄT ist CLIENT). Das Spirometrie-Programm heißt D:\LUFU SPIRO.exe.

1. Kommunikation zwischen AIS und Phoropter (keine Möglichkeit zur Stammdatenver-

waltung)

AIS = SERVER GERÄT = CLIENT

Messung am Phoropter wird durchgeführt

Tastendruck am GERÄT sendet Untersuchungsergebnisse als Satzart 6310 über die serielle Leitung

AIS empfängt Daten und ordnet sie dem aktuellen Patienten zu

2. Kommunikation zwischen AIS und EKG-Schreiber

AIS = CLIENT GERÄT = SERVER

Patient für die Untersuchung wird im AIS ausgewählt

AIS schreibt Datei F:\GDT\EKG1AIS1.001 mit Satzart 6302 zur Anforderung einer neuen Untersuchung (Ruhe-EKG: 8402 = EKG01)

Wechsel zur Gerätesoftware durch (Batch-)Aufruf des EKG-Programms aus dem Verzeichnis C:\REST_ECG mit ECG.BAT

GERÄT liest/verarbeitet und löscht Datei F:\GDT\EKG1AIS1.001

Ruhe-EKG für den (an das GERÄT) übergebenen Patienten wird durchgeführt

GERÄT schreibt Datei F:\GDT\AIS1EKG1.001 mit Satzart 6310 zur Übermittlung der Ergebnisse,

Beenden des Programms und damit Wechsel zum AIS

AIS liest und löscht Datei F:\GDT\AIS1EKG1.001 AIS ordnet Daten dem aktuellen Patienten zu


3. Kommunikation zwischen AIS und Lungenfunktions-Messplatz

AIS = Server GERÄT = CLIENT

Patient für die Untersuchung steht im AIS zur Verfügung

Tastendruck am GERÄT fordert Patienten an: GERÄT schreibt Datei F: \ GDT \ AIS_LUFU.001 mit

Satzart 6300 zur Anforderung des aktuellen Patienten

AIS liest/verarbeitet und löscht Datei F: \ GDT \ AIS_LUFU.001 AIS schreibt Datei F: \ GDT \ LUFU_AIS.001 mit

Satzart 6301 zur Übermittlung des aktuellen Stammdatensatzes

GERÄT liest/verarbeitet und löscht Datei F:\GDT\LUFU_AIS.001

Spirometrie für den (vom AIS übergebenen) Patienten wird durchgeführt

GERÄT schreibt Datei F:\GDT\AIS_LUFU.002 mit Satzart 6310 zur Übermittlung der Ergebnisse

Eine weitere Spirometrie für denselben Patienten wird durchgeführt

GERÄT schreibt Datei F:\GDT\AIS_LUFU.003 mit Satzart 6310 zur Übermittlung der Ergebnisse

AIS liest/verarbeitet und löscht Dateien F:\GDT\AIS_LUFU.002 und AIS_LUFU.003

AIS ordnet Daten dem Patienten zu


2.6 Kommentierte Beispiel-Dateien

2.6.1 Aufbau einer GDT-Zeile:

016 3101 Schmidt <CR><LF>

Länge

Kennung

Inhalt

Ende

Länge: 3 Byte 3-stellige natürliche Zahl. „000“ bedeutet Länge nicht angegeben

Kennung: 4 Byte 4-stellige natürliche Zahl. (siehe Feldtabelle)

Inhalt: variabel Darstellbare Zeichen des Code ISO 8859-15.

Ende: 2 Byte Zeichencode 13 dezimal, gefolgt von Zeichencode 10 dezimal

Für die Längenberechnung eines Feldes gilt die Regel: Länge des Feldteils “Inhalt” + 9 (3 Byte + 4 Byte + 2 Byte)

2.6.2 Beispieldatei: Stammdaten übermitteln SA 6301

01380006301 Satzart ”Stammdaten übermitteln”

01680040000332 Satzlänge

0228002Obj_Kopfdaten Start Obj_Kopfdaten

0178315EKG_TYP1 GDT-ID des Empfängers (z.B. EKG-Schreiber)

0178316PRAX_AIS GDT-ID des Senders

013921803.1 Versions-Nr. GDT

0228003Obj_Kopfdaten Ende Obj_Kopfdaten

0208002Obj_Patient Start Obj_Patient

014300002345 Patienten-Nummer

0193101Mustermann Nachname

0143102Franz Vorname

017310319451001 Geburtsdatum

01031101 Geschlecht (1=männlich)

0208003Obj_Patient Ende Obj_Patient

0288002Obj_Basisdiagnostik Ende Obj_Basisdiagnostik


0153622178.00 Größe

0153623079.00 Gewicht


0128006301 Satzende

= CR / LF. Jede Zeile ist mit CR / LF (0D 0A hex) abzuschließen!

2.6.3 Beispieldatei: Daten einer Untersuchung übermitteln SA 6310

01380006310 Satzart

01680040001192 Dateilänge

0228002Obj_Kopfdaten Start Obj_Kopfdaten

0178315PRAX_AIS GDT-ID des Empfängers

0178316LZBD_SYS GDT-ID des Senders

013921803.1 Versions-Nr. GDT

0228003Obj_Kopfdaten Ende Obj_Kopfdaten

0208002Obj_Patient Start Obj_Patient

014300002345 Patienten-Nummer

0193101Mustermann Nachname

0143102Franz Vorname

017310319451001 Geburtsdatum

01031101 Geschlecht (1=männlich)

0208003Obj_Patient Ende Obj_Patient

0288002Obj_Basisdiagnostik Start Obj_Basisdiagnostik

„Obj_Basisdiagnostik“

0153622178.00 Größe

0153632079.00 Gewicht


0258002Obj_Untersuchung Start Obj_Untersuchung

0148402BDM01 Untersuchung: 24h-Blutdruck

017620019981023 Datum der Untersuchung

0346220Diesisteinzweizeiliger Befund 1. Zeile

0416220Befundzur24h-Blutdruckmessung. Befund 2. Zeile

0566227AnmerkungenzueinerLangzeit-Blutdruckmessung. Kommentar

0506228Kurzzusammenfassung24hBlutdruckmessung formatierter Ergebnistext

0596228--------------------------------------------------

0596228TagphaseNachtphaseproz.Abfall

059622806:00-22:0022:00-06:00Tag/Nacht

0596228Ps[mmHg]143134-6%

0596228Pd[mmHg]92920%


0596228HF[P/min]7170-1%

0258003Obj_Untersuchung Ende Obj_Untersuchung

0268002Obj_Laborergebnis Start Obj_Laborergebnis

0168410SYSMXTG Test-Ident (Hersteller-spez.)

0298411SystolemaxTagphase Testbezeichnung

0128420142 Wert

0138421mmHg Einheit

017843223101998 Abnahme-Datum

0158439163400 Abnahme-Zeit

0128462140 oberer Grenzwert

0168410SYSMNTG nächster Test-Ident

0298411SystoleminTagphase Testbezeichnung

0128420112 Wert

0138421mmHg Einheit

017843224101998 Datum dieses Messwertes

0158439031200 Uhrzeit dieses Messwertes

0268003Obj_Laborergebnis Ende Obj_Laborergebnis

01380016310 Satzende

= Leerzeichen (20 hex) bzw. (32 dez)

= CR und LF (0D 0A hex) bzw. (13 10 dez)


3 Satztabelle

Im Folgenden werden die für die Anbindung medizintechnischer Geräte definierten

Satzarten 6300, 6301, 6302, 6303, 6310 und 6311 beschrieben.

Jeder Satz beginnt mit dem Feld „8000“, welches die jeweilige Satzart kennzeichnet.

Lediglich die Satzart 6300 „Stammdaten anfordern“ verlangt als Antwort die Satzart

6301 „Stammdaten übermitteln“.

Die übrigen Satzarten (6301, 6302, 6303, 6310, 6311) können zu beliebigen Zeit-

punkten übermittelt werden und verlangen keine Antwort.

In der Regel gelten folgende Kommunikationsrichtungen:

6300: GERÄT AIS

6301: AIS GERÄT

6302: AIS GERÄT

6303: AIS GERÄT

6310: GERÄT AIS

6311: AIS GERÄT

GERÄT = Medizingerät, AIS = Arzt-Informations-System

Hinweise:

Die in den Satzarten beschriebenen Objekte werden in einem separaten Do-

kument „GDT-Objektkatalog“ gepflegt. In diesem werden Aktualisierungen zu

den Objekten vorgenommen, ohne dass diese Auswirkungen auf die hier vor-

liegende Version der Schnittstelle haben.

Spalte „Vorkommen“:

Die Häufigkeit des Feldes wird in der Spalte „Vorkommen“ angegeben, wobei

die Angabe “n“ diejenigen Felder kennzeichnet, die beliebig oft vorkommen

können. Darüber hinaus wird in der Spalte „Vorkommen“ jedem Feld eine Hie-

rarchiestufe zugewiesen, das heißt das Auftreten des Feldes wird an die Exis-

tenz eines anderen Feldes geknüpft, nämlich genau an jenes Feld, welches in

der übergeordneten Hierarchiestufe referenziert wird.


Folgender beispielhafter Auszug aus einer Satztabelle soll die Struktur eines

Satzes entsprechend den Angaben in der Spalte „Vorkommen“ verdeutlichen:

FK Vorkommen Bezeichnung Vorhandensein Erläuterung

1 2 3 4 der Feldinhalte M/K Bedingung

…

8401 1 Feld 8401 kann nur einmal je Satz vorkommen

…

8410 n Feld 8410 kann beliebig oft je Satz vorkommen

8411 1 Feld 8411 kann nur einmal je Feld 8410 vorkommen

…

8460 n Feld 8460 kann beliebig oft je Feld 8410 vorkommen


3.1 Definition der Satzarten: Stammdaten anfordern „6300“

SA 6300 FK Vorkommen Bezeichnung Vorhandensein Erläuterung

Änd. 1 2 3 4 der Feldinhalte M/K Bedingung

8000 1 Satzidentifikation M Satzart Stammdaten anfordern

8004 1 Satzlänge K Länge dieses Satzes

Kopfdaten xxxx 1 Obj_Kopfdaten M Siehe Anhang D

Patient xxxx 1 Obj_Patient M Siehe Anhang D

Versicher-tenkarte

xxxx 1 Obj_Versichertenkarte K Siehe Anhang D

8001 1 Satzende M 6300

3.2 Definition der Satzarten: Stammdaten übermitteln „6301“



8000 1 Satzidentifikation M Satzart Stammdaten übermitteln




Versicher-tenkarte


Basisdi-agn.

xxxx 1 Obj_Basisdiagnostik K Siehe Anhang D


3.3 Definition der Satzarten: Neue Untersuchung anfordern „6302“



8000 1 Satzidentifikation M Satzart Neue Untersuchung anfordern




Versicher-tenkarte


Anforde-rung

xxxx 1 Obj_Anforderung M Siehe Anhang D

Basisdi-agnose


Dauer-medika-ment

xxxx 1 Obj_Dauermedikament K Siehe Anhang D

Dauerdi-agnose

xxxx 1 Obj_Dauerdiagnose K Siehe Anhang D

Überwei-sung

xxxx 1 Obj_Überweisung K Siehe Anhang D

Diagnose xxxx 1 Obj_Diagnose K Siehe Anhang D

Anhang xxxx 1 Obj_Anhang K Siehe Anhang D

Rg_Emp-fänger

xxxx 1 Obj_Rg_Empfänger K Siehe Anhang D

Arztidenti-fikation

xxxx 1 Obj_Arztidentifikation K Siehe Anhang D



3.4 Definition der Satzarten: Angeforderte Untersuchung stornieren „6303“



8000 1 Satzidentifikation M Satzart Angeforderte Untersuchung stornieren




Versicher-tenkarte


Anforde-rung


Arztidenti-fikation



3.5 Definition der Satzarten: Daten einer Untersuchung übermitteln „6310“



8000 1 Satzidentifikation M Satzart Daten einer Untersuchung übermitteln




Versicher-tenkarte


Basisdi-agnose


Anforde-rung


Untersu-chung

xxxx 1 Obj_Untersuchung K Siehe Anhang D

Anhang xxxx 1 Obj_Anhang K Siehe Anhang D

6330, n Name der freien Kategorie K Gerade und folgende ungerade FK gehören jeweils zusammen.

6332,

6334,

…

6398

6331, 1 Inhalt der freien Kategorie m Falls vorhe-rige FK „Name der freien Kate-gorie“ existiert.

6333,

6335,

…

6399

8405 1 Patienteninformation K

Arztidenti-fikation




3.6 Definition der Satzarten: Daten einer Untersuchung zeigen „6311“



8000 1 Satzidentifikation M Satzart Daten einer Untersuchung zeigen




Versicher-tenkarte


Anforde-rung


Arztidenti-fikation




4 Feldtabelle

Tabelle der in den Sätzen 6300, 6301, 6302, 6303, 6310, 6311 verwendeten Feld-

kennungen.

Änderungen in der Feldtabelle werden links wie folgt gekennzeichnet:

* L Längenänderung

* N Neues Feld, welches in Abstimmung mit dem Zentralinstitut eigens für die

„GDT“ Version vergeben wurde

* R Regeländerung, zur vorherigen Version

Regelnummer für Format-/Inhaltsprüfungen

* Nx.x Neues Feld ab Version x.x

* Obj Verweis auf Objektkatalog. Dort ist die Feldkennung beschrieben.

FK Bezeichnung Länge Typ Regel Beispiel

0102 Softwareverantwortlicher (SV) var a z.B. Firma

0103 Software var a Name der Software

0132 Release-Stand der Software var a 12.4

0201 (N)-BSNR 9 n 947812345

0202 Name des Kostenträgers var a Deutsche Rentenversicherung

0212 LANR 9 n 123456789

0950 Pharmazentralnummer Dauermedi-

kament

var a 4877800

0957 Darreichungsform Dauermedikament var a Filmtablette

3000 Patientennummer / Patientenkennung var a 123456

3100 Namenszusatz / Vorsatzwort des

Patienten

var a Von

3101 Name des Patienten var a Schmitz

3102 Vorname des Patienten var a Erna

3103 Geburtsdatum des Patienten 8 d 021 304

313

19661024

3104 Titel des Patienten var a Dr.

3105 Versichertennummer des Patienten var a 053 776 123456M789

3106 Wohnort des Patienten var a 50859 Köln

3107 Straße des Patienten var a Holzweg 106

3108 Versichertenart MFR 1 n 116 3

3110 Geschlecht des Patienten 1 n 533 1

3112 PLZ des Patienten var a 478 479 50859

3113 Wohnort des Patienten var a Köln



3114 Wohnsitzländercode var a 784 DE

3116 KV-Bereich 2 n 722 531

774

17

3119 Versichertennummer eGK des Pati-

enten

10 a 054 776 A123456780

3618 Mobiltelefonnummer des Patienten var a 0172 9335 172

3619 Email-Adresse des Patienten var a [email protected]

3622 Größe des Patienten in cm var f 175.50

3623 Gewicht des Patienten in kg var f 90.50

3626 Telefonnummer des Patienten var a 0951 3458 200

3628 Muttersprache des Patienten var a Deutsch

3649 Dauerdiagnose ab Datum 8 d 01012012

3650 Dauerdiagnose var a Diabetes mellitus

3651 Dauermedikament ab Datum 8 d 20111112

3652 Dauermedikament var a Adalat

3654 Risikofaktoren var a Raucher

3656 Allergien var a Neurodermitis

3658 Unfälle var a Motoradunfall

3660 Operationen var a Blinddarm

3662 Anamnese var a Frühgeburt

3664 Anzahl Geburten var n 2

3666 Anzahl Kinder var n 3

3668 Anzahl Schwangerschaften var n 4

3670 Dauertherapie var a Schmerzpumpe

3672 Kontrolltermine 8 d 19931201

3673 Dauerdiagnose ICD-Code 3,5,6 a 022 486

489 490

491 492

728 729

735 761

817

E10.21

3674 Diagnosesicherheit Dauerdiagnose 1 a 109 Z

3675 Seitenlokalisation Dauerdiagnose 1 a 110 R

3676 Diagnoseerläuterung Dauerdiagnose var a EKG eindeutig

3677 Diagnoseausnahmetatbestand Dau-

erdiagnose

var a 491 true

3700 Bezeichnung der basisdiagnostischen

Kategorie

var a Kardiovaskuläre Familienbelastung

3701 Inhalt der basisdiagnostischen Kate- var a Ja



gorie

4104 VKNR 5 n 017 201

763 790

27106

4106 Kostenträger-Abrechnungsgebiet 2 n 174 00

4109 Letzter Einlesetag der Versicherten-

karte im Quartal

8 d 480 776

790

20141002

4110 Bis-Datum der Gültigkeit 4 n 315 0913

4111 Krankenkassennummer (KIK) 7 n 202 12568008

4112 Versichertenstatus KVK 4 n 1000

4113 Statusergänzung / DMP-

Kennzeichnung

1 a 1

4121 Gebührenordnung 1 n 106 210 1

4122 Abrechnungsgebiet 2 n 131 00

4200 Terminwunsch var a

4202 Unfall, Unfallfolgen 1 n 142 1

4203 Behandlung gem. § 116b SGB V 1 n

4204 Eingeschränkter Leistungsanspruch

gem. § 18 Abs. 3a SGB V

1 n 142 1

4205 Auftrag var a 744 746

755

4207 Diagnose / Verdachtsdiagnose var a 746 Verdacht auf Hepatitis

4208 Befund / Medikation var a 746

4209 Auftrag / Diagnose / Verdacht var a Röntgen li. Hand

4217 (N)BSNR (Nebenbetriebsstätten-

nummer) des Erstveranlassers

9 n (049)

(061)

319 431

820

123456700

4218 (N)BSNR des Überweisers 9 n (049)

(059)

(061)

328 720

746 821

822

234567800

4219 Überweisung von anderen Ärzten var a 328 Allgemeinmedizin

4220 Überweisung an var a 320 Radiologen

4221 Behandlungstyp 1 n 205 404

754

1

4229 Ausnahmeindikation 5 n 432 32005

4231 Kontrolluntersuchung einer bekann-

ten Infektion

1 n

4237 Krankenhaus-Name var a Uniklinik



4241 LANR (lebenslange Arztnummer) des

Erstveranlassers

9 n 056 762 123456789

4242 LANR des Überweisers 9 n 056 721

762

234567890

6001 ICD Code 3,5,6 a 043 484

486 489

490 491

492 728

729 735

761 817

L50.0

6003 Diagnosesicherheit 1 a 109 484 Z

6004 Seitenlokalisation 1 a 110 R

6006 Diagnoseerläuterung var a Klinisch

6008 Diagnoseausnahmetatbestand var a 491 Zustand nach Geschlechtsumwand-

lung

6200 Tag der Speicherung von Behand-

lungsdaten

8 d 008 19930312

6201 Uhrzeit der Erhebung von Behand-

lungsdaten

6 n 110435

6205 Aktuelle Diagnose var a Diabetes

6206 Pharmazentralnummer (PZN) var a 4877800

6210 Medikament verordnet auf Rezept var a Adalat

6211 Außerhalb Rezept verordnetes Medi-

kament

var a Sostril

6214 Anzahl Packungen (Faktor) 3 n 008

6218 Angabe zu Einnahme var a 1-0-0

6220 Befund var a Erhöhter Blutdruck

6221 Fremdbefund var a Verdacht auf Obstruktion

*N2.1 6226 Anzahl der nachfolgenden Fortset-

zungszeilen der Kennung 6228

var n 2

*N 6227 Kommentar var a Belastung abgebrochen

*N 6228 Ergebnistabellentext formatiert var a s. Beispiele im Anhang

6302 Datei-Archivierungskennung var a 000001

6303 Dateiformat var a PDF

6304 Dateiinhalt var a Datenanalyse

6305 Verweis auf Datei var a \\FS1\DATA\00712.PDF

6329 Inhalt der Datei als BASE64-kodierte

Anlage

var a

*N2.1 6330-

6398

Name der freien Kategorie var a PATINFO



*N2.1 6331-

6399

Inhalt der freien Kategorie var a Patient ist fröhlich

6406 Gebührenfrei 1 n 0=nein, 1=ja

6407 Noctu 1 n 0=nein, 1=ja

6408 BVG 1 n 0=nein, 1=ja

6409 Unfall 1 n 0=nein, 1=ja

6431 Aut Idem 1 n 0=nein, 1=ja

8000 Satzidentifikation 4 a 6301

8004 Satzlänge 7 n 0000747

8002 ObjektIdent var a Bsp.: Obj_Kopfdaten

8003 Objektende var n Enthält die Objektbezeichnung

Bsp.: Obj_Patient

8001 Satzende var n Enthält die Satzart. Bsp.: 6310

8310 Anforderungs-Ident var a 223

8314 Anforderungs-UID var a Gesicherte eindeutige Anforderungs-

ID (UID)

*N 8315 GDT-ID des Empfängers var a ROP200U1

*N 8316 GDT-ID des Senders var a PRAX_AIS

*L 8402 Geräte und verfahrensspezifisches

Kennfeld

var a EKG01, siehe Anhang B

8403 Gebührenordnung 1 n 1

8404 Unterkategorie zur KF 8402 a Niere links

8405 Patienteninformation var a Zusatzinfo: Übergewicht

8407 Geschlecht 1 n 2

8408 Studie-UID Var a ROE23782

8409 Bezeichnung eines Untersuchungs-

gangs

Var a 3456KN_links2Ebenen

8410 Test-Ident Var a FEV1

8411 Testbezeichnung var a Obj. refr. cyl. Rechts

8412 Test-OID var a

8413 Test-Geräte-UID var a

8418 Teststatus 1 a B

8420 Ergebnis-Wert var f -3.70

8421 Einheit var a Dpt

8425 Budget-frei 1 n 1

8428 Probenmaterial-Ident var a SE

8429 Probenmaterial-Index 2 n 01

8430 Probenmaterial-Bezeichnung var a Abstrich



8431 Probenmaterial-Spezifikation var a Linkes Auge

8432 Abnahme-Datum 8 d 008 19940131

8433 Abnahme-Zeit 6 n 091520

*N 8437 Einheit(en) für Datenstrom var a Min, mmHg, mmHg

*N 8438 Datenstrom var a 5,120,80… oder

(5,120,80),(10,128,92)… kann Float-

Werte enthalten.

*N*R 8439 Abnahme-Zeit 6 n 090 125600

8460 Normalwert-Text var a Negativ

*N 8461 Normalwert untere Grenze var f -15.00

*N 8462 Normalwert obere Grenze var f 12.00

8470 Testbezogene Hinweise var a Gefrorenes Serum erforderlich

8480 Ergebnis-Text var a Negativ

8491 Beauftragender/verantwortlicher Arzt var a Dr. med. Mustermann/123456499

8501 Dringlichkeitsstatus 1 n 1 (1=Notfall, 2=eilig)

8504 Medikamenteneinnahme zum Zeit-

punkt der Probenentnahme

var a

8510 Schwangerschaft 1 n 1 (0=nein, 1=ja)

8511 Schwangerschaftsdauer

(in Wochen, Tage)

3 n 242

8512 1. Tag des Zyklus 8 d 20121009

8601 Name des Rechnungsempfängers var a Müller

8602 Titel, Vorname des Rechnungsemp-

fängers

var a Dr. Hans

8606 Wohnort des Rechnungsempfängers var a 50226 Köln

8607 Straße des Rechnungsempfängers var a Ottostr. 1

8608 Kommentar / Aktenzeichen var a 222/234AH

8609 Abrechnungstyp 1 a P

8610 Privattarif 1 n 2

8615 Auftraggeber var a 123456600

8990 Signatur (Namenszeichen) var a Dr. Huber

9103 Datum der Erstellung 8 d 20121020

*N2.1 9152 Zähler URL 4 n 1

*N2.1 9153 Beschreibung URL var a Messkurve für Pat. 00712

*N2.1 9154 URL var a \\FSI\DATA\00712.PDF

*N2.1 9206 Verwendeter Zeichensatz 1 n 2

*N 9218 Version GDT 5 a 03.00


Folgende Feldtypen sind definiert:

d= numerische Datumsangabe im Format JJJJMMTT, wobei

TT = 01-31, MM = 01-12, JJJJ = 0001-9999

n= numerisch; bei festen Feldlängen ist das Feld mit führenden Nullen auf zu fül-

len. Bei variablen Feldlängen dürfen keine führenden Nullen übertragen wer-

den.

a= alphanumerisch

f= Fließkommazahl mit Punkt als Dezimaltrennzeichen

5 Regeltabelle

Die Regeltabellen enthalten alle definierten Regelwerke für die Generierung, Prüfung

und Verarbeitung des GDT.

Hinweis: Die Details zu den in der Feldtabelle angegeben Regeln finden Sie in den

aktuell gültigen Regeltabellen der Kassenärztlichen Bundesvereinigung für die

Schnittstellenfamilie des „xDT“ (Bsp.: ADT, KADT, LDT, BDT).

6 Anhang

6.1 Anhang A: Blockformat zur seriellen Datenübertragung mit Beispielen

6.1.1 Übertragungsprotokoll

Die Datei wird in Blöcken übertragen. Der Empfang eines Übertragungsblocks ist

innerhalb von 10 Sekunden durch Senden eines ACK (06h) gefolgt von einer 1 (31h)

bei vollständigem und richtigem Empfang bzw. einer 0 (30h) bei fehlerhafter Übertra-

gung zu bestätigen.

6.1.2 Übertragungsblock

Ein Übertragungsblock ist folgendermaßen aufgebaut:

<Sende-Sequenz-Zähler><Kennung>[<Datenfeld>]<CRC-16><CR>

6.1.3 Bedeutung der einzelnen Felder

Sende-Sequenz-Zähler

Länge: 1 Byte


Der Sende-Sequenz-Zähler wird zyklisch von 1 (31h) bis 9 (30h) hochgezählt. Falls

der gleiche Übertragungsblock wegen fehlerhafter Übertragung nochmals gesendet

wird, bleibt der Sende-Sequenz-Zähler gleich. Der Wert 0 (30h) dient zur Synchroni-

sation. Er wird bei der ersten Übertragung nach dem Einschalten und nach Auftreten

von Übertragungsfehlern verwendet.

Kennung

Länge: 3 Byte

Es werden folgende Kennungen definiert:

B00 Beginn einer Übertragung / erster Datenblock

B01 Datenblock

B02 Ende einer Übertragung / letzter Datenblock

Datenfeld

Länge: max. 128 Byte

Das Datenfeld enthält die eigentlichen Daten. Mehrere Zeilen können zu einem Da-

tenfeld zusammengefasst werden. Eine Zeile kann auch auf mehrere Datenfelder

verteilt werden. Als Trennung zwischen zwei Zeilen wird das Zeichen 1Ch (Feldsepa-

rator FS) verwendet. Die Satzlänge und die Feldlängen werden dabei inkl. CR / LF

berechnet. Außer dem Feldseparator dürfen innerhalb eines Datenfeldes keine

ASCII-Zeichen kleiner als 20h verwendet werden.

CRC-16

Länge: 4 Byte

16 Bit CRC über Sende-Sequenz-Zähler, Kennung und Datenfeld.

Der Wert wird als ASCII-Hex gesendet. Beispiel 2A9Eh wird als 32h 41h 39h 45h

gesendet.

(Zur Generierung der Checksumme nach CRC-16 verweisen wir auf die Quellcode-

beispiele aus älteren GDT-Datensatzbeschreibungen bzw. auf Quellen aus dem In-

ternet wie beispielsweise „WIKIPEDIA“.)

CR

Länge: 1 Byte

Carriage Return (0Dh) schließt den Übertragungsblock ab.


6.1.4 Beispiele

Hinweis: Das Zeichen ‚|‘ steht für den Feldseparator (1Ch).

Zur Veranschaulichung wurde die Datenfeldlänge auf 32 Zeichen begrenzt.

6.1.4.1 Anforderung von Stammdaten

Client sendet:

C: 1B00 01380006300|01680040000134|0228002Obj_Kopfdaten|0178315QMS-<CRC> <CR>

S: <ACK> 1

C: 2B02 GDT1|0178316ROP200U1|014921803.10|0228003Obj_Kopfdaten|01380016300<CRC> <CR>

S: <ACK> 1

Server antwortet:

S: 7B00 01380006301|01680040000241|0228002Obj_Kopfdaten|0178315ROP<CRC> <CR>

C: <ACK> 1

S: 8B01 200U1|0178316QMS-GDT1|014921803.10|0228003Obj_Kopfdaten|0208002Obj_Pat<CRC> <CR>

C: <ACK> 1

S: 9B01 ient|014300010027|0123101Axt|0143102Berta|017310319650401<CRC> <CR>

C: <ACK> 1

S: 1B02 |01031102|0208003Obj_Patient|013800116301<CRC> <CR>

C: <ACK> 1

6.1.4.2 Verhalten bei Übertragungsfehlern

Bei Empfang von <ACK> 0 bzw. nach Auftreten eines Timeouts wird der letzte Über-

tragungsblock nochmals gesendet. Tritt ein Fehler zum zweiten Mal hintereinander

auf, wird der Sende-Sequenz-Zähler auf 0 gesetzt und die Übertragung vom ersten

Datenblock an wiederholt. Nach dem zweiten erfolglosen Versuch, die Datei zu über-

tragen, bricht der Sender die Übertragung ab. Die Fehlerbehandlung erfolgt in einer

der höheren Schichten.

6.1.4.3 Beispiele für Übertragungen mit Übertragungsfehlern

Wiederholung eines Übertragungsblocks


S: <ACK> 1


S: <ACK> 0 Fehler aufgetreten

Block nochmals senden mit gleichem Sende-Sequenz-Zähler (in diesem Beispiel 2)


S: <ACK> 1 diesmal Block richtig empfangen


Synchronisation nach Übertragungsfehlern


S: <ACK> 1





S: <ACK> 0 Fehler erneut aufgetreten


neue Synchronisation mit

Sequenzzähler 0

S: <ACK> 1


S: <ACK> 1

Abbruch einer Übertragung nach Übertragungsfehlern


S: <ACK> 1







neue Synchronisation mit

Sequenzzähler 0

S: <ACK> 1





Sender bricht Übertragung ab. Empfänger bleibt empfangsbereit.


Übertragungsfehler bei Stammdatenanforderung

Das Problem, dass sowohl Client als auch Server versuchen, eine Datei zu senden,

kann z.B. folgendermaßen entstehen:


S: <ACK> 1


S: [<ACK> 1]

Empfangsbestätigung vom Server zwar geschickt, kommt aber nicht beim Client an


erneutes Senden des gleichen Blocks

S: 7B00 01380006301|01680040000241|<CRC> <CR> Server sendet bereits den 1. Block

der angeforderten Stammdaten


erneutes Senden durch Client mit

neuer Synchronisation

S: 7B00 01380006301|01680040000241|<CRC> <CR> Server wiederholt den 1. Block der

Stammdaten (ACK 1 vom Client fehlt)


Client wiederholt den Synchronisations-

versuch

S: 0B00 01380006301|0168004000217|<CRC> <CR> erneutes Senden durch Server mit neuer

Synchronisation

S: 0B00 01380006301|01680040000217|<CRC> <CR> Server wiederholt den Synchronisations-

versuch

Die Übertragung wird nach Timeout (”warten auf ACK”) von Server und Client abge-

brochen

(vgl. 6.1.4.2).


6.2 Anhang B: Geräte- und verfahrensspezifisches Kennfeld „8402“

Das Feld 8402 wurde im Rahmen der Überarbeitung des GDT wie folgt neu definiert:

Feldkennung: 8402

Bezeichnung: Geräte- und verfahrensspezifisches Kennfeld

Funktion: Das Feld dient zur Gruppierung der zu übermittelnden Daten.

Typ: Der bisherige Typ von 2 (alnum) wurde auf 1-6 (alnum) erweitert.

Regel: Der Feldinhalt besteht aus einem Textteil mit maximal 4 Buchsta-

ben als Gruppenkennung, sowie einer anschließenden 2-stelligen

Nummerierung von 00 bis 99 (z.B. LUFU09). Die Nummer 00 ist

dabei grundsätzlich als Kennung für nicht näher spezifizierte Un-

tersuchungen der jeweiligen Gruppe reserviert. Die Gruppenken-

nung ALLG (i.d.R. ALLG00) wird für nicht näher einzuordnende

Untersuchungen festgelegt.

Die Liste der Feldinhalte ist dynamisch und wird zentral vom ZI verwaltet. Die nach-

folgend aufgeführten Gruppen und Feldinhalte sind daher nur als eine erste Zusam-

menstellung zu betrachten, die beliebig erweiterbar ist.

Im Gegensatz zur Kennung 8402 können die jeweiligen Testidents (Kennung 8410)

herstellerspezifisch vergeben werden (vgl. Anhang C des GDT).

ALLE__ Allergologie

ALLE01 Anamneseerfassung allergologisch

ALLE02 Befunderfassung allergologisch

ALLE03 Diagnoseerfassung allergologisch

ALLE04 Pricktest

ALLE05 Intracutantest

ALLE06 Provokationstest

ALLE07 Invitrotest

ALLE08 Insektengift

ALLE09 Epikutantest

ALLE10 Tägliche Hyposensibilisierungsbehandlung


ALLG__ Untersuchungen, allgemein

ALLG00 Nicht näher spezifizierte Untersuchungen

APNO__ Schlaf-Apnoe-Untersuchungen

APNO00 Apnoe, allgemein

APNO01 Langzeit Schlafapnoe Screening

APNO02 Polysomnografie

AUDI__ Audiometrische Untersuchungen

AUDI00 Audiometrie, allgemein

AUDI01 Reinton-Schwellen-Audiogramm

AUDI02 EEG-Audiometrie

BDM__ Blutdruckmessung

BDM00 Blutdruckmessung, allgemein

BDM01 Langzeit-Blutdruckmessung

CTG__

Kardiotokographie

CTG01 Kardiotokographie

DERM__ Dermatologie

DERM01 Derma-Kamera (Serie)

DICO__ Dicom

DICO01 CT

DICO02 MRT

EKG__ Elektrokardiographie

EKG00 EKG, allgemein

EKG01 Ruhe-EKG

EKG02 Arrhythmie-EKG


EKG03 Spätpotential-EKG

EKG04 Langzeit-EKG

ERGO__ Belastungs-Untersuchungen

ERGO00 Belastungs-Untersuchungen, allgemein

ERGO01 Belastungs-EKG

ERGO02 Fluss-Volumen unter Belastung

ERGO03 Blutgase

ERGO04 Blutgase unter Belastung

ERGO05 Sprioergometrie

ERGO06 Atemgasanalyse

ERGO07 Pulsoximetrie

ERGO08 Indirekte Kalorimetrie

ERGO09 Indirekte Kalorimetrie mit Haube

ERGO10 HZV-Bestimmung über CO2-Rückatmung

ERGO11 Atemantriebsmessung über CO2-Rückatmung

FILE__ File Datenübergabe

FILE01 Kamera (Video/Digital) allgemein über Daten-

schnittstelle

HÄMA__ Blutbilder

HÄMA01 Kleines Blutbild

HÄMA02 Großes Blutbild

HÄMA03 Manuelles Differentialblutbild

HÄMA04 Retikulozyten

HÄMA05 CD4/CD8

LUFU__ Lungenfunktions-Messung

LUFU00 Lungenfunktion, allgemein

LUFU01 Langsame Spirometrie

LUFU02 Forcierte Spirometrie (Fluss-Volumen)


LUFU03 MVV (Maximal Voluntary Ventilation)

LUFU04 Bodyplethysmographie

LUFU05 FRC pl (Lungenvolumen – Bodyplethysmograpie)

LUFU06 FRC He (Lungenvolumen – Helium Rückatmung)

LUFU07 Resistance nach Verschlussdruckmethode

LUFU08 Resistance nach Impulsoscillation-Methode

LUFU09 Resistance nach Oszilloresistometrie-Methode

LUFU10 Compliance

LUFU11 Atemmuskulaturstärke-Messung

LUFU12 Atemantrieb-Messung

LUFU13 Diffusion Single-Breath

LUFU14 Diffusion Steady-State

LUFU15 Diffusion Rebreathing

LUFU16 Diffusion Membranfaktor

LUFU17 Capnographie

LUFU18 Rhinomanometrie

LUFU19 Ruheatemanalyse

NEUR__ Neurologische Messung

NEUR00 Neurologie, allgemein

NEUR01 Langzeit-EEG

NEUR02 EEG mit simultaner EKG-Aufzeichnung

NEUR03 Motorisches NLG

NEUR04 Sensorisches NLG

NEUR05 Evozierte Potentiale

NEUR06 Rotationstest

NEUR07 Nystagmusanalyse

NEUR08 Sakkadentest

NEUR09 Posture

NEUR10 Biofeedback

NEUR11 ERG/EOG


NEUR12 EMG der Augenmuskeln

NULL__ Leer Device

NULL01 Leer-Device nur um Patientenstammdaten an die

Datenbank zu senden

OPTO__ Augenheilkunde

OPTO00 Augenheilkunde, allgemein

OPTO01 Refraktionsbestimmung, objektiv

OPTO02 Refraktionsbestimmung, subjektiv

OPTO03 Refraktionswerte Brille/Kontaktlinse

OPTO04 Blendenempfindlichkeitsmessung (Visus)

OPTO05 Gesichtsfeldmessung

OPTO06 Augendruckmessung

OPTO07 Hornhautmessung (Krümmungsradi-

en/Achslagen)

OPTO08 Hornhautmessung (3D-Geometriedaten)

OPTO09 Fundusbilder

OPTO10 Angiographiebilder

OPTO11 Spaltlampenbilder

OPTO12 Topograpiebilder

OPTO13 Schichtbilder

OPTO14 Generische Bilddaten

PROV__ Provokations-Test

PROV00 Provokation, allgemein

PROV01 Spezifische Aerosol-Provokation

PROV02 Unspezifische Aerosol-Provokation

PROV03 Kaltluft Provokation

PROV04 Bronchodilatation


SCAN__ Scanner

SCAN01 Scanner allgemein nach TWAIN Standard

SONO__ Sonographie-Messungen

SONO00 Sonographie, allgemein

SONO01 Ultraschall-Doppler

URO__ Urologie

URO00 Urologie, allgemein

URO01 Uroflowmetrie

VDDS__ VDDS Dentalschnittstelle

VDDS01 Dental Röntgensystem nach VDDS Schnittstelle

VIDE__ Videoaufnahmen

VIDE01 Sonographie

VIDE02 Angiographie

VIDE03 Endoskopie

VIDE04 Laparaskopie

VIDE05 Arthroskopie

VIDE06 Mikroskopie

VIDE20 C-Bogen

XRAY__ Röntgenbild

XRAY01 Röntgenbild


6.3 Anhang C: Übermittlung von Messdaten

Messdaten können verschiedene Dimensionalität besitzen. Der einfachste Fall ist der

einfache Messpunkt, eine eindimensionale für sich alleine wichtige Zahl.

0 Messwert

Dieser Fall einer oder mehrerer eindimensionaler Zahlen wird im GDT durch die Se-

quenz

8410 Test-Ident

…

8420 Messwert

dargestellt.

Ein Beispiel (Körpergröße zu einem bestimmten Zeitpunkt):

8410 Größe

…

8420 184

Oft interessiert jedoch die Entwicklung von Messgrößen z.B. gegenüber der Zeit in

äquidistanten Abständen.

Zeit [Monate]

Dieser Fall lässt sich einfach und effektiv mit der Sequenz

8410 Test-Ident

…

8417 Datenstrom (als Einzelwerte)

darstellen.

Ein Beispiel (Körpergröße über einen gewissen Zeitraum):

8410 Größe

…

8417 184,185,187,190,190

Größe

[cm]


Sind die Messwerte nicht äquidistant, so muss zusätzlich die zweite Dimension direkt

angegeben werden:

8410 Test-Ident

…

8417 Datenstrom (als Pärchen)

Wieder am Beispiel (Körpergröße und Monate seit Messbeginn):

8410 Größe

…

8417 (184,0),(186,2),(188,7),(190,20)

Auch die Darstellung von mehreren Messgrößen ist möglich, da die Sequenz

8410

…

8417

n-mal vorkommen darf.

Wieder am Beispiel (zusätzlich die Entwicklung des Gewichtes neben der Größe):

a) Bei äquidistanten Messwerten (Größe und Gewicht wurden zusammen in glei-

chen Zeitabständen gemessen):

8410 Größe

…

8417 (184,65),(186,65),(188,69),(190,72)

b) Wurde dagegen zu verschiedenen Zeitpunkten die Messwerte einzeln gemessen,

d.h. bei jedem Messwert ist zusätzlich eine Zeitangabe erhalten, so ergibt sich

folgende Sequenz:

8410 Größe

…

8417 (184,0),(186,2),(188,7),(190,20)

…

8410 Gewicht

…

8417 (65,0),(66,4),(69,7),(72,20)


Erweiterung des GDT gegenüber der Version 1.0

Was jedoch, wenn Messwerte mehrere Proben (oder zu verschiedenen Zeitpunkten

erhobene) einfach übertragen werden und z.B. von dem Auswertungsprogramm ver-

gleichend dargestellt werden sollen? Bisher gab es hierzu im GDT keine direkte

Möglichkeit.

Messwert Probe 1

Probe 2

Zeit

Hierzu wird, als neue Hierarchieebene, die Probe und der Zeitpunkt der Messung

definiert:

3000 Patientendaten

…

8402 Messgerät

…

8405 Probe

…

8406 Datum

8407 Uhrzeit

…

8410 Test-Ident

…

8420 Messwerte

…

oder 8417 mehrere Messwerte

Durch die zusätzliche Einführung der Zeit als Hierarchieebene lassen sich Zeitreihen

einfacher und klarer (als wie bisher durch mehrdimensionale Tupel im Feld 8417)

übertragen. Die Möglichkeit, die Zeit als selbständige Dimension im Feld 8417 zu

übertragen, ist hierdurch jedoch nicht genommen.


Man erhält folgende Datensatzdarstellung:

Satzart 6310

Vorkommen

1 2 3 4

3000 Patientennummer 1

…

8402 Gerät 1

…

6205 - 6228 Erklärung 1

8405 Probe n

…

8406 Zeitpunkt Datum 1

8407 Zeitpunkt Uhrzeit 1

8410 Test-Ident n

…

8420 Messwert (alternativ) 1

Diese Darstellung erlaubt, alle erforderlichen Messdaten direkt abzubilden. Sie ist

abwärtskompatibel zur GDT Version 1.0! Sind die Felder 8405 (Probe) und 8406

(Datum) nur einmal vorhanden oder fehlen ganz, so unterscheidet sich der Daten-

satzaufbau nicht von der Abbildung der Daten, wie sie in der GDT Version 1.0 defi-

niert wurde.


6.4 Anhang D: Building Blocks / Objekte

Anbei die Liste der Objekte, die in dieser Datensatzbeschreibung verwendet werden.

Eine detaillierte Beschreibung dieser Objekte (Zusammensetzung der Feldkennun-

gen, Regeln für Vorkommen, Bezeichnung, …) finden Sie in dem Dokument „Ob-

jektkatalog als Ergänzung zu den xDT-Datensatzbeschreibungen“.

Obj_Anforderung Obj_Diagnose Obj_Schein

Obj_Anhang Obj_Einweisung Obj_Terminanfrage

Obj_Arztidentifikation Obj_Kopfdaten Obj_Ueberweisung

Obj_Basisdiagnostik Obj_Patient Obj_Untersuchung

Obj_Dauerdiagnose Obj_RgEmpfänger Obj_Versichertenkarte

Obj_Dauermedikament Obj_Satzende

6.5 Beispieldateien „Best Practice“

Folgende Beispieldateien zeigen in der täglichen Praxis häufig vorkommende Vor-

gänge mit den erforderlichen Feldkennungen und Satzarten:

Legende: GERÄT = Medizinisches Gerät, AIS = Arzt-Informations-System

6.5.1 Stammdaten anfordern „6300“ (GERÄT an AIS)

Aufbau Satzart 6300 Kommentar

Stammdaten anfordern (6300) ist ein Vorgang des medizinischen Gerätes (GERÄT) an das Arzt-Informations-System (AIS). Im Objekt Obj_Patient kann über 3119 alternativ zur Patienten-nummer eine Identifikation erfolgen. Andernfalls werden die Daten des aktu-ellen Patienten angefordert.

1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Satzende

Vorgang: GERÄT an AIS. Beispiel wie bisher


6.5.2 Stammdaten übermitteln „6301“ (AIS an GERÄT)


Beispiel für die minimale Stammdaten-übermittlung; grundsätzlich sollte bei allen Vorgängen des AIS zum GERÄT das Objekt Obj_ArztIdent übertragen werden.

1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_ArztIdent

4. Obj_Satzende

Vorgang: AIS an GERÄT. Beispiel mit Arztidentifika-tion

6.5.3 Neue Untersuchung anfordern „6302“ (AIS an GERÄT)

Beispiel 1:


Minimalversion. Anforderung einer Un-tersuchung mit Arztidentifikation und Anforderungsidentifikation. 1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Anforderung

4. Obj_ArztIdent

5. Obj_Satzende

Vorgang: AIS an GERÄT. hier mit Arztidentifikation

Beispiel 2:


Anforderung einer Untersuchung mit Daten der Versichertenkarte und aus-führlichen medizinischen Dauerinforma-tionen sowie der Basisdiagnostik

1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Versichertenkarte

4. Obj_Anforderung

5. Obj_Basisdiagnostik

6. Obj_DauerDiag

7. Obj_DauerMed



8. Obj_ArztIdent

9. Obj_Satzende

Vorgang: AIS an GERÄT. Zusätzlich zu den Muss-Objekten Obj_Kopfdaten und Obj_Patient werden Obj_Versichertenkarte, Obj_Basisdiagnostik, Obj_DauerMed, und Obj_DauerDiag übertragen. Das medizinische Gerät mit den medizinischen Dau-erinformationen, der Basisdiagnostik und den Versi-cherungsdaten initialisiert.

6.5.4 Angeforderte Untersuchung stornieren „6303“


Minimalversion. Anforderung einer Un-tersuchung stornieren mit Arztidentifika-tion und Anforderungsidentifikation. 1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Anforderung

4. Obj_ArztIdent

5. Obj_Satzende

Vorgang: AIS an GERÄT. hier mit Arztidentifikation

6.5.5 Daten einer Untersuchung übermitteln „6310“ (GERÄT an AIS)


1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Untersuchung

4. Obj_Anhang

5. Obj_Satzende

Vorgang: GERÄT an AIS


6.5.6 Daten einer Untersuchung anzeigen „6311“ (AIS an GERÄT)


1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Anforderung

4. Obj_ArztIdent

5. Obj_Satzende

Vorgang: AIS an GERÄT. In der Spezifikation steht 4111, wird aber im Beispiel nicht aufgeführt.

6.5.7 Terminanforderung „6302“ (AIS an GERÄT)


Bei der Terminanforderung müssen im Objekt Obj_Patient die Felder SMS und Emailadresse des Patienten belegt sein, da die Rückbestätigung des Termins an den Patienten gerichtet ist. In dem Ob-jekt Obj_Terminanfrage ist die Ver-dachtsdiagnose bzw. die Fragestellung für die, angefragte Facharztpraxis für den weiteren Arbeitslauf in der Zielpra-xis besonders wichtig.

1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Anforderung

4. Obj_Terminanfrage

5. Obj_ArztIdent

6. Obj_Satzende

Vorgang: AIS an GERÄT; SMS-Telefonnummer oder Emailadresse des Patienten sind im Objekt Obj_Patient zu übertragen.

6.5.8 Überweisung an Facharzt „6302“ (AIS an GERÄT)


Mit dem Vorgang Überweisung an Facharzt wird eine Terminanfrage mit ausführlichen medizinischen Dauerin-formationen und Basisdiagnostik initiali-siert. Das Objekt Obj_Untersuchung kann hier zur Bereitstellung von Vorbe-funden genutzt werden. Im Objekt Obj_Anhang können zum Beispiel die Einwilligungserklärung des Patienten

1. Obj_Kopfdaten

2. Obj_Patient


4. Obj_Anforderung




6. Obj_Basisdiagnostik und Vorbefunde (Fremdbefunde) über-tragen werden.

7. Obj_Einweisung

8. Obj_DauerMed

9. Obj_DauerDiag

10. Obj_Anhang

11. Obj_Untersuchung

12. Obj_ArztIdent

13. Obj_Satzende


6.5.9 Krankenhauseinweisung „6302“ (AIS an GERÄT)


Mit dem Vorgang Krankenhauseinwei-sung wird eine Terminanfrage mit aus-führlichen medizinischen Dauerinforma-tionen und Basisdiagnostik initialisiert. Das Objekt Obj_Untersuchung kann hier zur Bereitstellung von Vorbefunden genutzt werden. Im Objekt Obj_Anhang können zum Beispiel die Einwilligungs-erklärung des Patienten und Vorbefunde (Fremdbefunde) übertragen werden.

1. Obj_Kopfdaten

2. Obj_Patient


4. Obj_Anforderung



7. Obj_Einweisung

8. Obj_DauerMed

9. Obj_DauerDiag

10. Obj_Anhang

11. Obj_Untersuchung

12. Obj_ArztIdent

13. Obj_Satzende



6.5.10 Notfalldatensatz übermitteln „6302“ (AIS an GERÄT)


Im Bereich der Notdienstpraxen ist eine Bereitstellung von medizinischen Dauer-informationen und der Basisdiagnostik gefordert. Auch kann damit der allge-mein geforderte Notfalldatensatz initiali-siert werden.

1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Anforderung


5. Obj_DauerMed

6. Obj_DauerDiag

7. Obj_ArztIdent

8. Obj_Satzende

Vorgang: AIS an GERÄT.


7 Darstellung des Workflows

Die GDT-Schnittstelle wurde entworfen, um AIS mit medizinischen Geräten (GERÄT)

aller Art kommunizieren zu lassen. Dabei übergibt das AIS ausgewählte Stammdaten

und ggf. medizinische Informationen von Patienten an ein medizinisches Untersu-

chungs- oder Therapiegerät. Dem Konzept der GDT-Schnittstelle liegt ein Basis-

Workflow zugrunde.

In der Realität kommen aber weitere Workflows vor, die im Folgenden dargestellt

werden.

7.1 Basis-Workflow

7.1.1 Anforderung

AIS

o Anwahl Patient

o (optional) Auswahl Patient

o (optional) Auswahl Verfahren

o (optional) Textzusätze

o Erstellung einer Anforderung gem. Satzart 6302

Speichern als Datei

Senden über V.24 / RS232-Schnittstelle oder

Schreiben in eine Datei gem. Namenskonvention des GDT

Warten auf Ergebnis


GERÄT

o Warten auf Anforderung vom AIS

o Wertet Anforderungsdaten aus und startet die gewählte Prozedur

o Bearbeitungs- bzw. Auswertezeit des GERÄT

o Erstellen eines Ergebnisses bzw. Fertigmeldung mit Satzart 6310



Beenden des Arbeitsbetriebes

AIS

o Ergebnisdaten empfangen und speichern

7.1.2 Anzeige von Ergebnisdaten

AIS

o Auswahl Patient und Untersuchung


Speichern als Datei



(optional) Warten auf ein Ende der Arbeit mit dem GERÄT

GERÄT

o Anwahl Patient und Untersuchungs- / Behandlungsdaten


o Betrachtung der Ergebnisse bzw. weitere interaktive Arbeit mit dem existie-

renden Datenmaterial

o Beenden der Auswertung

7.2 Speicherung von Patientenstammdaten

Zum Zweck der Synchronisation von Datenbeständen ist eine Satzart 6301 definiert

worden. Dabei sollen sämtliche Stammdaten des AIS (neue oder geänderte) an das

GERÄT übergeben werden.

7.2.1 Einfache bzw. direkte Datenübertragung

Das GERÄT muss dazu in dem Zustand sein, Stammdaten direkt zu empfangen bzw.

zu verarbeiten.

AIS

o Anwahl / Auswahl eines Patienten


Speichern als Datei



KEIN Warten auf das GERÄT

GERÄT

o Übernahme der Stammdaten in die eigene Datenbank.


7.2.2 Stapelübertragung von Stammdaten

Bei diesem Modus scheidet die Übertragung mittels serieller Schnittstelle aus. Das

GERÄT braucht dann aber nicht permanent Stammdaten in Empfang zu nehmen,

sondern kann dies in bestimmten Zeitintervallen vornehmen.

AIS

o Anwahl / Auswahl eines Patienten


Speichern als Datei


KEIN Warten auf das GERÄT

GERÄT

o Übernahme der Stammdaten in die eigene Datenbank


7.3 Trivialform GDT-Anforderung

In der Praxis hat sich gezeigt, dass für viele Anwendungen nur eine einfache Daten-

übermittlung realisiert wurde. Diese Form entstand meist aus der Not des AIS, die

Ansteuerung eines Gerätes aktiv vorzunehmen. Der Vorteil dieser Methode liegt in

der Flexibilität. Man kann verschiedenste GERÄTE installieren, die dann vom An-

wender selbst aufgerufen werden können.

AIS

o Erstellung einer Satzart 6301 (wird meist bei Anwahl eines Patienten pau-

schal als Datei abgelegt)

GERÄT

o Das Gerät wird vom Benutzer ausgewählt und in den Untersuchungs- / Ar-

beitsmodus versetzt

o Arbeit mit dem GERÄT

o (optionale) Erstellung eines Ergebnisses in Form einer Satzart 6310

AIS

o Beim Beenden eines Patienten (z.B. Verlassen der med. Dokumentation /

Karteikarte) wird noch nach dem Vorhandensein einer Satzart 6310 ge-


sucht und, falls vorhanden, zu der med. Dokumentation / Karteikarte des

Patienten hinzugefügt.

7.3.1 Ergebnis

Der Ablauf ist wie bei 7.3

7.4 Asynchrone Kommunikation

Moderne AIS haben die Möglichkeit, GDT-Anforderungen auszugeben, ohne direkt

auf das Ergebnis warten zu müssen. Ankommende Ergebnisdaten werden von

Dienstprogrammen, die im Hintergrund laufen, automatisiert und im Stapel zu unter-

schiedlichen Patienten angenommen.


„Neue Untersuchung anfordern“ (Satzart 6302)

o FK 8402 Geräte- und verfahrensspezifisches Kennfeld, diese Angabe er-

folgt jeweils pro Messgerät

o FK 8404 Unterkategorisierung zur FK 8402 (z.B. Auswahl eines Organs)

o FK 8408 Vergabe einer eindeutigen Kennung des Untersuchungsauftrages

(Studie-UID), damit mehrere Ergebnisdateien (Satzart 6310 kommt somit

mehrfach vor) für eine Untersuchung erstellt werden können (z.B. Erstel-

lung mehrerer Bilder)

o FK 8409 Vergabe einer Bezeichnung (Text) für einen Untersuchungsgang

als ergänzende Beschreibung für FK 8408

o FK 8410 Testident: Bei Vergabe einer ganzen Untersuchungsreihe können

mehrere Testidents vergeben werden

o FK 8411 Bezeichnung des Tests


o FK 8491 Beauftragender bzw. verantwortlicher Arzt (referring physician)

(z.B. Dr. med. Mustermann/123456499)

„Daten einer Untersuchung übermitteln“ (Satzart 6310)

o Alle Felder aus der zuvor erstellten Satzart 6302 und zusätzlich optional

o FK 6325 Kennung des (Teil-) Auftrages (z.B. Referenz auf ein Bild: Hand

lateral, Hand AP)

o FK 8412 Dateiname einer Ergebnisdatei (z.B. Thumbnail-Bild)

7.5 Asynchrone Kommunikation in einer Gerätegemeinschaft

Im Zuge der Rationalisierung und Bildung von Praxisgemeinschaften, Ärztehäusern,

Medizinische Versorgungszentren und Laborgemeinschaften, werden Medizingeräte

von mehreren Praxen gemeinsam genutzt. Die Geräte sind zumeist auch räumlich

getrennt.

7.5.1 Ablauf

Mehrere AIS senden Untersuchungs-/Behandlungsanforderungen an ein zentrales

GERÄT. Am GERÄT wird eine Worklist mit den offenstehenden Aufträgen geführt.

Nach Beenden der Arbeit mit dem GERÄT müssen die Ergebnisse wieder den Pra-

xen zur Verfügung stehen.


7.5.2 Erweiterungen des GDT

Erfordernis zur Generierung weltweit eindeutiger Kennungen für angeforderte

Leistungen eines Medizingerätes und die Zuordnung der Ergebnisse.

7.5.3 Erfordernis der Definition von Übertragungswegen

Solange die Daten im praxiseigenen LAN ausgetauscht werden, kann die Daten-

übermittlung über viele Wege frei definiert werden. Sobald diese Daten das interne

Praxisnetz verlassen, sind neben datenschutzrechtlichen Überlegungen (z.B. zur

Verschlüsselung) auch weitere Vorgaben / Normungen zu berücksichtigen, um die

Kommunikation in heterogenen Netzwerken nicht unnötig zu erschweren.


8 Änderungen zur Vorversion 3.0

Die Feldkennung FK 8100 „Satzlänge“ wurde geändert in FK 8004

Die Feldkennung FK 8202 „Satzende“ wurde geändert in FK 8001. Als Angabe für

den Feldinhalt wird die jeweilige Satzart (z.B. 6310) verwendet.

Die Feldkennung FK 8200 „ObjektIdent“ wurde geändert in FK 8002

Die Feldkennung FK 8201 „Objektende“ wurde geändert in FK 8003. Als Angabe

für den Feldinhalt wird die jeweilige Objektbezeichnung (z.B. Obj_Kopfdaten)

verwendet.

Redaktionell

o Begriff PVS gegen AIS ersetzt.

Hintergrund: Immer mehr wird die GDT-Schnittstelle nicht nur in der klassi-

schen Arztpraxis eingesetzt, sondern vermehrt im klinischen Umfeld (klini-

sche Ambulanzen, kliniknahen MVZ), so dass die Verwendung nicht mehr

nur auf die ambulante Arztpraxis beschränkt ist.

o Begriff „Zeilenlänge“ geändert in „Feldlänge“.

o Klarstellung des unterstützten Zeichensatzes.

Überarbeitung der Beschreibung der Feldtypen, analog KVDT Satzbeschreibung

Achtung: Reihenfolge beim Feldtyp „date“ = „d“ geändert.

Alte Definition TTMMJJJ, neue Definition JJJJMMTT.

Folgende Feldkennungen wurden auf die neue Definition umgestellt:

FK 3103, FK 3651, FK 3672, FK 4109 und FK 6200

Überarbeitung der Feldtypen

„alnum“ geändert in „a“

„float“ geändert in „f“

„date“ geändert in „d“

„num“ geändert in „n“

„zeit“ nicht mehr verwendet, stattdessen „n“

Satzart 6303 „Angeforderte Untersuchung stornieren“

Unnötige Kann-Objekte entfernt, da sie für diesen Usecase nicht benötigt wer-

den:

Obj_Basisdiagnostik

Obj_Dauermedikament


Obj_Dauerdiagnose

Obj_Überweisung

Obj_Diagnose

Obj_Anhang

Obj_Empfänger

Alle Satzarten

Hinter dem Objekt Obj_Patient kommt jetzt immer das Objekt

Obj_Versichertenkarte als Kann-Objekt.

Die einzeln aufgeführte Feldkennung FK 4111 in der Satzart 6311 wurde ent-

fernt, da die Feldkennung 4111 bereits im Obj_Versichertenkarte enthalten ist

und dieses Objekt jetzt unmittelbar hinter dem Objekt Obj_Patient folgt.

Objekt Obj_Anforderung

Erweiterung des Objektes um die Feldkennung 8501 Dringlichkeitsstatus, so wie

bereits im Objekt Obj_Labortest erfolgt.

Documents

GDT 3.1 Gerätedaten-Träger - QMS€¦ · GDT 3.1 Gerätedaten-Träger Schnittstellenbeschreibung zum systemunabhängigen Datentransfer zwischen Arzt-Informations-Systemen und med