GDT 3.0 Gerätedaten-Träger - QMS€¦ · GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 2 von 55 Stand: 01.10.2013 Version 3.0 Release 1.0 Autor Ralf Franke (Arbeitskreisleiter

Anbindung von medizinischen Messgeräten

GDT 3.0 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, 2013 Version: 3.0 Release: 1.0 Stand: 01.10.2013 Freigabe: Freigegeben

GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 2 von 55 Stand: 01.10.2013

Version 3.0 Release 1.0

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.10.2013 / Qualitätsring Medizinische Software e.V.

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

Änderungshistorie:

Version Datum Geändert von Änderungsgrund / Beschreibung

2.99.3.0.1 07.11.2011 Ralf Franke Erstentwurf

2.99.3.0.2 09.11.2011 Ralf Franke Ergänzungen aus Feedback

2.99.3.0.3 10.11.2011 Ralf Franke FK 9106 geändert in FK 9206 (GDT V 2.1)

Erweiterung FK 8402 (nach Vorschlag)

Neues Objekt „ArztIdent“

2.99.3.0.4 16.01.2012 Ralf Franke Überarbeitung

2.99.3.0.5 03.02.2012 Ralf Franke Ergänzung/Überarbeitung aus Arbeitskreissitzung BDT/GDT vom 17.01.2012

2.99.3.0.6 01.03.2012 Ralf Franke Aktualisierung der QMS e.V. Kontaktdaten

2.99.3.0.7 28.03.2012 Ralf Franke Aktualisierung Kommentare

2.99.3.0.8 20.05.2012 Ralf Franke Einpflegen der Zuarbeiten/Beiträgen von: ktberger-consulting, Arzt & Praxis GmbH und DGN Deutsches Gesundheitsnetz Service GmbH

2.99.3.0.9 06.08.2012 Ralf Franke Aktualisierung Kommentare

Überarbeitung Feldtabelle

Ergänzungen Kapitel Workflow

Neue Satzart 6303 „Stornierung eines Auftra-ges“

2.99.3.1 30.08.2012 Silke Hochheim Redaktionelle Anpassung an neues QMS-Layout

2.99.3.2 24.09.2012 Ralf Franke Ergänzung/Überarbeitung aus Arbeitskreissitzung BDT/GDT vom 04.09.2012

3.0 15.10.2012 Ralf Franke Prerelease für Kommentierungsphase

3.0 17.01.2013 Ralf Franke Berücksichtigung der Beiträge aus der Kommentie-rungsphase

3.0 31.01.2013 Ralf Franke Finale Version Prerelease


3.0 Release 1

01.07.2013 Ralf Franke Redaktionelle Änderungen: Überarbeitung der Bei-spieldateien, Grafiken, Schreibfehler

3.0 Release 1

01.10.2013 Ralf Franke Finale Version zur Veröffentlichung auf der Home-page des Qualitätsring Medizinische Software e.V.

Vorwort Nur durch die engagierte Vereinsarbeit im Qualitätsring Medizinische Software e.V. (im Fol-genden kurz QMS genannt) ist die hier vorliegende GDT-Datensatzbeschreibung möglich ge-worden. Jeder, der von den Ergebnissen profitieren möchte, ist daher aufgerufen, mitzuarbeiten und sich ebenfalls an der Konsensarbeit zu beteiligen. Leider sind in der Vergangenheit immer wieder unter dem Deckmantel "GDT-Schnittstelle" feh-lerhafte und nicht zertifizierte Versionen der GDT-Schnittstellen aufgetaucht, die das Ziel des standardisierten Datentransfers zwischen den Systemen aufzuweichen drohen und letztlich die Bemühungen des QMS nach Qualitätsstandards 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 inner-halb des QMS zu outen. Begleitet wird diese Maßnahme durch ein Anschreiben des QMS-Vorstandes an die verantwortliche Firma, sich dem Standard 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 7

1.1 Allgemeines .................................................................................................................................... 7

1.2 Begriffsdefinition ............................................................................................................................ 7

1.3 Kommunikation .............................................................................................................................. 8

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

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

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

1.4.3 Kennzeichnung für PVS ......................................................................................................... 8

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

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

2 SCHNITTSTELLEN-BESCHREIBUNG 9

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

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

2.3 Kommunikation über Datei .........................................................................................................10

2.3.1 Dateinamen ..........................................................................................................................10

2.3.2 Verzeichnis ...........................................................................................................................10

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

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

2.4.2 Ablauf der Kommunikation ...................................................................................................11

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“ (6301) ...................................................................15

2.6.3 Beispieldatei „Daten einer Untersuchung übermitteln“ 6310 ................................................16

3 SATZTABELLE 17

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

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

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

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


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 28

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 ...............................................................................................................................30

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

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

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

6.5 Beispieldateien „Best Practice“ .................................................................................................43

6.5.1 Stammdaten anfordern „6300“ (GERÄT an PVS) ................................................................43

6.5.2 Stammdaten übermitteln „6301“ (PVS an GERÄT) ..............................................................43

6.5.3 Neue Untersuchung anfordern „6302“ (PVS an GERÄT) ....................................................43

6.5.4 Daten einer Untersuchung übermitteln „6310“ (GERÄT an PVS) ........................................44

6.5.5 Daten einer Untersuchung anzeigen „6311“ (PVS an GERÄT) ...........................................45

6.5.6 Terminanforderung „6302“ (PVS an GERÄT) ......................................................................45

6.5.7 Überweisung an Facharzt „6302“ (PVS an GERÄT) ............................................................45

6.5.8 Krankenhauseinweisung „6302“ (PVS an GERÄT) ..............................................................46

6.5.9 Notfalldatensatz übermitteln „6302“ (PVS an GERÄT) ........................................................47

7 DARSTELLUNG DES WORKFLOWS 48

7.1 Basis-Workflow ............................................................................................................................48

7.1.1 Anforderung ..........................................................................................................................48

7.1.2 Anzeige von Ergebnisdaten ..................................................................................................49

7.2 Speicherung von Patientenstammdaten ....................................................................................50

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

7.2.2 Stapelübertragung von Stammdaten ....................................................................................50

7.3 Trivialform GDT-Anforderung .....................................................................................................52

7.3.1 Ergebnis ................................................................................................................................53


7.4 Asynchrone Kommunikation ......................................................................................................53

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

7.5.1 Ablauf ....................................................................................................................................55

7.5.2 Erweiterungen des GDT .......................................................................................................55

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


1 Einführung

1.1 Allgemeines

Die vorliegende Schnittstellenbeschreibung wurde vom QMS (Qualitätsring Medizinische Soft-ware 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 Markt-teilnehmern im Gesundheitswesen verwendbar. Sie kann sowohl von Standalone-Geräten, wie auch von PC-gestützten Messgeräten realisiert werden. Sollte eine direkte Kommunikation ge-mäß dieser Beschreibung technisch nicht realisierbar 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 Realisierung 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 verwendet:

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

PVS (Arzt-)PraxenVerwaltungsSystem

KOMPONENTE Jeder Teilnehmer am Datenaustausch PVS 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 PVS 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 Untersuchungsdaten liegt, sollte ein PVS mindestens als SERVER (Verarbeiten von Untersuchungs-Daten) und ein GERÄT mindestens als CLIENT (Senden von Untersuchungs-Daten) arbeiten können (vgl. 1.4).


1.3 Kommunikation

Prinzipiell ist eine Datenkommunikation über drei verschiedene Mechanismen möglich:

Datei-Schnittstelle

Die Kommunikation zwischen GERÄT und PVS erfolgt über Dateien, die in bestimmten Ver-

zeichnissen unter bestimmten Namen (s.u.) angelegt werden.

Serielle Schnittstelle

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

Schnittstelle mit dem PVS.

Programm-Programm-Schnittstelle

GERÄT und PVS unterstützen Programm-Programm-Schnittstellen (z.B. Clipboard, DDE,

OLE, UNIX-Pipes)

Die vorliegende Version der Schnittstellenbeschreibung beschränkt sich auf die beiden Mecha-nismen: 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 Datenfor-mat 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 verwendet, die für PVS und GERÄTE unterschiedlich definiert ist.

Um festzustellen, ob ein bestimmtes PVS mit einem GERÄT kommunizieren kann, müssen ledig-lich die Schnittstellen-Kennzeichnungen überprüft werden. Eine Kommunikation ist dann möglich, wenn mindestens ein Übertragungsweg (seriell oder Da-tei) und mindestens eine SERVER-/CLIENT-Angabe übereinstimmen.

Die technische Dokumentation eines GDT-fähigen GERÄTES, bzw. PVS muss daher eine ent-sprechende Angabe über die Art der realisierten Schnittstelle enthalten.

1.4.2 Mindestanforderungen für PVS und GERÄT

Das PVS 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 PVS

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 PVS kann als SERVER arbeiten

= 01 PVS kann als CLIENT arbeiten


= 11 PVS kann als SERVER oder CLIENT arbeiten

Beispiel: GDT-S-10 / GDT-D-11

PVS 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 PVS / GERÄT

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

PVS 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:

PVS 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 beteiligten Kompo-nenten und wird bei der Installation festgelegt.

Die ID besteht aus insgesamt 8 beliebigen Zeichen, die hersteller- und gerätespezifisch 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 ist der IBM-8-Bit Zeichensatz (Codepage 437) mit Zeichen ≥ 20hex (32 dez.).

Zusätzlich können weitere Zeichensätze unterstützt werden.


2.3 Kommunikation über Datei

2.3.1 Dateinamen

Die Übermittlung von Informationen erfolgt über (Text-)Dateien, deren Datei-Name bei der Instal-lation eindeutig festzulegen ist. Der Aufbau des Dateinamens ist wie folgt definiert:

<Empfänger-Kürzel><Sender-Kürzel>.<hochzählende Nr> (z.B. PVS2GER.005)

oder

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

oder

<Empfänger-Kürzel><Sender-Kürzel>_<hochzählende Nr>.GDT (z.B. PVS2GER_4711.GDT)

Der Dateiname setzt sich aus max. 4 Zeichen als Kürzel für den Empfänger und max. 4 Zeichen als Kürzel für den Sender der Datei zusammen (siehe oben).

Die Dateinamenserweiterung (Extension) ist eine 3stellige, hochzählende Nummer, die fortlau-fend für einen bestimmten Dateinamen vergeben wird. Die Dateizählung beginnt bei fortlaufender Extension mit .001 (führende Nullen). Damit ist sichergestellt, dass auch mehrere Dateien (z.B. von einem GERÄT) an das PVS geschickt werden können. Hinweis: Ist abzusehen, dass die drei Stellen der Extension nicht für die fortlaufende Nummerie-rung ausreichend sind, so kann diese auch in den Dateinamen eingefügt werden, sofern der Empfänger dieses verarbeiten kann. (z.B. PVS2GER_4711.GDT). Manche Betriebssysteme ha-ben Restriktionen in Bezug auf die Extension von Dateinamen!

Kann von bestimmten Systemen nur ein fester Dateiname konfiguriert werden, so ist für diesen die Extension „GDT“ vorzusehen (z.B. PVS1EKG1.GDT).

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

Die Dateien werden vom jeweiligen Sender erzeugt, wobei die Extension entsprechend hochge-zählt wird. Sollte eine Datei mit Extension .GDT noch vorhanden sein (Empfänger hat Datei noch nicht gelesen) darf diese vom Sender nicht überschrieben werden (Datenverlust).

Die Verarbeitung durch den Empfänger hat sortiert nach Datum/Zeit (FIFO) zu erfolgen. Nach dem Lesen sind die Dateien durch den Empfänger zu löschen.

Um Kommunikationsprobleme zu verhindern, sollte der Sender die Kommunikationsdatei 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 Dateinamen (z.B. Dateiname ohne Extension) erstellt wer-den. 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-/PVS-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 Leitun-gen 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 richtigen Polung sicherheitshalber Kon-takt 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 inner-halb des Protokolls ein eigener Software-Handshake definiert ist, kann auf eine zusätzliche, ex-terne Handshake-Prozedur (XON-XOFF) verzichtet werden.

Um die Kompatibilität zu erhalten, werden die Satz- und Zeilenlängen der übermittelten Dateien immer mit CR / LF berechnet (so wie im GDT definiert). Statt dieser beiden Zeichen 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 aufgeführten Kom-ponenten.

Die Praxis arbeitet mit dem PVS „PRAX_PVS“ (GDT-SD-11) und hat daran drei Geräte angebun-den:

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

tendruck Untersuchungsdaten an das PVS schicken kann (ohne eigene Stammdatenverwal-

tung) (PVS ist SERVER / GERÄT ist CLIENT).

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

und von der Karteikarte aus aufgerufen wird (PVS 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 PVS kommuniziert (PVS ist SERVER / GERÄT ist

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

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

waltung)

PVS = SERVER GERÄT = CLIENT

Messung am Phoropter wird durchgeführt

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

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


2. Kommunikation zwischen PVS und EKG-Schreiber

PVS = CLIENT GERÄT = SERVER

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

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

Wechsel zur Gerätesoftware durch Aufruf des Programms im Verzeichnis ECG.BAT unter C:\REST.ECG

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

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

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

Beenden des Programms und damit Wechsel zum PVS

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

3. Kommunikation zwischen PVS und Lungenfunktions-Messplatz

PVS = Server GERÄT = CLIENT

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

Tastendruck am GERÄT fordert Patienten an: GERÄT schreibt Datei F: \ GDT \ PVS_LUFU.001 mit Satzart 6300 zur Anforderung des aktuellen Patienten

PVS liest/verarbeitet und löscht Datei F: \ GDT \ PVS_LUFU.001 PVS schreibt Datei F: \ GDT \ LUFU_PVS.001 mit

Satzart 6301 zur Übermittlung des aktuellen Stammdatensatzes

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


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

GERÄT schreibt Datei F:\GDT\PVS_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\PVS_LUFU.003 mit Satzart 6310 zur Übermittlung der Ergebnisse

PVS liest/verarbeitet und löscht Dateien F:\GDT\PVS_LUFU.002 und PVS_LUFU.003

PVS ordnet Daten dem Patienten zu


2.6 Kommentierte Beispiel-Dateien

2.6.1 Aufbau einer GDT-Zeile:

0163101Schmidt<CR><LF>

Zeilenlänge inkl. CR LF

Feldkennung des Zeileninhalts

Inhalt des jeweiligen Datenfeldes

Zeilenende (CR/ LF)

2.6.2 Beispieldatei „Stammdaten übermitteln“ (6301)

01380006301 ; Satzart ”Stammdaten übermitteln”

01681000000292 ; Satzlänge

0228200Obj_Kopfdaten Startkennung Objekt „Obj_Kopfdaten“

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

0178316PRAX_PVS ; GDT-ID des Senders

014921803.01 ; Versions-Nr. GDT

01082015 Objektende (Objekt enthält 5 Felder)

0208200Obj_Patient ; Startkennung Objekt „Obj_Patient“

014300002345 ; Patienten-Nummer

0193101Mustermann ; Nachname

0143102Franz ; Vorname

017310301101945 ; Geburtsdatum

01031101 ; Geschlecht (1=männlich)


0288200Obj_Basisdiagnostik ; Startkennung Objekt „Obj_Basisdiagnostik“

0153622178.00 ; Größe

0153623079.00 ; Gewicht


011820219 Satzende (Satz enthält 19 Felder)

= CR / LF

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


2.6.3 Beispieldatei „Daten einer Untersuchung übermitteln“ 6310

01380006310 ; Satzart

01681000001073 ; Dateilänge

0228200Obj_Kopfdaten ; Start eines neuen Objektes

0178315PRAX_PVS ; GDT-ID des Empfängers

0178316LZBD_SYS ; GDT-ID des Senders

014921803.01 ; Versions-Nr. GDT

01082015 Objektende

0208200Obj_Patient ; Start eines neuen Objektes

014300002345 ; Patienten-Nummer

0193101Mustermann ; Nachname

0143102Franz ; Vorname

017310301101945 ; Geburtsdatum

01031101 ; Geschlecht (1=männlich)

0082017 Objektende

0288200Obj_Basisdiagnostik ; Start eines neuen Objektes

0153622178.00 ; Größe

0153632079.00 ; Gewicht

0148402BDM01 ; Untersuchung: 24h-Blutdruck

017620023101998 ; 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%

0168410SYSMXTG ; Test-Ident (Hersteller-spez.)

0298411SystolemaxTagphase ; Testbezeichnung

0128420142 ; Wert

0138421mmHg ; Einheit

017843223101998 ; Datum Messwert

0158439163400 ; Uhrzeit Messwert

0128462140 ; oberer Grenzwert

0168410SYSMNTG ; nächster Test-Ident


0298411SystoleminTagphase ; Testbezeichnung

0128420112 ; Wert

0138421mmHg ; Einheit

017843224101998 ; Datum dieses Messwertes

0158439031200 ; Uhrzeit dieses Messwertes

011820129 Objektende

011820244

= 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, 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, 6310, 6311) können zu beliebigen Zeitpunkten übermittelt werden und verlangen keine Antwort.

In der Regel gilt folgende Kommunikationsrichtung:

6300: GERÄT PVS

6301: PVS GERÄT

6302: PVS GERÄT

6310: GERÄT PVS

6311: PVS GERÄT

GERÄT = Medizingerät

PVS = (Arzt-)PraxenVerwaltungsSystem

Hinweis:

Die in den Satzarten beschriebenen Objekte werden in einem separat gepflegten Doku-

ment „GDT-Objektkatalog“. In diesem werden Aktualisierungen zu den Objekten vorge-

nommen, ohne dass diese Einfluss auf die hier vorliegende Version der Schnittstelle ha-

ben.

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 Hierarchiestufe zugewiesen, das heißt


das Auftreten des Feldes wird an die Existenz 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 ent-

sprechend 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

8100 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

8202 1 Satzende M Enthält die Anzahl der übermittelten Felder inkl. FK 8000 und FK 8202

3.2 Definition der Satzarten: Stammdaten übermitteln „6301“



8000 1 Satzidentifikation M Satzart Stammdaten übermitteln




Basisdi-agn.

xxxx 1 Obj_Basisdiagnostik K Siehe Anhang D

Versicher-tenkarte



3.3 Definition der Satzarten: Neue Untersuchung anfordern „6302“



8000 1 Satzidentifikation M Satzart Neue Untersuchung anfordern




Anforde-rung

xxxx 1 Obj_Anforderung M Siehe Anhang D

Basisdi-agnose


Dauer-medika-ment

xxxx 1 Obj_Dauermedikament K Siehe Anhang D

Anforde-rung

xxxx 1 Obj_Anforderung K Siehe Anhang D

Dauerdi-agnose

xxxx 1 Obj_Dauerdiagnose K Siehe Anhang D

Versicher-tenkarte


Ü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_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




Anforde-rung


Basisdi-agnose


Anforde-rung

xxxx 1 Obj_Anforderung K Siehe Anhang D

Dauer-medika-ment

xxxx 1 Obj_Dauermedikament K Siehe Anhang D

Dauerdi-agnose

xxxx 1 Obj_Dauerdiagnose K Siehe Anhang D

Versicher-tenkarte


Überwei-sung

xxxx 1 Obj_Überweisung K Siehe Anhang D

Diagnose xxxx 1 Obj_Diagnose K Siehe Anhang D


Rg_Emp-fänger

xxxx 1 Obj_Empfänger K Siehe Anhang D

Arztidenti-fikation




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



8000 1 Satzidentifikation M Satzart Daten einer Untersuchung übermitteln




Anforde-rung


Basisdi-agnose


Anforde-rung


Versicher-tenkarte


6200 1 Tag der Speicherung von Be-handlungsdaten

K TTMMJJJJ Datum der Untersuchung

6205 n Aktuelle Diagnose K

6206 1 Pharmazentralnummer (PZN) K

6210 1 Medikament verordnet auf Rezept m Falls 6206 vorhanden

6211 1 Außerhalb Rezept verordnetes Medikament

m Falls 6206 vorhanden

6214 1 Anzahl Packungen (Faktor) K

6218 1 Angabe zur Einnahme K

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

6407 1 Noctu K 0=nein, 1=ja

6408 1 BVG K 0=nein, 1=ja

6409 1 Unfall K 0=nein, 1=ja

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

6220 N Befund K

6221 N Fremdbefund K z.B. vom Gerät automatisch erzeugter Befundhinweis

6227 N Kommentar K

6226 N Anzahl der nachfolgenden Fort-setzungszeilen der Kennung

K Hiermit kann bei der Übertragung von 6228 die GDT-Längenbeschränkung umgangen werden. Wird z.B. hier der Wert 2 übertragen, dann bilden die folgenden 2 Zeilen 6228 eine Gesamt-zeile, die vom Empfänger zusammen-gesetzt werden sollte.

6228 n Ergebnistabellentext, formatiert m Falls 6226 vorhanden

Beliebiger Ergebnistext, vom Gerät formatiert


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




Anforde-rung


4111 1 Krankenkassennummer (KIK) K

Arztidenti-fikation




4 Feldtabelle

Tabelle der in den Sätzen 6300, 6301, 6302, 6310, 6311 verwendeten Feldkennungen.

* Ä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“ Versi-on 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 alnum z.B. Firma

0103 Software var alnum Name der Software

0132 Release-Stand der Software var alnum 12.4

0201 (N)-BSNR 9 num 947812345

0202 Name des Kostenträgers var alnum Deutsche Rentenversicherung

0212 LANR 9 num 123456789

0950 Pharmazentralnummer Dauermedi-

kament

var alnum 4877800

0957 Darreichungsform Dauermedikament var alnum Filmtablette

3000 Patientennummer / Patientenkennung var alnum 123456

3100 Namenszusatz / Vorsatzwort des

Patienten

var alnum Von

3101 Name des Patienten var alnum Schmitz

3102 Vorname des Patienten var alnum Erna

3103 Geburtsdatum des Patienten 8 datum 020/304 12041946

3104 Titel des Patienten var alnum Dr.

3105 Versichertennummer des Patienten var alnum 123456M789

3106 Wohnort des Patienten var alnum 50859 Köln

3107 Straße des Patienten var alnum Holzweg 106

3108 Versichertenart MFR 1 num 116 3

3110 Geschlecht des Patienten 1 num 112 1

3112 PLZ des Patienten var alnum 50859

3113 Wohnort des Patienten var alnum Köln

3114 Wohnsitzländercode var alnum DE

3116 KV-Bereich 2 num 17

3119 Versichertennummer eGK des Pati- 10 alnum A123456780



enten

3618 Mobiltelefonnummer des Patienten var alnum 0172 9335 172

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

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

3623 Gewicht des Patienten in kg var float 90.50

3626 Telefonnummer des Patienten var alnum 0951 3458 200

3628 Muttersprache des Patienten var alnum Deutsch

3649 Dauerdiagnose ab Datum 8 datum 01012012

3650 Dauerdiagnose var alnum Diabetes mellitus

3651 Dauermedikament ab Datum 8 datum 12112011

3652 Dauermedikament var alnum Adalat

3654 Risikofaktoren var alnum Raucher

3656 Allergien var alnum Neurodermitis

3658 Unfälle var alnum Motoradunfall

3660 Operationen var alnum Blinddarm

3662 Anamnese var alnum Frühgeburt

3664 Anzahl Geburten var num 2

3666 Anzahl Kinder var num 3

3668 Anzahl Schwangerschaften var num 4

3670 Dauertherapie var alnum Schmerzpumpe

3672 Kontrolltermine 8 datum 01121993

3673 Dauerdiagnose ICD-Code 3,5,6 alnum E10.21

3674 Diagnosesicherheit Dauerdiagnose 1 alnum Z

3675 Seitenlokalisation Dauerdiagnose 1 alnum R

3676 Diagnoseerläuterung Dauerdiagnose var alnum EKG eindeutig

3677 Diagnoseausnahmetatbestand Dau-

erdiagnose

var alnum true

3700 Bezeichnung der basisdiagnostischen

Kategorie

var alnum Kardiovaskuläre Familienbelastung

3701 Inhalt der basisdiagnostischen Kate-

gorie

var alnum Ja

4104 VKNR 5 num 27106

4106 Kostenträger-Abrechnungsgebiet 2 num 00

4109 Letzter Einlesetag der Versicherten-

karte im Quartal

8 datum 07082012

4110 Bis-Datum der Gültigkeit 4 num 0913

4111 Krankenkassennummer (KIK) 7 num 12568008



4112 Versichertenstatus KVK 4 num 1000

4113 Statusergänzung / DMP-

Kennzeichnung

1 alnum 1

4121 Gebührenordnung 1 num 1

4122 Abrechnungsgebiet 2 num 00

4200 Terminwunsch var alnum

4202 Unfall, Unfallfolgen 1 num 1

4203 Behandlung gem. § 116b SGB V 1 num

4204 Eingeschränkter Leistungsanspruch

gem. § 18 Abs. 3a SGB V

1 num 1

4205 Auftrag var alnum

4207 Diagnose / Verdachtsdiagnose var alnum Verdacht auf Hepatitis

4208 Befund / Medikation var alnum

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

4217 (N)BSNR (Nebenbetriebsstätten-

nummer) des Erstveranlassers

9 num 123456700

4218 (N)BSNR des Überweisers 9 num 234567800

4219 Überweisung von anderen Ärzten var alnum Allgemeinmedizin

4220 Überweisung an var alnum Radiologen

4221 Behandlungstyp 1 num 1

4229 Ausnahmeindikation 5 num 32005

4231 Kontrolluntersuchung einer bekann-

ten Infektion

1 num

4237 Krankenhaus-Name var alnum Uniklinik

4241 LANR (lebenslange Arztnummer) des

Erstveranlassers

9 num 123456789

4242 LANR des Überweisers 9 num 234567890

6001 ICD Code 3,5,6 alnum L50.0

6003 Diagnosesicherheit 1 alnum Z

6004 Seitenlokalisation 1 alnum R

6006 Diagnoseerläuterung var alnum Klinisch

6008 Diagnoseausnahmetatbestand var alnum Zustand nach Geschlechtsumwand-

lung

6200 Tag der Speicherung von Behand-

lungsdaten

8 datum 008 12031993

6201 Uhrzeit der Erhebung von Behand-

lungsdaten

6 zeit 110435

6205 Aktuelle Diagnose var alnum Diabetes

6206 Pharmazentralnummer (PZN) var alnum 4877800



6210 Medikament verordnet auf Rezept var alnum Adalat

6211 Außerhalb Rezept verordnetes Medi-

kament

var alnum Sostril

6214 Anzahl Packungen (Faktor) 3 num 008

6218 Angabe zu Einnahme var alnum 1-0-0

6220 Befund var alnum Erhöhter Blutdruck

6221 Fremdbefund var alnum Verdacht auf Obstruktion

*N2.1 6226 Anzahl der nachfolgenden Fortset-

zungszeilen der Kennung 6228

var num 2

*N 6227 Kommentar var alnum Belastung abgebrochen

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

6302 Datei-Archivierungskennung var alnum 000001

6303 Dateiformat var alnum PDF

6304 Dateiinhalt var alnum Datenanalyse

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

6329 Inhalt der Datei als BASE64-kodierte

Anlage

var alnum

*N2.1 6330-

6398

Name der freien Kategorie var alnum PATINFO

*N2.1 6331-

6399

Inhalt der freien Kategorie var alnum Patient ist fröhlich

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

6407 Noctu 1 num 0=nein, 1=ja

6408 BVG 1 num 0=nein, 1=ja

6409 Unfall 1 num 0=nein, 1=ja

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

8000 Satzidentifikation 4 alnum 6301

8100 Satzlänge 7 num 0000747

8200 ObjektIdent var alnum Bsp.: Obj_Kopfdaten

8201 Objektende var num Enthält die Anzahl der übermittelten

Felder im Objekt inkl. der Felder

„8200“ und „8201“

8202 Satzende var num Enthält die Anzahl der übermittelten

Felder im Satz inkl. der Felder „8000“

und „8202“ (Bsp. : 7)

8310 Anforderungs-Ident var alnum 223

8314 Anforderungs-UID var alnum Gesicherte eindeutige Anforderungs-

ID (UID)

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



*N 8316 GDT-ID des Senders var alnum PRAX_PVS

*L 8402 Geräte und verfahrensspezifisches

Kennfeld

var alnum EKG01, siehe Anhang B

8403 Gebührenordnung 1 num 1

8404 Unterkategorie zur KF 8402 Niere links

8405 Patienteninformation var alnum Zusatzinfo: Übergewicht

8407 Geschlecht 1 num 2

8410 Test-Ident var alnum FEV1

8411 Testbezeichnung var alnum Obj. refr. cyl. Rechts

8412 Test-OID var alnum

8413 Test-Geräte-UID var alnum

8418 Teststatus 1 alnum B

8420 Ergebnis-Wert var float -3.70

8421 Einheit var alnum Dpt

8425 Budget-frei 1 num 1

8428 Probenmaterial-Ident var alnum SE

8429 Probenmaterial-Index 2 num 01

8430 Probenmaterial-Bezeichnung var alnum Abstrich

8431 Probenmaterial-Spezifikation var alnum Linkes Auge

8432 Abnahme-Datum 8 datum 008 31011994

8433 Abnahme-Zeit 6 zeit 091520

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

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

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

Werte enthalten.

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

8460 Normalwert-Text var alnum negativ

*N 8461 Normalwert untere Grenze var float -15.00

*N 8462 Normalwert obere Grenze var float 12.00

8470 Testbezogene Hinweise var alnum Gefrorenes Serum erforderlich

8480 Ergebnis-Text var alnum negativ

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

8504 Medikamenteneinnahme zum Zeit-

punkt der Probenentnahme

var alnum

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

8511 Schwangerschaftsdauer

(in Wochen, Tage)

3 num 242

8512 1. Tag des Zyklus 8 datum 09102012



8601 Name des Rechnungsempfängers var alnum Müller

8602 Titel, Vorname des Rechnungsemp-

fängers

var alnum Dr. Hans

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

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

8608 Kommentar / Aktenzeichen var alnum 222/234AH

8609 Abrechnungstyp 1 alnum P

8610 Privattarif 1 num 2

8615 Auftraggeber var alnum 123456600

8990 Signatur (Namenszeichen) var alnum Dr. Huber

9103 Datum der Erstellung 8 datum 20102012 (im Format TTMMJJJJ)

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

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

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

*N2.1 9206 Verwendeter Zeichensatz 1 num 2

*N 9218 Version GDT 5 alnum 03.00

datum = Datumsangabe TTMMJJJJ

zeit = Uhrzeit HHMMSS

num = numerisch, bei festen Feldlängen ist das Feld mit führenden Nullen aufzufüllen

alnum = alphanumerisch

float = Fließkommazahl mit Punkt als Dezimaltrennzeichen

5 Regeltabelle

Regeln sind entsprechend ihrer Art in Nummernkreise unterteilt:

000 – 099 Formatprüfungen

100 – 199 Inhaltsprüfungen

200 – 299 Existenzprüfungen

300 – 399 Kontextprüfungen

Regelnr. Kategorie Prüfung Erläuterung

008 Format TTMMJJJJ TT=Tag; MM=Monat; JJJ=Jahr

020 Format TTMMJJJJ Wertebereich: TT=00-31, MM=00-12; JJJJ=0000-9999

090 Format HHMMSS HH=Stunde; MM=Minute; SS=Sekunde

Wertebereich: HH=00-24; MM=00-59; SS=00-59 (evtl. fehlende

Sekunden sind mit 00 anzugeben)

112 Erlaubter Inhalt 1, 2


116 Erlaubter Inhalt 1, 2, 5 Versichertenart MFR

304 Kontext Datum kleiner oder

gleich Maschinendatum

Vermeidung von Fehleingaben

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 Übertragung 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 Synchronisation. Er wird bei der ersten Über-tragung 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 Datenfeld zu-sammengefasst werden. Eine Zeile kann auch auf mehrere Datenfelder verteilt werden. Als Trennung zwischen zwei Zeilen wird das Zeichen 1Ch (Feldseparator FS) verwendet. Die Satz-länge und die Zeilenlängen werden dabei inkl. CR / LF berechnet. Außer dem Feldseparator dür-fen 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 Quellcodebeispiele aus älteren GDT-Datensatzbeschreibungen bzw. auf Quellen aus dem Internet 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|01681000000119|0228200Obj_Kopfdaten|0178315QMS-<CRC> <CR>

S: <ACK> 1

C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>

S: <ACK> 1

Server antwortet:

S: 7B00 01380006301|01681000000217|0228200Obj_Kopfdaten|0178315ROP<CRC> <CR>

C: <ACK> 1

S: 8B01 200U1|0178316QMS-GDT1|014921803.00|01082015|0208200Obj_Pat<CRC> <CR>

C: <ACK> 1

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

C: <ACK> 1

S: 1B02 |01031102|01082017|011820215<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 Übertragungs-block 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 übertragen, 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

C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>

S: <ACK> 0 Fehler aufgetreten

Block nochmals senden mit gleichem Sende-Sequenz-Zähler(in diesem Beispiel 2) C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>

S: <ACK> 1 diesmal Block richtig empfangen

Synchronisation nach Übertragungsfehlern


S: <ACK> 1

C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>



S: <ACK> 0 Fehler erneut aufgetreten


neue Synchronisation mit Sequenzzähler 0

S: <ACK> 1

C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>

S: <ACK> 1

Abbruch einer Übertragung nach Übertragungsfehlern


S: <ACK> 1

C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>






neue Synchronisation mit Sequenzzähler 0

S: <ACK> 1

C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>


C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>


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

C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>

S: [<ACK> 1]

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

C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>

erneutes Senden des gleichen Blocks

S: 7B00 01380006301|01681000000217|<CRC> <CR> Server sendet bereits den 1. Block der angeforderten Stammdaten


erneutes Senden durch Client mit neuer Synchronisation

S: 7B00 01380006301|0158100000217|<CRC> <CR> Server wiederholt den 1. Block der Stammdaten (ACK 1 vom Client fehlt)


Client wiederholt den Synchronisati-onsversuch


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

S: 0B00 01380006301|01681000000217|<CRC> <CR> Server wiederholt den Synchronisa-tionsversuch

Die Übertragung wird nach Timeout (”warten auf ACK”) von Server und Client abgebrochen (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 Buchstaben als Gruppenkennung, sowie einer anschließenden 2-stelligen Nummerierung von 00 bis 99 (z.B. LUFU09). Die Nummer 00 ist dabei grundsätzlich als Kennfeld für nicht näher spezifizierte Untersuchungen der jeweiligen Grup-pe reserviert. Die Gruppenkennung 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 nachfolgend auf-geführten Gruppen und Feldinhalte sind daher nur als eine erste Zusammenstellung zu betrach-ten, die beliebig erweiterbar ist.

Im Gegensatz zur Kennung 8402 können die jeweiligen Testidents (Kennung 8410) hersteller-spezifisch vergeben werden (vgl. Anhang B 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 Datenschnittstelle

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 Daten-bank 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ümmungsradien/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 Sequenz

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

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

8410 Test-Ident

Größe

[cm]


…

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 gleichen Zeitab-

stä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 vergleichend 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öglich-keit, die Zeit als selbständige Dimension im Feld 8417 zu übertragen, ist hierdurch jedoch nicht genommen.

Man erhält folgende Datensatzdarstellung:

6310 Satz

Vorkommen

1 2 3 4

3000 Patientendaten 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


…

8417 Datenstrom n

…

8420 Messwert (alternativ) 1

Diese Darstellung erlaubt, alle erforderlichen Messdaten direkt abzubilden. Sie ist abwärtskompa-tibel zur GDT Version 1.0! Sind die Felder 8405 (Probe) und 8406 (Datum) nur einmal vorhanden oder fehlen ganz, so unterscheidet sich der Datensatzaufbau nicht von der Abbildung der Daten, wie sie in der GDT Version 1.0 definiert 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 Feldkennungen, Regeln für Vorkommen, Bezeichnung, …) finden Sie in dem Dokument „Objektkatalog 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_Versichertenkarte

Obj_Dauerdiagnose Obj_RgEmpfänger

Obj_Dauermedikament Obj_Satzende


6.5 Beispieldateien „Best Practice“

Folgende Beispieldateien zeigen in der täglichen Praxis häufig vorkommende Vorgänge mit den erforderlichen Feldkennungen und Satzarten:

Legende: GERÄT = Medizinisches Gerät, PVS = (Arzt-)PraxenVerwaltungsSystem

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

Aufbau Satzart 6300 Kommentar

Stammdaten anfordern (6300) ist ein Vorgang des medizinischen Gerätes (GERÄT) an das (Arzt-) PraxenVerwal-tungsSystem (PVS). Im Objekt Obj_Patient kann über 3119 alternativ zur Patientennummer eine Identifikation erfolgen. Andernfalls werden die Daten des aktuellen Patienten angefordert.

1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Satzende

Vorgang: GERÄT an PVS. Beispiel wie bisher

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


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

1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_ArztIdent

4. Obj_Satzende

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

6.5.3 Neue Untersuchung anfordern „6302“ (PVS 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: PVS 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_Anforderung

4. Obj_Versichertenkarte

5. Obj_Basisdiagnostik

6. Obj_DauerDiag

7. Obj_DauerMed

8. Obj_ArztIdent

9. Obj_Satzende

Vorgang: PVS 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 Daten einer Untersuchung übermitteln „6310“ (GERÄT an PVS)

Aufbau Satzart 6310

1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Untersuchung

4. Obj_Anhang

5. Obj_Satzende

Vorgang: GERÄT an PVS


6.5.5 Daten einer Untersuchung anzeigen „6311“ (PVS an GERÄT)

Aufbau Satzart 6311

1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Anforderung

4. Obj_ArztIdent

5. Obj_Satzende

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

6.5.6 Terminanforderung „6302“ (PVS 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 angefragte Facharztpraxis für den weiteren Arbeitslauf in der Zielpraxis besonders wichtig.

1. Obj_Kopfdaten

2. Obj_Patient

3. Obj_Anforderung

4. Obj_Terminanfrage

5. Obj_ArztIdent

6. Obj_Satzende

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

6.5.7 Überweisung an Facharzt „6302“ (PVS 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

3. Obj_Anforderung




6. Obj_Versichertenkarte 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

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

6.5.8 Krankenhauseinweisung „6302“ (PVS 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

3. Obj_Anforderung



6. Obj_Versichertenkarte

7. Obj_Einweisung

8. Obj_DauerMed

9. Obj_DauerDiag

10. Obj_Anhang

11. Obj_Untersuchung

12. Obj_ArztIdent

13. Obj_Satzende

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


6.5.9 Notfalldatensatz übermitteln „6302“ (PVS 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: PVS an GERÄT.


7 Darstellung des Workflows

Die GDT-Schnittstelle wurde entworfen, um PVS mit medizinischen Geräten (GERÄT) aller Art kommunizieren zu lassen. Dabei übergibt das PVS ausgewählte Stammdaten und ggfls. medizi-nische Informationen von Patienten an ein medizinisches Untersuchungs- 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

PVS

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 PVS

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

PVS

o Ergebnisdaten empfangen und speichern

7.1.2 Anzeige von Ergebnisdaten

PVS

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 existierenden Da-

tenmaterial

o Beenden der Auswertung


7.2 Speicherung von Patientenstammdaten

Zum Zweck der Synchronisation von Datenbeständen ist eine Satzart 6301 definiert worden. Da-bei sollen sämtliche Stammdaten des PVS (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 verarbei-ten.

PVS

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.


PVS

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 PVS, die Ansteuerung eines GE-RÄTs aktiv vorzunehmen. Der Vorteil dieser Methode liegt in der Flexibilität. Man kann ver-schiedenste GERÄTe installieren, die dann vom Anwender selbst aufgerufen werden können.

PVS

o Erstellung einer Satzart 6301 (wird meist bei Anwahl eines Patienten pauschal als

Datei abgelegt)

GERÄT

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

versetzt

o Arbeit mit dem GERÄT

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

PVS


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

wird noch nach dem Vorhandensein einer Satzart 6310 gesucht 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 PVS haben die Möglichkeit, GDT-Anforderungen auszugeben, ohne direkt auf das Er-


gebnis warten zu müssen. Ankommende Ergebnisdaten werden von Dienstprogrammen, die

im Hintergrund laufen, automatisiert und im Stapel zu unterschiedlichen Patienten angenommen.

„Neue Untersuchung anfordern (Satzart 6302)

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

pro Messgerät

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

o FK 8408 Vergabe einer Study-UID, damit mehrere Ergebnisdateien (Satzart 6310

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

stellung mehrerer Bilder)

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

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, Medizini-sche Versorgungszentren und Laborgemeinschaften, werden Medizingeräte von mehreren Pra-xen gemeinsam genutzt. Die Geräte sind zumeist auch räumlich getrennt.

7.5.1 Ablauf

Mehrere PVS senden Untersuchungs-/Behandlungsanforderungen an ein zentrales GERÄT. Am GERÄT wird eine Worklist mit den offen stehenden Aufträgen geführt. Nach Beenden der Arbeit mit dem GERÄT müssen die Ergebnisse wieder den Praxen 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 ne-ben 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.

Documents

GDT 3.0 Gerätedaten-Träger - QMS€¦ · GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 2 von 55 Stand: 01.10.2013 Version 3.0 Release 1.0 Autor Ralf Franke (Arbeitskreisleiter