Vorwort. QMS Qualitätsring Medizinische Software. Daher: Werden Sie Mitglied, arbeiten Sie mit und lassen sich zertifizieren!!

Transkript

1 Vorwort Nur durch die engagierte Vereinsarbeit im QMS ist die hier vorliegende GDT-Datensatzbeschreibung möglich geworden. 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" fehlerhafte 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 innerhalb 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!! QMS Qualitätsring Medizinische Software GDT V 2.1 (5/01) Seite 1 / 47

2 Anbindung von medizinischen Meßgeräten (GDT - Gerätedaten-Träger) Schnittstellenbeschreibung zum systemunabhängigen Datentransfer zwischen Praxis-EDV Systemen und Meßgeräten Version 2.1 (5/2001) Qualitätsring Medizinische Software c/o Kassenärztliche Vereinigung Hessen Bezirksstelle Darmstadt Wilhelminenplatz Darmstadt GDT V 2.1 (5/01) Seite 2 / 47

3 Inhaltsverzeichnis 1. EINFÜHRUNG Allgemeines Begriffsdefinition Kommunikation Kennzeichnung der Schnittstellen-Eigenschaften Allgemeines Mindestanforderungen für EDV und GERÄT Kennzeichnung für EDV Kennzeichnung für GERÄT Beispiele für mögliche Kombinationen EDV / GERÄT SCHNITTSTELLEN-BESCHREIBUNG Identifikation der Komponenten (GDT-ID) Zeichensatz Kommunikation über Datei Dateinamen Verzeichnis Kommunikation über serielle Schnittstelle Hardware Ablauf der Kommunikation Beispiele zum Ablauf Kommentierte Beispiel-Dateien Aufbau einer BDT-Zeile: Beispieldatei Stammdaten übermitteln Beispieldatei Daten einer Untersuchung übermitteln...16 GDT V 2.1 (5/01) Seite 3 / 47

4 3. SATZTABELLE Definition der Satzarten: Stammdaten anfordern"6300" Definition der Satzarten: Stammdaten übermitteln "6301" Definition der Satzarten: Neue Untersuchung anfordern "6302" Definition der Satzarten: Daten einer Untersuchung übermitteln "6310" Definition der Satzarten: Daten einer Untersuchung übermitteln "6310" Definition der Satzarten: Daten einer Untersuchung übermitteln "6310" Definition der Satzarten: Daten einer Untersuchung zeigen "6311" FELDTABELLE REGELTABELLE ANHANG Anhang A Blockformat zur seriellen Datenübertragung mit Beispielen Übertragungsprotokoll Übertragungsblock Bedeutung der einzelnen Felder Beispiele Anforderung von Stammdaten Verhalten bei Übertragungsfehlern Beispiele für Übertragungen mit Übertragungsfehlern Anhang B Geräte- und verfahrensspezifisches Kennfeld "8402" Anhang C C-Programm zur Berechnung der CRC Anhang D: Borland Pascal 7. 0 Programm zur Berechnung der CRC GDT V 2.1 (5/01) Seite 4 / 47

5 1. Einführung 1.1 Allgemeines Die vorliegende Schnittstellenbeschreibung wurde vom QMS (Qualitätsring Medizinische Software) erarbeitet, um eine standardisierte Schnittstelle zwischen Praxis-EDV-Systemen und medizintechnischen Geräten zu definieren. Die Schnittstelle (Geräte-Daten-Träger - GDT) ist daher geräte-, hersteller- und fachgruppen-neutral ausgelegt. Sie kann sowohl von Standalone-Geräten, wie auch von PC-gestützten Meßgeräten realisiert werden. Sollte eine direkte Kommunikation gemäß 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 Praxis- EDV- und Gerätehersteller entwickeln. Eine Zertifizierung findet durch den QMS-Arbeitskreis GDT statt. ( Die Schnittstellenbeschreibung wird durch das Zentralinstitut als Anhang zur BDT-Satzbeschreibung übernommen.) Zielrichtung bei der Weiterentwicklung dieser Schnittstelle wird vor allem die Realisierung von PLUG and PLAY Lösungen zur Anbindung von medizintechnischen Geräten an Praxis-EDV sein, um den Installationsaufwand möglichst gering zu halten. 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) GERÄT = medizintechnisches Gerät (bzw. zugehöriges Treiberprogramm), Standalone-Einheit oder PC-gestütztes Meßgerät EDV = Praxis-EDV-System KOMPONENTE = jeder Teilnehmer am Datenaustausch, EDV oder GERÄT SERVER = KOMPONENTE, die auf externe Anfragen und Kommandos wartet und diese bearbeiten kann (-auch der Server in einem PC-Netzwerk reagiert nur auf Anfragen der Workstations) CLIENT = KOMPONENTE, die Anfragen und Kommandos aussendet Die Bezeichnungen CLIENT / SERVER werden hier ausschließlich zur Beschreibung des Sende- und Empfangsverhaltens verwendet, sind also unabhängig von EDV und GERÄT. Zum Installationszeitpunkt ist für die eingesetzten Komponenten festzulegen, wer als SERVER und wer als GDT V 2.1 (5/01) Seite 5 / 47

6 CLIENT arbeitet, um Konflikte zu vermeiden. Da der eigentliche Sinn einer Geräte-Anbindung in der Übermittlung von Untersuchungsdaten liegt, sollte eine EDV mindestens als SERVER (Verarbeiten von Untersuchungs-Daten) und ein GERÄT sollte 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 EDV erfolgt über Dateien, die in bestimmten Verzeichnissen unter bestimmten Namen (s.u.) angelegt werden. serielle Schnittstelle Das angeschlossene GERÄT (bzw. Treiberprogramm) kommuniziert über eine serielle Schnittstelle mit der EDV. Programm-Programm-Schnittstelle GERÄT und EDV unterstützen Programm-Programm-Schnittstellen (z.b. Clipboard, DDE, OLE, UNIX- Pipes u.ä.). Die vorliegende Version der Schnittstellenbeschreibung beschränkt sich zunächst jedoch auf die Kommunikation über serielle oder Datei-Schnittstelle. Eine Erweiterung auf Programm-Programm- Schnittstellen ist geplant. Da alle Nachrichten in Form von BDT-Sätzen übermittelt werden, ist das verwendete Datenformat unabhängig vom verwendeten Kommunikationsweg. GDT V 2.1 (5/01) Seite 6 / 47

7 1.4 Kennzeichnung der Schnittstellen-Eigenschaften Allgemeines Um die technische Beschreibung der Schnittstellenfähigkeit verschiedener KOMPONENTEN eindeutig festzulegen, wird eine spezielle Kennzeichnung verwendet, die für EDV und GERÄTE unterschiedlich definiert ist. Um festzustellen, ob eine bestimmte EDV 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 (seriell oder Datei) und mindestens eine SERVER-/CLIENT-Angabe übereinstimmen: Die technische Dokumentation eines GDT-fähigen GERÄTES, bzw. EDV muß daher eine entsprechende Angabe über die Art des realisierten GDT enthalten Mindestanforderungen für EDV und GERÄT EDV sollte mindestens als SERVER arbeiten, d.h. auf Satzart 6300 mit Satzart 6301 antworten und Satzarten 6310 verarbeiten können. GERÄT sollte mindestens als CLIENT arbeiten, d.h. Satzart 6310 senden können Kennzeichnung für EDV 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 EDV kann als SERVER arbeiten = 01 EDV kann als CLIENT arbeiten = 11 EDV kann als SERVER oder CLIENT arbeiten Beispiel: GDT-S-10 / GDT-D-11 (EDV kann seriell nur als SERVER, über Datei aber als SERVER und CLIENT arbeiten) GDT V 2.1 (5/01) Seite 7 / 47

8 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) Beispiele für mögliche Kombinationen EDV / GERÄT Folgende Komponenten können z.b. miteinander kommunizieren: EDV 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: EDV GERÄT GDT-S-11 GDT-D-11 GDT-SD-10 GDT-S-01 GDT V 2.1 (5/01) Seite 8 / 47

9 2. Schnittstellen-Beschreibung 2.1 Identifikation der Komponenten (GDT-ID) Die GDT-ID dient der eindeutigen Identifikation der an der Kommunikation beteiligten Komponenten 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 IDs geschieht, ist unbedingt auf eine eindeutige Vergabe zu achten, insbesondere bei GERÄTEN, die in einem Raum mehrfach vorhanden sind (z.b. 2 EKG-Schreiber des gleichen Herstellers). 2.2 Zeichensatz Der innerhalb der BDT-Felder 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. Der aktuell verwendete Zeichensatz wird in der Feldkennung 9206 definiert. 2.3 Kommunikation über Datei Dateinamen Die Übermittlung von Informationen erfolgt über an den BDT angelehnte Dateien, deren Datei-Name bei der Installation eindeutig festzulegen ist. Der Aufbau des Dateinamens ist wie folgt definiert: <Empfänger-Kürzel><Sender-Kürzel>. <hochzählende Nr> (z.b. EDV2GER.005) oder <Empfänger-Kürzel><Sender-Kürzel>. GDT (z.b. EDV2GER.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 fortlaufend für einen bestimmten Dateinamen vergeben wird. Die Dateizählung beginnt bei fortlaufender Extension mit.001 (führende Nullen). Damit ist sichergestellt, daß auch mehrere Dateien z.b. von einem GERÄT an die EDV GDT V 2.1 (5/01) Seite 9 / 47

10 geschickt werden können. Kann von bestimmten Systemen nur ein fester Dateiname unterstützt werden, so ist für diese Datei die Extension. GDT vorzusehen (z.b. EDV1EKG1.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 hochgezä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 Sendende die Kommunikationsdatei ohne Pausen beschreiben. Ist eine Verzögerung erforderlich, muß eine neue Datei mit fortlaufender Extension generiert werden. Es dürfen auch mehrere GDT-Sätze in einer Datei hintereinander vorkommen. In einer Datei dürfen mehrere unterschiedliche Satzarten auch von verschiedenen Patienten verwendet werden Verzeichnis Das Laufwerk und Verzeichnis, in dem die GDT-Kommunikationsdateien abgelegt werden, werden zum Installationszeitpunkt festgelegt, und sind bei der Geräte-/EDV-Konfiguration mit anzugeben. GDT V 2.1 (5/01) Seite 10 / 47

11 2.4 Kommunikation über serielle Schnittstelle 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) TxD Pin 2 (3) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ (2) Pin 3 RxD (Receive Data) RxD Pin 3 (2) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ (3) Pin 2 TxD (Transmit Data) GND Pin 7 (5) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ (5) Pin 7 GND (Signal Ground) RTS Pin 4 (7) ÄÄÄ ÚÄÄÄ (7) Pin 4 RTS (Request To Send) CTS Pin 5 (8) ÄÄÄÙ ÀÄÄÄ (8) Pin 5 CTS (Clear To Send) DTR Pin 20 (4) ÄÄÄ ÚÄÄÄ (4) Pin 20 DTR (Data Terminal Ready) DSR Pin 6 (6) ÄÄÄÙ ÀÄÄÄ (6) Pin 6 DSR (Data Set Ready) Ablauf der Kommunikation Als Datenfelder werden (-mit speziellen Kennungen-) die definierten BDT-Satz- und Feldkennungen verwendet. Alle BDT-Daten 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 Satzlängen und Zeilenlängen der übermittelten BDT-Dateien immer mit CR / LF berechnet (wie im BDT 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). GDT V 2.1 (5/01) Seite 11 / 47

12 2.5 Beispiele zum Ablauf Die Beispiele basieren auf der folgenden Praxis-Zusammenstellung mit den aufgeführten Komponenten. Die Praxis arbeitet mit der Praxis-Software "PRAX_EDV" (GDT-SD-11) und hat daran 3 Geräte angebunden: (1) Ein Phoropter (GDT-S-10), der über eine serielle Leitung angeschlossen ist, und nur auf Tastendruck Untersuchungsdaten an die EDV schicken kann (ohne eigene Stammdatenverwaltung) (EDV 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 (EDV 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-Meßplatz (GDT-D-10), mit eigener Stammdatenverwaltung, der vom Gerät aus bedient wird und mit der EDV kommuniziert (EDV ist SERVER / GERÄT ist CLIENT). Das Spirometrie-Programm heißt D:\LUFU SPIRO.exe. 1. Kommunikation zwischen Praxis-EDV und Phoropter (keine Möglichkeit zur Stammdatenverwaltung) EDV = SERVER GERÄT = CLIENT Messung am Phoropter wird durchgeführt! Tastendruck am GERÄT sendet Untersuchungsergebnisse als Satzart 6310 über die serielle Leitung! EDV empfängt Daten und ordnet sie dem aktuellen Patienten zu GDT V 2.1 (5/01) Seite 12 / 47

13 2. Kommunikation zwischen Praxis-EDV und EKG-Schreiber EDV = CLIENT GERÄT = SERVER Patient für die Untersuchung wird auf der Praxis- EDV ausgewählt! EDV schreibt Datei F: \ GDT \ EKG1EDV1.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 und löscht Datei F: \ GDT \ EKG1EDV1.001! Ruhe-EKG für den übergebenen Patienten wird durchgeführt.! GERÄT schreibt Datei F: \ GDT \ EDV1EKG1.001 mit Satzart 6310 zur Übermittlung der Ergebnisse, Beenden des Programmes und damit Wechsel zur Praxis-EDV! EDV liest und löscht Datei F: \ GDT \ EDV1EKG1.001 EDV ordnet Daten dem aktuellen Patienten zu GDT V 2.1 (5/01) Seite 13 / 47

14 3. Kommunikation zwischen Praxis-EDV und Lungenfunktions-Meßplatz EDV = SERVER GERÄT = CLIENT Patient für die Untersuchung steht auf der Praxis-EDV zur Verfügung! Tastendruck am GERÄT fordert Patienten an: GERÄT schreibt Datei F: \ GDT \ EDV_LUFU.001 mit Satzart 6300 zur Anforderung des aktuellen Patienten! EDV liest und löscht Datei F: \ GDT \ EDV_LUFU.001 EDV schreibt Datei F: \ GDT \ LUFU_EDV.001 mit Satzart 6301 zur Übermittlung des aktuellen Stammdatensatzes! GERÄT liest und löscht Datei F: \ GDT \ LUFU_EDV.001! Spirometrie für den übergebenen Patienten wird durchgeführt.! GERÄT schreibt Datei F: \ GDT \ EDV_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 \ EDV_LUFU.003 mit Satzart 6310 zur Übermittlung der Ergebnisse! EDV liest und löscht Dateien F: \ GDT \ EDV_LUFU.002 und EDV_LUFU.003 EDV ordnet Daten dem Patienten zu GDT V 2.1 (5/01) Seite 14 / 47

15 2.6 Kommentierte Beispiel-Dateien Aufbau einer BDT-Zeile: Schmidt<CR><LF> Zeilenlänge inkl. CR LF Feldkennung des Zeileninhalts Inhalt des jeweiligen BDT-Feldes Zeilenende (CR LF / 0D 0A hex) Beispieldatei Stammdaten übermitteln ; Satzart Stammdaten übermitteln ; Dateilänge EKG_TYP1 ; GDT-ID des Empfängers (z.b. EKG-Schreiber) PRAX_EDV ; GDT-ID des Senders ; Versions-Nr. GDT ; Patienten-Nummer Mustermann ; Nachname Franz ; Vorname ; Geburtsdatum ; Geschlecht (1=männlich) ; Größe ; Gewicht = CR und LF (0D 0A hex) Jede Zeile ist mit CR und LF (0D 0A hex) abzuschließen. GDT V 2.1 (5/01) Seite 15 / 47

16 2.6.3 Beispieldatei Daten einer Untersuchung übermitteln ; Satzart ; Dateilänge PRAX_EDV ; GDT-ID des Empfängers LZBD_SYS ; GDT-ID des Senders ; Versions-Nr. GDT ; Patienten-Nummer Mustermann ; Nachname Franz ; Vorname ; Geburtsdatum ; Geschlecht (1=männlich) ; Größe ; Gewicht BDM01 ; Untersuchung: 24h-Blutdruck ; Datum der Untersuchung Dies ist ein zweizeiliger ; Befund 1. Zeile Befund zur 24h-Blutdruckmessung. ; Befund 2. Zeile Anmerkungen zu einer Langzeit-Blutdruckmessung. ; Kommentar Kurzzusammenfassung 24 h Blutdruckmessung ; formatierter Ergebnistext Tagphase Nachtphase proz. Abfall :00-22:00 22:00-06:00 Tag/Nacht Ps[mmHg] % Pd[mmHg] % HF[P/min] % SYSMXTG ; Test-Ident (Hersteller-spez.) Systole max Tagphase ; Testbezeichnung ; Wert mmHg ; Einheit ; Datum Meßwert ; Uhrzeit Meßwert ; oberer Grenzwert SYSMNTG ; nächster Test-Ident Systole min Tagphase ; Testbezeichnung ; Wert mmHg ; Einheit ; Datum dieses Meßwertes ; Uhrzeit dieses Meßwertes = Leerzeichen ( 20 hex / 32 dez ) = CR und LF ( 0D 0A hex ) GDT V 2.1 (5/01) Seite 16 / 47

17 3. Satztabelle Im folgenden werden die für die Anbindung medizintechnischer Geräte definierten Sätze 6300, 6301, 6302, 6310 und 6311 beschrieben. Jeder Satz beginnt mit dem Feld "8000", das die jeweilige Satzkennung enthält. 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: MG " PCS 6301: PCS " MG 6302: PCS " MG 6310: MG " PCS 6311: PCS " MG MG = Medizingerät PCS = Praxiscomputersystem GDT V 2.1 (5/01) Seite 17 / 47

18 3.1 Definition der Satzarten: Stammdaten anfordern"6300" SA 6300 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/K Bedingung Satzidentifikation M Satzart Stammdaten anfordern Satzlänge M Länge dieses Satzes GDT - ID des Empfängers K GDT - ID des Senders K verwendeter Zeichensatz K 1=7Bit, 2=IBM(Standard) CP 437, 3=ISO8859-1(ANSI) CP Version GDT M Patientennummer / Patientenkennung M Sofern ein GERÄT nicht in der Lage ist, die Pat.Nr. zu übermitteln, ist der Wert 0 oder ein leerer Inhalt zu senden. Damit werden die Daten des aktuellen Patienten angefordert. GDT V 2.1 (5/01) Seite 18 / 44

19 3.2 Definition der Satzarten: Stammdaten übermitteln "6301" SA 6301 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/K Bedingung Satzidentifikation M Satzart Stammdaten übermitteln Satzlänge M Länge dieses Satzes GDT - ID des Empfängers K GDT - ID des Senders K verwendeter Zeichensatz K 1=7Bit, 2=IBM(Standard) CP 437, 3=ISO8859-1(ANSI) CP Version GDT M Patientennummer / Patientenkennung M Namenszusatz / Vorsatzwort des Patienten K z.b. Freiherr von Name des Patienten M Vorname des Patienten M Geburtsdatum des Patienten M TTMMJJJJ Titel des Patienten K Versichertennummer des Patienten K Wohnort des Patienten K PLZ ORT Straße des Patienten K Straße und Hausnummer Versichertenart K 1=Mitglied, 3=Familienversicherter, 5=Rentner Geschlecht des Patienten K 1=männlich, 2=weiblich Größe des Patienten K Gewicht des Patienten K Muttersprache des Patienten K GDT V 2.1 (5/01) Seite 19 / 44

20 3.3 Definition der Satzarten: Neue Untersuchung anfordern "6302" SA 6302 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/K Bedingung Satzidentifikation M Satzart Neue Untersuchung anfordern Satzlänge M Länge dieses Satzes GDT - ID des Empfängers K GDT - ID des Senders K verwendeter Zeichensatz K 1=7Bit, 2=IBM(Standard) CP 437, 3=ISO8859-1(ANSI) CP Version GDT M Softwareverantwortlicher (SV) K z.b. Firma Software K Name der Software Release-Stand der Software K Software Versionsnummer Patientennummer / Patientenkennung M Namenszusatz / Vorsatzwort des Patienten K z.b. Freiherr von Name des Patienten M Vorname des Patienten M Geburtsdatum des Patienten M TTMMJJJJ Titel des Patienten K Versichertennummer des Patienten K Wohnort des Patienten K PLZ ORT Straße des Patienten K Straße und Hausnummer Versichertenart K 1=Mitglied, 3=Familienversicherter, 5=Rentner Geschlecht des Patienten K 1=männlich, 2=weiblich Größe des Patienten K Gewicht des Patienten K Muttersprache des Patienten K Geräte und verfahrensspezifisches Kennfeld K Typ der angeforderten Untersuchung, z.b. EKG01 (siehe Anhang B) Test-Ident K GDT V 2.1 (5/01) Seite 20 / 44

21 3.4 Definition der Satzarten: Daten einer Untersuchung übermitteln "6310" SA 6310 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/K Bedingung Satzidentifikation M Satzart Daten einer Untersuchung übermitteln Satzlänge M Länge dieses Satzes GDT - ID des Empfängers K GDT - ID des Senders K verwendeter Zeichensatz K 1=7Bit, 2=IBM(Standard) CP 437, 3=ISO8859-1(ANSI) CP Version GDT M Softwareverantwortlicher (SV) K z.b. Firma Software K Name der Software Release-Stand der Software K Software Versionsnummer Patientennummer / Patientenkennung M Sofern ein GERÄT derzeit nicht in der Lage ist, die Pat.Nr. zu übermitteln, ist der Wert 0 zu senden. Die Daten sind dann von der EDV dem entsprechenden Patienten zuzuordnen Namenszusatz / Vorsatzwort des Patienten K z.b. Freiherr von Name des Patienten K Vorname des Patienten K Geburtsdatum des Patienten K TTMMJJJJ Titel des Patienten K Versichertennummer des Patienten K Wohnort des Patienten K PLZ ORT Straße des Patienten K Straße und Hausnummer Versichertenart K Geschlecht des Patienten K 1=Mitglied, 3=Familienversicherter, 5=Rentner Größe des Patienten K 1=männlich, 2=weiblich Gewicht des Patienten K Muttersprache des Patienten K Geräte und verfahrensspezifisches Kennfeld M Typ der durchgeführten Untersuchung, z.b. EKG01 (siehe Anhang B) GDT V 2.1 (5/01) Seite 21 / 44

22 3.4 Definition der Satzarten: Daten einer Untersuchung übermitteln "6310" SA 6310 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/K Bedingung Tag der Erhebung von Behandlungsdaten K TTMMJJJJ Datum der Untersuchung Uhrzeit der Erhebung von Behandlungsdaten K HHMMSS ; Zeit (6stellig) der anzuzeigenden Untersuchung 6205 n Aktuelle Diagnose K 6220 n Befund K 6221 n Fremdbefund K z.b. vom Gerät automatisch erzeugter Befundhinweis 6227 n Kommentar K 6226 n Anzahl der nachfolgend Fortsetzungszeilen der Kennung 6228 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 Gesamtzeile die vom Empfänger zusammengestzt werden sollte n Ergebnistabellentext, formatiert K beliebiger Ergebnistext, vom Gerät formatiert 6202 n Datei-Archivierungskenner K Kenner zur Klassifizierung der Daten Dateiformat m falls 6302 vorhanden Formatbeschreibung (z.b. PDF) Dateiinhalt m falls 6302 vorhanden Beschreibung, was unter der(n) folgenden Adresse(n) (WWW Adresse oder UNC-Pfad) zu finden ist. z.b. Protokolle, Untersuchungsdaten Verweis auf die Datei m falls 6302 vorhanden Uniform Resource Locator (WWW-Adresse oder UNC-Pfad) z.b. \\FS1\TEST\BILD1.PDF 6330, 6332, 6334,..., , 6333, 6335,..., 6399 n Name der freien Kategorie K Gerade und darauf folgende ungerade Kennung gehören jeweils als Wertepaar zusammen. 1 Inhalt der freien Kategorie m falls vorhergehende Kennung Name der freien Kategorie existiert. GDT V 2.1 (5/01) Seite 22 / 44

23 3.4 Definition der Satzarten: Daten einer Untersuchung übermitteln "6310" SA 6310 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/K Bedingung 8410 n Test-Ident m 20 Zeichen alnum Header zur Übermittlung einzelner Meßwerte-Gruppen falls Feld(er) > = 8411 < = Testbezeichnung K Probenmaterial-Ident K Probenmaterial-Index K Probenmaterial-Bezeichnung K 8431 n Probenmaterial-Spezifikation K Einheiten(en) für Datenstrom m falls Feld(er) 8438 <> (leer) z.b. Hz, dba 8438 n Datenstrom K z.b. (50,-30),(100,-20),(150,-22),(200,-17),...usw Teststatus K B = bereits berichtet, K = korrigierter Wert oder fehlt Ergebnis-Wert K Einheit m falls Feld(er) 8420, 8461, 8462 <> (leer) Abnahme-Datum K TTMMJJJJ ; Datum der Einzelmessung Abnahme-Zeit K HHMMSS ; Zeit (6stellig) der Einzelmessung Normalwert-Text K Normalwert untere Grenze K Wert wird in der Einheit 8421 übermittelt Normalwert obere Grenze K Wert wird in der Einheit 8421 übermittelt 8470 n Anmerkung K testbezogener Hinweis 8480 n Ergebnis-Text K Signatur K Name / Kürzel des Durchführenden GDT V 2.1 (5/01) Seite 23 / 44

24 3.5 Definition der Satzarten: Daten einer Untersuchung zeigen "6311" SA 6311 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/K Bedingung Satzidentifikation M Satzart Daten einer Untersuchung zeigen Satzlänge M Länge dieses Satzes GDT - ID des Empfängers K GDT - ID des Senders K verwendeter Zeichensatz K 1=7Bit, 2=IBM(Standard) CP 437, 3=ISO8859-1(ANSI) CP Version GDT M Patientennummer / Patientenkennung M Sofern eine EDV nicht in der Lage ist, die Pat.Nr. zu übermitteln, ist der Wert 0 oder ein leerer Inhalt zu senden. Damit werden die Daten einer Untersuchung des aktuellen Patienten dargestellt Namenszusatz / Vorsatzwort des Patienten K z.b. Freiherr von Name des Patienten K Vorname des Patienten K Geburtsdatum des Patienten K TTMMJJJJ Titel des Patienten K Tag der Erhebung von Behandlungsdaten K TTMMJJJJ Datum der anzuzeigenden Untersuchung Uhrzeit der Erhebung von Behandlungsdaten K HHMMSS ; Zeit (6stellig) der anzuzeigenden Untersuchung Geräte und verfahrensspezifisches Kennfeld K Typ der anzuzeigenden Untersuchung z.b. ERGO00 (siehe Anhang B) Abnahme-Datum K TTMMJJJJ ; Datum der anzuzeigenden Einzelmessung Abnahme-Zeit K HHMMSS ; Zeit (6stellig) der anzuzeigenden Einzelmessung GDT V 2.1 (5/01) Seite 24 / 44

25 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, in der 1. Version neue Feldkennung, die in Abstimmung mit dem Zentralinstitut eigens für den GDT vergeben wurde *R = Regeländerung, in der 1. Version Regelnummer für Format-/Inhaltsprüfungen, die nicht vom KBV-Prüfmodul abgedeckt werden *Nx.x = Neues Feld ab Version x.x FK Bezeichnung Länge Typ Regel Beispiel *N Softwareverantwortlicher (SV) <=60 alnum Firma xxx *N Software <=60 alnum PraxisMed *N Release-Stand der Software <=60 alnum Version 4.30b 3000 Patientennummer / <=10 alnum Patientenkennung 3100 Namenszusatz / Vorsatzwort des <=15 alnum von Patienten 3101 Name des Patienten <=28 alnum Schmitz 3102 Vorname des Patienten <=28 alnum Erna 3103 Geburtsdatum des Patienten 8 datum 020/ Titel des Patienten <=15 alnum Dr Versichertennummer <=12 alnum M789 des Patienten 3106 Wohnort des Patienten <=30 alnum Köln 3107 Straße des Patienten <=28 alnum Holzweg Versichertenart MFR 1 num Geschlecht des Patienten 1 num Größe des Patienten in cm var float Gewicht des Patienten in kg var float Muttersprache des Patienten <=60 alnum türkisch 6200 Tag der Erhebung von Behandlungsdaten 8 datum GDT V2.1 (5/00) Seite 25 / 47

26 FK Bezeichnung Länge Typ Regel Beispiel 6201 Uhrzeit der Erhebung von 6 zeit 090 HHMMSS Behandlunsdaten 6205 Aktuelle Diagnose <=60 alnum Diabetes 6220 Befund <=60 alnum erhöhter Blutdruck 6221 Fremdbefund <=60 alnum Verdacht auf Obstruktion *N Anzahl Folgezeilen <=4 num 2 *N 6227 Kommentar <=60 alnum Belastung abgebrochen *N 6228 Ergebnistabellentext, formatiert <=60 alnum s. Beispiele im Anhang *N Datei-Archivierungsnummer <=60 alnum *N Dateiformat <=60 alnum PDF *N Dateiinhalt <=60 alnum Datenanalyse *N Verweis auf Datei (URL) <=60 alnum \\FS1\DATA\00712.PDF *N Name der freien Kategorie <=60 alnum 6398 *N Inhalt der freien Kategorie <=60 alnum Satzidentifikation 4 alnum Satzlänge 5 num *N 8315 GDT - ID des Empfängers 8 alnum ROP200U1 *N 8316 GDT - ID des Senders 8 alnum PRAX_EDV *L 8402 Geräte und verfahrensspez. <=6 alnum EKG01, siehe Anhang B Kennfeld 8410 Test-Ident <=20 alnum FEV Testbezeichnung <=60 alnum Obj. refr. cyl. rechts 8418 Teststatus 1 alnum B 8420 Ergebnis-Wert var float Einheit <=60 alnum dpt 8428 Probenmaterial-Ident <=8 alnum 8429 Probenmaterial-Index 2 num 8430 Probenmaterial-Bezeichnung <=60 alnum 8431 Probenmaterial-Spezifikation <=60 alnum 8432 Abnahme-Datum 8 datum GDT V2.1 (5/00) Seite 26 / 47

27 FK Bezeichnung Länge Typ Regel Beispiel *N 8437 Einheit (en) für Datenstrom <=60 alnum min, mmhg, mmhg *N 8438 Datenstrom <=60 alnum 5,120,80... oder (5,120,80),(10,128,92).. kann Float-Werte enthalten. *N *R 8439 Abnahme-Zeit 6 zeit 090 HHMMSS Normalwert-Text <=60 alnum *N 8461 Normalwert untere Grenze var float -15 *N 8462 Normalwert obere Grenze var float Testbezogene Hinweise <=60 alnum 8480 Ergebnis-Text <=60 alnum 8990 Signatur <=60 alnum Dr. Huber *N verwendeter Zeichensatz 1 num 2 *N 9218 Version GDT 5 alnum 01.00, oder datum = Datumsangabe TTMMJJJJ num = numerisch, bei festen Feldlängen ist das Feld mit führenden Nullen aufzufüllen alnum = alphanumerisch float = Fließkommazahl mit Punkt als Dezimaltrennzeichen GDT V2.1 (5/00) Seite 27 / 47

28 5. Regeltabelle Regeln sind entsprechend ihrer Art in Nummernkreise unterteilt: Formatprüfungen Inhaltsprüfungen Existenzprüfungen Kontextprüfungen Regelnr. Kategorie Prüfung Erläuterung 008 Format TTMMJJJJ TT=Tag;MM=Monat;JJJJ=Jahr 020 Format TTMMJJJJ Wertebereich: TT=00-31 MM=00-12 /JJJJ= ) 090 Format HHMMSS HH=Stunde;MM=Minute;SS=Sekunde Wertebereich: HH=00-24 / MM=00-59 / SS=00-59 (evt. fehlende Sekunden sind mit 00 anzugeben) 112 erlaubter Inhalt 1, erlaubter Inhalt 1, 3, 5 Versichertenart MFR 304 Kontext Datum kleiner oder gleich Maschinendatum Vermeidung von Fehleingaben GDT V2.1 (5/00) Seite 28 / 47

29 6. ANHANG 6.1 Anhang A Blockformat zur seriellen Datenübertragung mit Beispielen Übertragungsprotokoll Die BDT-Datei wird in Blöcken übertragen. Der Empfang eines Übertragungsblocks ist innerhalb von 10 s 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 Übertragungsblock Ein Übertragungsblock ist folgendermaßen aufgebaut: <Sende-Sequenz-Zähler> <Kennung> [<Datenfeld>] <CRC-16> <CR> Bedeutung der einzelnen Felder Sende-Sequenz-Zähler Länge: 1 Byte. Der Sende-Sequenz-Zähler wird zyklisch von 1 (31h) bis 9 (39h) 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 Übertragung nach dem Einschalten und nach Auftreten von Übertragungsfehlern verwendet. Kennung Länge: 3 Byte Es werden folgende Kennungen definiert: B00 Beginn einer BDT-Datenübertragung / erster BDT-Datenblock B01 BDT-Datenblock B02 Ende einer BDT-Datenübertragung / letzter BDT-Datenblock Datenfeld Länge: max. 128 Byte Das Datenfeld enthält die eigentlichen BDT-Daten. Mehrere BDT-Zeilen können zu einem Datenfeld zusammengefaßt werden. Eine BDT-Zeile kann auch auf mehrere Datenfelder verteilt werden. Als Trennung zwischen zwei BDT-Zeilen wird das Zeichen 1Ch (Feldseparator FS) verwendet. GDT V2.1 (5/00) Seite 29 / 47

30 Die BDT-Satzlänge und -Zeilenlängen werden aber 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. Wird als ASCII-Hex gesendet. Z.B. 2A9Eh als 32h 41h 39h 45h. (Zur Generierung der Checksumme siehe Anhang C) CR Länge: 1 Byte Carriage Return (0Dh) schließt den Übertragungsblock ab Beispiele Hinweis: Das Zeichen ' ' steht für den Feldseparator (1Ch). Zur Veranschaulichung wurde die Datenfeldlänge auf 32 Zeichen begrenzt Anforderung von Stammdaten Client sendet: C: 1B QMS-STAR 017 <CRC> <CR> S: <ACK> 1 C: 2B ROP200U <CRC> <CR> S: <ACK> 1 Server antwortet: S: 7B <CRC> <CR> C: <ACK> 1 S: 8B ROP200U QMS-STAR <CRC> <CR> C: <ACK> 1 S: 9B Axt Berta <CRC> <CR> C: <ACK> 1 S: 1B <CRC> <CR> C: <ACK> 1 GDT V2.1 (5/00) Seite 30 / 47

31 6.1.6 Verhalten bei Übertragungsfehlern Bei Empfang von <ACK> 0 bzw. nach Auftreten eines Timeouts wird der letzte Übertragungsblock nochmals gesendet. Tritt ein Fehler zum zweiten Mal hintereinander auf, wird der Sende-Sequenz-Zähler auf 0 gesetzt und die Übertragung vom ersten BDT-Datenblock an wiederholt. Nach dem zweiten erfolglosen Versuch, die BDT-Datei zu übertragen, bricht der Sender die Übertragung ab. Die Fehlerbehandlung erfolgt in einer der höheren Schichten Beispiele für Übertragungen mit Übertragungsfehlern Wiederholung eines Übertragungsblocks C: 1B QMS-STAR 017 <CRC> <CR> S: <ACK> 1 C: 2B ROP200U <CRC> <CR> S: <ACK> 0 ; Fehler aufgetreten C: 2B ROP200U <CRC> <CR> ; Block nochmals senden mit gleichem Sende-Sequenz-Zähler (hier 2) S: <ACK> 1 ; diesmal Block richtig empfangen Synchronisation nach Übertragungsfehlern C: 1B QMS-STAR 017 <CRC> <CR> S: <ACK> 1 C: 2B ROP200U <CRC> <CR> S: <ACK> 0 ; Fehler aufgetreten C: 2B ROP200U <CRC> <CR> S: <ACK> 0 ; Fehler erneut aufgetreten C: 0B QMS-STAR 017 <CRC> <CR> ; neue Synchronisation mit ; Sequenzzähler 0 S: <ACK> 1 C: 1B ROP200U <CRC> <CR> S: <ACK> 1 GDT V2.1 (5/00) Seite 31 / 47

32 Abbruch einer Übertragung nach Übertragungsfehlern C: 1B MEDISTAR 017 <CRC> <CR> S: <ACK> 1 C: 2B ROP200U <CRC> <CR> S: <ACK> 0 ; Fehler aufgetreten C: 2B ROP200U <CRC> <CR> S: <ACK> 0 ; Fehler aufgetreten C: 0B QMS-STAR 017 <CRC> <CR> S: <ACK> 1 C: 2B ROP200U <CRC> <CR> S: <ACK> 0 ; Fehler aufgetreten C: 2B ROP200U <CRC> <CR> S: <ACK> 0 Sender bricht Übertragung ab. Empfänger bleibt empfangsbereit. Übertragungsfehler bei Stammdatenanforderung Das Problem, daß sowohl Client als auch Server versuchen, eine BDT-Datei zu senden, kann z.b. folgendermaßen entstehen: C: 1B QMS-STAR 017 <CRC> <CR> S: <ACK> 1 C: 2B ROP200U <CRC> <CR> S: [<ACK> 1] ; Empfangsbestätigung vom Server zwar geschickt, kommt aber nicht beim Client an C: 2B ROP200U <CRC> <CR> ; erneutes Senden des gleichen Blocks S: 7B <CRC> <CR> ; Server sendet bereits 1. Block der angeforderten Stammdaten C: 0B QMS-STAR 017 <CRC> <CR> ; erneutes Senden durch Client mit neuer Synchronisation S: 7B <CRC> <CR> ; Server wiederholt den 1. Block der Stammdaten (ACK 1 vom Client fehlt) C: 0B QMS-STAR 017 <CRC> <CR> ; Client wiederholt den GDT V2.1 (5/00) Seite 32 / 47

33 Synchronisationsversuch S: 0B <CRC> <CR> ; erneutes Senden durch Server mit neuer Synchronisation S: 0B <CRC> <CR> ; Server wiederholt den Synchronisationsversuch Die Übertragung wird nach Timeout ( warten auf ACK ) von Server und Client abgebrochen (vgl ). GDT V2.1 (5/00) Seite 33 / 47

34 6.2 Anhang B Geräte- und verfahrensspezifisches Kennfeld "8402" Das Feld 8402 wurde im Rahmen der Überarbeitung des BDT (Anbindung und Datenübermittlung medizintechnischer Geräte) wie folgt neu definiert: Feldkennung: 8402 Bezeichnung: Funktion: Typ: Regel: Geräte- und verfahrensspezifisches Kennfeld Das Feld dient zur Gruppierung der zu übermittelnden Daten. Der bisherige Typ von 2 (alnum) wurde auf 1-6 (alnum) erweitert. Der Feldinhalt besteht aus einem Textteil mit maximal 4 Buchstaben als Gruppenkennung, sowie einer anschließenden 2-stelligen Numerierung 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 Gruppe 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 aufgeführten Gruppen und Feldinhalte sind daher nur als eine erste Zusammenstellung zu betrachten, die beliebig erweiterbar ist. Im Gegensatz zur Kennung 8402 können die jeweiligen Testidents (Kennung 8410) herstellerspezifisch vergeben werden (vgl. Anhang B des BDT 2/94). GDT V2.1 (5/00) Seite 34 / 47

35 ALLE ALLE01 ALLE02 ALLE03 ALLE04 ALLE05 ALLE06 ALLE07 ALLE08 ALLE09 ALLE10 Allergologie Anamneseerfassung allergolisch Befunderfassung allergologisch Diagnoseerfassung allergologisch Pricktest Intracutantest Provokationstest Invitrotest Insektengift Epikutantest tägliche Hyposensibilisierungsbehandlung ALLG ALLG00 nicht näher spezifizierte Untersuchungen Untersuchungen, allgemein APNO APNO00 APNO01 APNO02 Apnoe, allgemein Langzeit Schlafapnoe Screening Polysomnographie Schlaf-Apnoe-Untersuchungen AUDI AUDI00 AUDI01 AUDI02 Audiometrie, allgemein Reinton-Schwellen-Audiogramm EEG-Audiometrie Audiometrische Untersuchungen BDM BDM00 BDM01 Blutdruckmessung,allgemein Langzeit-Blutdruckmessung Blutdruckmessung EKG Elektrokardiographie GDT V2.1 (5/00) Seite 35 / 47

36 EKG00 EKG01 EKG02 EKG03 EKG04 EKG, allgemein Ruhe-EKG Arrhythmie-EKG Spätpotential-EKG Langzeit-EKG ERGO ERGO00 ERGO01 ERGO02 ERGO03 ERGO04 ERGO05 ERGO06 ERGO07 ERGO08 ERGO09 ERGO10 ERGO11 Belastungs-Untersuchungen Belastungs-Untersuchung, allgemein Belastungs-EKG Fluß-Volumen unter Belastung Blutgase Blutgase unter Belastung Spiroergometrie Atemgasanalyse Pulsoximetrie Indirekte Kalorimetrie Indirekte Kalorimetrie mit Haube HZV-Bestimmung über CO2-Rückatmung Atemantriebsmessung über CO2-Rückatmung HÄMA Blutbilder HÄMA01 kleines Blutbild HÄMA02 großes Blutbild HÄMA03 manuelles Differentialblutbild HÄMA04 Retikulozyten HÄMA05 CD4/CD8 LUFU LUFU00 LUFU01 LUFU02 LUFU03 LUFU04 LUFU05 Lungenfunktions-Messung Lungenfunktion, allgemein Langsame Spirometrie Forcierte Spirometrie (Fluß-Volumen) MVV (Maximal Voluntary Ventilation) Bodyplethysmographie FRC pl (Lungenvolumen - Bodyplethysmographie) GDT V2.1 (5/00) Seite 36 / 47

37 LUFU06 FRC He (Lungenvolumen - Helium Rückatmung) LUFU07 Resistance nach Verschlußdruckmethode 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 Ruheatmungsanalyse NEUR NEUR00 NEUR01 NEUR02 NEUR03 NEUR04 NEUR05 NEUR06 NEUR07 NEUR08 NEUR09 NEUR10 NEUR11 NEUR12 Neurologische Messung Neurologie, allgemein Langzeit-EEG EEG mit simultaner EKG-Aufzeichnung Motorisches NLG Sensorisches NLG Evozierte Potentiale Rotationstest Nystagmusanalyse Sakkadentest Posture Biofeedback ERG/EOG EMG der Augenmuskeln OPTO OPTO00 OPTO01 OPTO02 OPTO03 OPTO04 Augenheilkunde Augenheilkunde, allgemein Refraktionsbestimmung, objektiv Refraktionsbestimmung, subjektiv Refraktionswerte Brille/Kontaktlinse Blendenempfindlichkeitsmessung (Visus) GDT V2.1 (5/00) Seite 37 / 47

38 OPTO05 OPTO06 OPTO07 OPTO08 OPTO09 OPTO10 OPTO11 OPTO12 OPTO13 OPTO14 Gesichtsfeldmessung Augendruckmessung Hornhautmessung (Krümmungsradien/Achslagen) Hornhautmessung (3D-Geometriedaten) Fundusbilder Angiographiebilder Spaltlampenbilder Topographiebilder Schichtbilder generische Bilddaten PROV PROV00 PROV01 PROV02 PROV03 PROV04 Provokations-Test Provokation, allgemein Spezifische Aerosol-Provokation Unspezifische Aerosol-Provokation Kaltluft Provokation Bronchodilatation SONO SONO00 SONO01 Sonographie, allgemein Ultraschall-Doppler Sonographie-Messungen URO URO00 URO01 Urologie, allgemein Uroflowmetrie Urologie GDT V2.1 (5/00) Seite 38 / 47

39 6.3 Anhang C C-Programm zur Berechnung der CRC-16 short crc16(char *s, short len) { short bte, crc, i; } crc = 0; while (len > 0) { len = len - 1; bte = *s; s = s + 1; i = 8; while (i > 0) { i = i - 1; if (bte & 0x0080) { crc = crc ^ 0x8000; } if (crc & 0x8000) { crc = crc << 1; crc = crc ^ 0x8005; } else { crc = crc << 1; } bte = bte << 1; } } return crc; 6.4 Anhang D: Borland Pascal 7. 0 Programm zur Berechnung der CRC-16 GDT V2.1 (5/00) Seite 39 / 47

40 program Crc16Dem; { CRC16-Demo für Borland Pascal 7.0 } {$B-,I+,P+,T-,X+} function UpdateCrc16 (InitCrc: Word; var Data; Len: Word): Word; { CRC-16-Weiterberechnung, InitCrc sollte beim 1. Block 0 sein } type CrcByteArray = array[ ] of Byte; var Crc, I, J: Word; B : Byte; begin Crc := InitCrc; for I := 1 to Len do begin B := CrcByteArray(Data)[I]; for J := 1 to 8 do begin if (B and $80) <> 0 then Crc := Crc xor $8000; if (Crc and $8000) <> 0 then begin Crc := Crc shl 1; Crc := Crc xor $8005; end else Crc := Crc shl 1; B := B shl 1; end; end; UpdateCrc16 := Crc; end; function Crc16 (var Data; Len: Word): Word; { CRC-16-Berechnung, InitCrc := 0 } begin Crc16 := UpdateCrc16(0, Data, Len); end; function Crc16Str (const St: String): Word; { CRC-16-Berechnung fr Strings unter Nichtbercksichtigung des L ngenbytes } type TDataStr = record Len: Byte; GDT V2.1 (5/00) Seite 40 / 47

41 Data: array[1..255] of Char; end; var DataStr: ^TDataStr; begin DataStr Crc16Str := Crc16(DataStr^.Data, DataStr^.Len); end; begin { Crc16Dem } if ParamCount = 0 then WriteLn('Aufruf: crcdemo Demostring') else begin Write(ParamStr(1) + ': '); WriteLn(Crc16Str(ParamStr(1))); end; end. GDT V2.1 (5/00) Seite 41 / 47