QUALITÄTSRING MEDIZINISCHE SOFTWARE e.v. Vorwort

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 onsensarbeit 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!! GDT V2. (5/0) Seite von 4

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. (5/200) GDT V2. (5/0) Seite 2 von 4

3 Inhaltsverzeichnis. Allgemeines Begriffsdefinition ommunikation ennzeichnung der Schnittstellen-Eigenschaften Allgemeines Mindestanforderungen für EDV und GERÄT ennzeichnung für EDV ennzeichnung für GERÄT Beispiele für mögliche ombinationen EDV / GERÄT SCHNITTSTELLEN-BESCHREIBUNG Identifikation der omponenten (GDT-ID) Zeichensatz ommunikation über Datei Dateinamen Verzeichnis ommunikation über serielle Schnittstelle Hardware Ablauf der ommunikation Beispiele zum Ablauf ommentierte Beispiel-Dateien Aufbau einer BDT-Zeile: Beispieldatei Stammdaten übermitteln Beispieldatei Daten einer Untersuchung übermitteln SATZTABELLE... 7 GDT V2. (5/0) Seite 3 von 4

4 3. Definition der Satzarten: Stammdaten anfordern"6300" Definition der Satzarten: Stammdaten übermitteln "630" Definition der Satzarten: Neue Untersuchung anfordern "6302" Definition der Satzarten: Daten einer Untersuchung übermitteln "630" Definition der Satzarten: Daten einer Untersuchung übermitteln "630" Definition der Satzarten: Daten einer Untersuchung übermitteln "630" Definition der Satzarten: Daten einer Untersuchung zeigen "63" 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 ennfeld "8402" Anhang C C-Programm zur Berechnung der CRC Anhang D: Borland Pascal 7. 0 Programm zur Berechnung der CRC GDT V2. (5/0) Seite 4 von 4

5 . Einführung. 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 ommunikation 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..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 OMPONENTE = jeder Teilnehmer am Datenaustausch, EDV oder GERÄT SERVER = OMPONENTE, die auf externe Anfragen und ommandos wartet und diese bearbeiten kann (-auch der Server in einem PC-Netzwerk reagiert nur auf Anfragen der Workstations) CLIENT = OMPONENTE, die Anfragen und ommandos 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. GDT V2. (5/0) Seite 5 von 4

6 Zum Installationszeitpunkt ist für die eingesetzten omponenten festzulegen, wer als SERVER und wer als CLIENT arbeitet, um onflikte 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..4)..3 ommunikation Prinzipiell ist eine Datenkommunikation über drei verschiedene Mechanismen möglich: Datei-Schnittstelle Die ommunikation 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 ommunikation ü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 ommunikationsweg. GDT V2. (5/0) Seite 6 von 4

7 .4 ennzeichnung der Schnittstellen-Eigenschaften.4. Allgemeines Um die technische Beschreibung der Schnittstellenfähigkeit verschiedener OMPONENTEN eindeutig festzulegen, wird eine spezielle ennzeichnung 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-ennzeichnungen überprüft werden. Eine ommunikation 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..4.2 Mindestanforderungen für EDV und GERÄT EDV sollte mindestens als SERVER arbeiten, d.h. auf Satzart 6300 mit Satzart 630 antworten und Satzarten 630 verarbeiten können. GERÄT sollte mindestens als CLIENT arbeiten, d.h. Satzart 630 senden können..4.3 ennzeichnung 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> = 0 EDV kann als SERVER arbeiten = 0 EDV kann als CLIENT arbeiten = EDV kann als SERVER oder CLIENT arbeiten Beispiel: GDT-S-0 / GDT-D- (EDV kann seriell nur als SERVER, über Datei aber als SERVER und CLIENT arbeiten) GDT V2. (5/0) Seite 7 von 4

8 .4.4 ennzeichnung 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> = 0 GERÄT kann als SERVER arbeiten = 0 GERÄT kann als CLIENT arbeiten = GERÄT kann als SERVER oder CLIENT arbeiten Beispiel: GDT-D-0 (GERÄT kann nur über Datei als CLIENT arbeiten).4.5 Beispiele für mögliche ombinationen EDV / GERÄT Folgende omponenten können z.b. miteinander kommunizieren: EDV GERÄT GDT-S- GDT-SD-0 GDT-D-0 GDT-D- GDT-SD-0 GDT-S-0 Folgende omponenten können z.b. nicht miteinander kommunizieren: EDV GDT-S- GDT-SD-0 GERÄT GDT-D- GDT-S-0 GDT V2. (5/0) Seite 8 von 4

9 2. Schnittstellen-Beschreibung 2. Identifikation der omponenten (GDT-ID) Die GDT-ID dient der eindeutigen Identifikation der an der ommunikation beteiligten omponenten 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 EG-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 ommunikation über Datei 2.3. 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-ürzel><Sender-ürzel>. <hochzählende Nr> (z.b. EDV2GER.005) oder <Empfänger-ürzel><Sender-ürzel>. GDT (z.b. EDV2GER.GDT) Der Dateiname setzt sich aus max. 4 Zeichen als ürzel für den Empfänger und max. 4 Zeichen als ürzel für den Sender der Datei zusammen (siehe oben). Die Dateinamenserweiterung (Extension) ist eine 3stellige, hochzählende Nummer, die fortlaufend für einen GDT V2. (5/0) Seite 9 von 4

10 bestimmten Dateinamen vergeben wird. Die Dateizählung beginnt bei fortlaufender Extension mit.00 (führende Nullen). Damit ist sichergestellt, daß auch mehrere Dateien z.b. von einem GERÄT an die EDV geschickt werden können. ann von bestimmten Systemen nur ein fester Dateiname unterstützt werden, so ist für diese Datei die Extension. GDT vorzusehen (z.b. EDVEG.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 ommunikationsprobleme zu verhindern, sollte der Sendende die ommunikationsdatei 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-ommunikationsdateien abgelegt werden, werden zum Installationszeitpunkt festgelegt, und sind bei der Geräte-/EDV-onfiguration mit anzugeben. GDT V2. (5/0) Seite 0 von 4

11 2.4 ommunikation über serielle Schnittstelle 2.4. Hardware Die ommunikation sollte als Mindestanforderung mit einem dreiadrigen seriellen abel (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 = Stopbits = Verbindungskabel (Minimal-Anforderung) (Pin-Belegung für 25 polige Stecker / in lammern 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 ommunikation Als Datenfelder werden (-mit speziellen ennungen-) 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 ompatibilitä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 (Ch) gesendet, da CR als Trennzeichen für die serielle Übertragung definiert ist (vgl. Beispiele in Anhang A). GDT V2. (5/0) Seite von 4

12 2.5 Beispiele zum Ablauf Die Beispiele basieren auf der folgenden Praxis-Zusammenstellung mit den aufgeführten omponenten. Die Praxis arbeitet mit der Praxis-Software "PRAX_EDV" (GDT-SD-) und hat daran 3 Geräte angebunden: () Ein Phoropter (GDT-S-0), 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 EG-Schreiber (GDT-D-0), der eine eigene Stammdatenverwaltung hat, und von der arteikarte aus aufgerufen wird (EDV ist CLIENT / GERÄT ist SERVER). Das entsprechende PC- Programm zum Starten des EG liegt auf C:\REST_ECG und heißt ECG.BAT. (3) Ein Lungenfunktions-Meßplatz (GDT-D-0), 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.. ommunikation 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 630 über die serielle Leitung EDV empfängt Daten und ordnet sie dem aktuellen Patienten zu GDT V2. (5/0) Seite 2 von 4

13 2. ommunikation zwischen Praxis-EDV und EG-Schreiber EDV = CLIENT GERÄT = SERVER Patient für die Untersuchung wird auf der Praxis- EDV ausgewählt EDV schreibt Datei F: \ GDT \ EGEDV.00 mit Satzart 6302 zur Anforderung einer neuen Untersuchung (Ruhe-EG: 8402=EG0) 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 \ EGEDV.00 Ruhe-EG für den übergebenen Patienten wird durchgeführt. GERÄT schreibt Datei F: \ GDT \ EDVEG.00 mit Satzart 630 zur Übermittlung der Ergebnisse, Beenden des Programmes und damit Wechsel zur Praxis-EDV EDV liest und löscht Datei F: \ GDT \ EDVEG.00 EDV ordnet Daten dem aktuellen Patienten zu GDT V2. (5/0) Seite 3 von 4

14 3. ommunikation 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.00 mit Satzart 6300 zur Anforderung des aktuellen Patienten EDV liest und löscht Datei F: \ GDT \ EDV_LUFU.00 EDV schreibt Datei F: \ GDT \ LUFU_EDV.00 mit Satzart 630 zur Übermittlung des aktuellen Stammdatensatzes GERÄT liest und löscht Datei F: \ GDT \ LUFU_EDV.00 Spirometrie für den übergebenen Patienten wird durchgeführt. GERÄT schreibt Datei F: \ GDT \ EDV_LUFU.002 mit Satzart 630 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 630 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 V2. (5/0) Seite 4 von 4

15 2.6 ommentierte Beispiel-Dateien 2.6. Aufbau einer BDT-Zeile: 0630Schmidt<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 07835EG_TYP ; GDT-ID des Empfängers (z.b. EG-Schreiber) 07836PRAX_EDV ; GDT-ID des Senders ; Versions-Nr. GDT ; Patienten-Nummer 0930Mustermann ; Nachname 04302Franz ; Vorname ; Geburtsdatum 0030 ; Geschlecht (=männlich) ; Größe ; Gewicht = CR und LF (0D 0A hex) Jede Zeile ist mit CR und LF (0D 0A hex) abzuschließen. GDT V2. (5/0) Seite 5 von 4

16 2.6.3 Beispieldatei Daten einer Untersuchung übermitteln ; Satzart ; Dateilänge 09835PRAX_EDV ; GDT-ID des Empfängers 04836LZBD_SYS ; GDT-ID des Senders ; Versions-Nr. GDT ; Patienten-Nummer 0930Mustermann ; Nachname 04302Franz ; Vorname ; Geburtsdatum 0030 ; Geschlecht (=männlich) ; Größe ; Gewicht BDM0 ; Untersuchung: 24h-Blutdruck ; Datum der Untersuchung Dies ist ein zweizeiliger ; Befund. Zeile Befund zur 24h-Blutdruckmessung. ; Befund 2. Zeile Anmerkungen zu einer Langzeit-Blutdruckmessung. ; ommentar urzzusammenfassung 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] % 07840SYSMXTG ; Test-Ident (Hersteller-spez.) 02984Systole max Tagphase ; Testbezeichnung ; Wert 03842mmHg ; Einheit ; Datum Meßwert ; Uhrzeit Meßwert ; oberer Grenzwert 07840SYSMNTG ; nächster Test-Ident 02984Systole min Tagphase ; Testbezeichnung ; Wert 03842mmHg ; Einheit ; Datum dieses Meßwertes ; Uhrzeit dieses Meßwertes = Leerzeichen ( 20 hex / 32 dez ) = CR und LF ( 0D 0A hex ) GDT V2. (5/0) Seite 6 von 4

17 3. Satztabelle Im folgenden werden die für die Anbindung medizintechnischer Geräte definierten Sätze 6300, 630, 6302, 630 und 63 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 630 "Stammdaten übermitteln". Die übrigen Satzarten (630, 6302, 630, 63) können zu beliebigen Zeitpunkten übermittelt werden und verlangen keine Antwort. In der Regel gilt folgende ommunikationsrichtung: 6300: MG PCS 630: PCS MG 6302: PCS MG 630: MG PCS 63: PCS MG MG = Medizingerät PCS = Praxiscomputersystem GDT V2. (5/0) Seite 7 von 4

18 3. Definition der Satzarten: Stammdaten anfordern"6300" SA 6300 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/ Bedingung 8000 Satzidentifikation M Satzart Stammdaten anfordern 800 Satzlänge M Länge dieses Satzes 835 GDT - ID des Empfängers 836 GDT - ID des Senders 9206 verwendeter Zeichensatz =7Bit, 2=IBM(Standard) CP 437, 3=ISO8859-(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 V2. (5/0) Seite 8 von 4

19 3.2 Definition der Satzarten: Stammdaten übermitteln "630" SA 630 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/ Bedingung 8000 Satzidentifikation M Satzart Stammdaten übermitteln 800 Satzlänge M Länge dieses Satzes 835 GDT - ID des Empfängers 836 GDT - ID des Senders 9206 verwendeter Zeichensatz =7Bit, 2=IBM(Standard) CP 437, 3=ISO8859-(ANSI) CP Version GDT M Patientennummer / Patientenkennung M 300 Namenszusatz / Vorsatzwort des Patienten z.b. Freiherr von 30 Name des Patienten M 302 Vorname des Patienten M 303 Geburtsdatum des Patienten M TTMMJJJJ 304 Titel des Patienten 305 Versichertennummer des Patienten 306 Wohnort des Patienten PLZ ORT 307 Straße des Patienten Straße und Hausnummer 308 Versichertenart =Mitglied, 3=Familienversicherter, 5=Rentner 30 Geschlecht des Patienten =männlich, 2=weiblich 3622 Größe des Patienten 3623 Gewicht des Patienten 3628 Muttersprache des Patienten GDT V2. (5/0) Seite 9 von 4

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

21 3.4 Definition der Satzarten: Daten einer Untersuchung übermitteln "630" SA 630 Änderungen Feldkennung Vorkommen Bezeichnung der Feldinhalte Vorhandensein M/ Bedingung Erläuterung Satzidentifikation Satzlänge M M Satzart Neue Untersuchung anfordern Länge dieses Satzes GDT - ID des Empfängers GDT - ID des Senders verwendeter Zeichensatz Version GDT Softwareverantwortlicher (SV) Software Software Release-Stand der Software M =7Bit, 2=IBM(Standard) CP 437, 3=ISO8859-(ANSI) CP z.b. Firma Name der Software Software Versionsnummer 3000 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 Name des Patienten Vorname des Patienten Geburtsdatum des Patienten Titel des Patienten Versichertennummer des Patienten Wohnort des Patienten Straße des Patienten Versichertenart Geschlecht des Patienten Größe des Patienten Gewicht des Patienten Muttersprache des Patienten Geräte und verfahrensspezifisches ennfeld M M M z.b. Freiherr von TTMMJJJJ PLZ ORT Straße und Hausnummer =Mitglied, 3=Familienversicherter, 5=Rentner =männlich, 2=weiblich Typ der durchgeführten Untersuchung, z.b. EG0 (siehe Anhang B) GDT V2. (5/0) Seite 2 von 4

22 3.4 Definition der Satzarten: Daten einer Untersuchung übermitteln "630" SA 630 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/ Bedingung Tag der Erhebung von Behandlungsdaten Uhrzeit der Erhebung von Behandlungsdaten TTMMJJJJ Datum der Untersuchung HHMMSS ; Zeit (6stellig) der anzuzeigenden Untersuchung ,, , 6333, 6335,, 6399 n n n n n n n n Aktuelle Diagnose Befund Fremdbefund ommentar Anzahl der nachfolgend Fortsetzungszeilen der ennung 6228 Ergebnistabellentext Datei-Archivierungskenner Dateiformat Dateiinhalt Verweis auf die Datei Name der freien ategorie Inhalt der freien ategorie m falls 6302 vorhanden m falls 6302 vorhanden m falls 6302 vorhanden Gerade und darauf folgende ungerade ennung gehören jeweils als Wertepaar zusammen. m falls vorhergehende ennung Name der freien ategorie existiert. z.b. vom Gerät automatisch erzeugter Befundhinweis 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. beliebiger Ergebnistext, vom Gerät formatiert enner zur lassifizierung der Daten Formatbeschreibung (z.b. PDF) Beschreibung, was unter der(n) folgenden Adresse(n) (WWW Adresse oder UNC-Pfad) zu finden ist. z.b. Protokolle, Untersuchungsdaten Uniform Resource Locator (WWW-Adresse oder UNC- Pfad) z.b. \\FS\TEST\BILD.PDF GDT V2. (5/0) Seite 22 von 4

23 3.4 Definition der Satzarten: Daten einer Untersuchung übermitteln "630" SA 630 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/ Bedingung 840 n Test-Ident m 20 Zeichen alnum Header zur Übermittlung einzelner Meßwerte-Gruppen falls Feld(er) > = 84 < = Testbezeichnung 8428 Probenmaterial-Ident 8429 Probenmaterial-Index 8430 Probenmaterial-Bezeichnung 843 n Probenmaterial-Spezifikation 8437 Einheiten(en) für Datenstrom m falls Feld(er) 8438 <> (leer) z.b. Hz, dba 8438 n Datenstrom z.b. (50,-30),(00,-20),(50,-22),(200,-7),...usw 848 Teststatus B = bereits berichtet, = korrigierter Wert oder fehlt 8420 Ergebnis-Wert 842 Einheit m falls Feld(er) 8420, 846, 8462 <> (leer) 8432 Abnahme-Datum TTMMJJJJ ; Datum der Einzelmessung 8439 Abnahme-Zeit HHMMSS ; Zeit (6stellig) der Einzelmessung 8460 Normalwert-Text 846 Normalwert untere Grenze Wert wird in der Einheit 842 übermittelt 8462 Normalwert obere Grenze Wert wird in der Einheit 842 übermittelt 8470 n Anmerkung testbezogener Hinweis 8480 n Ergebnis-Text 8990 Signatur Name / ürzel des Durchführenden GDT V2. (5/0) Seite 23 von 4

24 3.5 Definition der Satzarten: Daten einer Untersuchung zeigen "63" SA 63 Feld- Vorkommen Bezeichnung der Vorhandensein Erläuterung Änderungen kennung Feldinhalte M/ Bedingung 8000 Satzidentifikation M Satzart Daten einer Untersuchung zeigen 800 Satzlänge M Länge dieses Satzes 835 GDT - ID des Empfängers 836 GDT - ID des Senders 9206 verwendeter Zeichensatz =7Bit, 2=IBM(Standard) CP 437, 3=ISO8859-(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. 300 Namenszusatz / Vorsatzwort des Patienten z.b. Freiherr von 30 Name des Patienten 302 Vorname des Patienten 303 Geburtsdatum des Patienten TTMMJJJJ 304 Titel des Patienten 6200 Tag der Erhebung von Behandlungsdaten TTMMJJJJ Datum der anzuzeigenden Untersuchung 620 Uhrzeit der Erhebung von Behandlungsdaten HHMMSS ; Zeit (6stellig) der anzuzeigenden Untersuchung 8402 Geräte und verfahrensspezifisches ennfeld Typ der anzuzeigenden Untersuchung z.b. ERGO00 (siehe Anhang B) 8432 Abnahme-Datum TTMMJJJJ ; Datum der anzuzeigenden Einzelmessung 8439 Abnahme-Zeit HHMMSS ; Zeit (6stellig) der anzuzeigenden Einzelmessung GDT V2. (5/0) Seite 24 von 4

25 4. Feldtabelle Tabelle der in den Sätzen 6300, 630, 6302, 630, 63 verwendeten Feldkennungen. * Änderungen in der Feldtabelle werden links wie folgt gekennzeichnet: *L = Längenänderung *N = neues Feld, in der. Version neue Feldkennung, die in Abstimmung mit dem Zentralinstitut eigens für den GDT vergeben wurde *R = Regeländerung, in der. Version Regelnummer für Format-/Inhaltsprüfungen, die nicht vom BV-Prüfmodul abgedeckt werden *Nx.x = neues Feld ab Version x.x F 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 Patientennummer / Patientenkennung Namenszusatz / Vorsatzwort des Patienten <=0 alnum <=5 alnum von 30 Name des Patienten <=28 alnum Schmitz 302 Vorname des Patienten <=28 alnum Erna 303 Geburtsdatum des Patienten 8 datum 020/ Titel des Patienten <=5 alnum Dr. 305 Versichertennummer des Patienten <=2 alnum 23456M Wohnort des Patienten <=30 alnum öln 307 Straße des Patienten <=28 alnum Holzweg Versichertenart MFR num Geschlecht des Patienten 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. (5/0) Seite 25 von 4

26 F Bezeichnung Länge Typ Regel Beispiel 620 Uhrzeit der Erhebung von 6 zeit 090 HHMMSS 3220 Behandlunsdaten 6205 Aktuelle Diagnose <=60 alnum Diabetes 6220 Befund <=60 alnum erhöhter Blutdruck 622 Fremdbefund <=60 alnum Verdacht auf Obstruktion *N2. *N *N *N2. *N2. *N2. *N2. *N Anzahl Folgezeilen <=4 num ommentar <=60 alnum Belastung abgebrochen 6228 Ergebnistabellentext, formatiert <=60 alnum s. Beispiele im Anhang 6302 Datei-Archivierungsnummer <=60 alnum Dateiformat <=60 alnum PDF 6304 Dateiinhalt <=60 alnum Datenanalyse 6305 Verweis auf Datei (URL) <=60 alnum \\FS\DATA\0072.PDF 6330 Name der freien ategorie <=60 alnum Inhalt der freien ategorie <=60 alnum Satzidentifikation 4 alnum Satzlänge 5 num *N *N *L 835 GDT - ID des Empfängers 8 alnum ROP200U 836 GDT - ID des Senders 8 alnum PRAX_EDV 8402 Geräte und verfahrensspez. <=6 alnum EG0, siehe Anhang B ennfeld 840 Test-Ident <=20 alnum FEV 84 Testbezeichnung <=60 alnum Obj. refr. cyl. rechts 848 Teststatus 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 843 Probenmaterial-Spezifikation <=60 alnum GDT V2. (5/0) Seite 26 von 4

27 F Bezeichnung Länge Typ Regel Beispiel 8432 Abnahme-Datum 8 datum *N 8437 Einheit (en) für Datenstrom <=60 alnum min, mmhg, mmhg *N 8438 Datenstrom <=60 alnum 5,20,80... oder (5,20,80),(0,28,92).. kann Float-Werte enthalten. *N*R 8439 Abnahme-Zeit 6 zeit 090 HHMMSS Normalwert-Text <=60 alnum *N 846 Normalwert untere Grenze var float -5 *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 num 2 *N 928 Version GDT 5 alnum 0.00, oder 02.0 datum = Datumsangabe TTMMJJJJ numerisch, bei festen Feldlängen ist das Feld mit führenden Nullen num = aufzufüllen alnum = alphanumerisch float = Fließkommazahl mit Punkt als Dezimaltrennzeichen GDT V2. (5/0) Seite 27 von 4

28 5. Regeltabelle Regeln sind entsprechend ihrer Art in Nummernkreise unterteilt: Formatprüfungen Inhaltsprüfungen Existenzprüfungen ontextprüfungen Regelnr. ategorie Prüfung Erläuterung 008 Format TTMMJJJJ TT=Tag;MM=Monat;JJJJ=Jahr 020 Format TTMMJJJJ Wertebereich: TT=00-3 MM=00-2 /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) 2 erlaubter Inhalt, 2 6 erlaubter Inhalt, 3, 5 Versichertenart MFR 304 ontext Datum kleiner oder gleich Maschinendatum Vermeidung von Fehleingaben GDT V2. (5/0) Seite 28 von 4

29 6. ANHANG 6. Anhang A Blockformat zur seriellen Datenübertragung mit Beispielen 6.. Übertragungsprotokoll Die BDT-Datei wird in Blöcken übertragen. Der Empfang eines Übertragungsblocks ist innerhalb von 0 s durch Senden eines AC (06h) gefolgt von einer (3h) 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> <ennung> [<Datenfeld>] <CRC-6> <CR> 6..3 Bedeutung der einzelnen Felder Sende-Sequenz-Zähler Länge: Byte. Der Sende-Sequenz-Zähler wird zyklisch von (3h) 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. ennung Länge: 3 Byte Es werden folgende ennungen definiert: B00 Beginn einer BDT-Datenübertragung / erster BDT-Datenblock B0 BDT-Datenblock B02 Ende einer BDT-Datenübertragung / letzter BDT-Datenblock Datenfeld Länge: max. 28 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. GDT V2. (5/0) Seite 29 von 4

30 Als Trennung zwischen zwei BDT-Zeilen wird das Zeichen Ch (Feldseparator FS) verwendet. 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-6 Länge: 4 Byte 6 Bit CRC über Sende-Sequenz-Zähler, ennung und Datenfeld. Wird als ASCII-Hex gesendet. Z.B. 2A9Eh als 32h 4h 39h 45h. (Zur Generierung der Checksumme siehe Anhang C) CR Länge: Byte Carriage Return (0Dh) schließt den Übertragungsblock ab Beispiele Hinweis: Das Zeichen ' ' steht für den Feldseparator (Ch). Zur Veranschaulichung wurde die Datenfeldlänge auf 32 Zeichen begrenzt Anforderung von Stammdaten Client sendet: C: B QMS-STAR 07 <CRC> <CR> S: <AC> C: 2B ROP200U <CRC> <CR> S: <AC> Server antwortet: S: 7B <CRC> <CR> C: <AC> S: 8B ROP200U QMS-STAR <CRC> <CR> C: <AC> S: 9B Axt Berta <CRC> <CR> C: <AC> S: B <CRC> <CR> C: <AC> GDT V2. (5/0) Seite 30 von 4

31 6..6 Verhalten bei Übertragungsfehlern Bei Empfang von <AC> 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: B QMS-STAR 07 <CRC> <CR> S: <AC> C: 2B ROP200U <CRC> <CR> S: <AC> 0 ; Fehler aufgetreten C: 2B ROP200U <CRC> <CR> ; Block nochmals senden mit gleichem Sende-Sequenz-Zähler (hier 2) S: <AC> ; diesmal Block richtig empfangen Synchronisation nach Übertragungsfehlern C: B QMS-STAR 07 <CRC> <CR> S: <AC> C: 2B ROP200U <CRC> <CR> S: <AC> 0 ; Fehler aufgetreten C: 2B ROP200U <CRC> <CR> S: <AC> 0 ; Fehler erneut aufgetreten C: 0B QMS-STAR 07 <CRC> <CR> ; neue Synchronisation mit ; Sequenzzähler 0 S: <AC> C: B ROP200U <CRC> <CR> S: <AC> GDT V2. (5/0) Seite 3 von 4

32 Abbruch einer Übertragung nach Übertragungsfehlern C: B MEDISTAR 07 <CRC> <CR> S: <AC> C: 2B ROP200U <CRC> <CR> S: <AC> 0 ; Fehler aufgetreten C: 2B ROP200U <CRC> <CR> S: <AC> 0 ; Fehler aufgetreten C: 0B QMS-STAR 07 <CRC> <CR> S: <AC> C: 2B ROP200U <CRC> <CR> S: <AC> 0 ; Fehler aufgetreten C: 2B ROP200U <CRC> <CR> S: <AC> 0 Sender bricht Übertragung ab. Empfänger bleibt empfangsbereit. Übertragungsfehler bei Stammdatenanforderung Das Problem, dass sowohl Client als auch Server versuchen, eine BDT-Datei zu senden, kann z.b. folgendermaßen entstehen: C: B QMS-STAR 07 <CRC> <CR> S: <AC> C: 2B ROP200U <CRC> <CR> S: [<AC> ] ; 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. Block der angeforderten Stammdaten C: 0B QMS-STAR 07 <CRC> <CR> ; erneutes Senden durch Client mit neuer Synchronisation S: 7B <CRC> <CR> ; Server wiederholt den. Block der Stammdaten (AC vom Client fehlt) C: 0B QMS-STAR 07 <CRC> <CR> ; Client wiederholt den Synchronisationsversuch GDT V2. (5/0) Seite 32 von 4

33 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 AC ) von Server und Client abgebrochen (vgl. 6..6). GDT V2. (5/0) Seite 33 von 4

34 6.2 Anhang B Geräte- und verfahrensspezifisches ennfeld "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 ennfeld Das Feld dient zur Gruppierung der zu übermittelnden Daten. Der bisherige Typ von 2 (alnum) wurde auf - 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 ennfeld 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 ennung 8402 können die jeweiligen Testidents (ennung 840) herstellerspezifisch vergeben werden (vgl. Anhang B des BDT 2/94). GDT V2. (5/0) Seite 34 von 4

35 ALLE Allergologie ALLE0 Anamneseerfassung allergolisch ALLE02 Befunderfassung allergologisch ALLE03 Diagnoseerfassung allergologisch ALLE04 Pricktest ALLE05 Intracutantest ALLE06 Provokationstest ALLE07 Invitrotest ALLE08 Insektengift ALLE09 Epikutantest ALLE0 tägliche Hyposensibilisierungsbehandlung ALLG Untersuchungen, allgemein ALLG00 nicht näher spezifizierte Untersuchungen APNO Schlaf-Apnoe-Untersuchungen APNO00 Apnoe, allgemein APNO0 Langzeit Schlafapnoe Screening APNO02 Polysomnographie AUDI Audiometrische Untersuchungen AUDI00 Audiometrie, allgemein AUDI0 Reinton-Schwellen-Audiogramm AUDI02 EEG-Audiometrie BDM Blutdruckmessung BDM00 Blutdruckmessung,allgemein BDM0 Langzeit-Blutdruckmessung GDT V2. (5/0) Seite 35 von 4

36 EG Elektrokardiographie EG00 EG, allgemein EG0 Ruhe-EG EG02 Arrhythmie-EG EG03 Spätpotential-EG EG04 Langzeit-EG ERGO Belastungs-Untersuchungen ERGO00 Belastungs-Untersuchung, allgemein ERGO0 Belastungs-EG ERGO02 Fluß-Volumen unter Belastung ERGO03 Blutgase ERGO04 Blutgase unter Belastung ERGO05 Spiroergometrie ERGO06 Atemgasanalyse ERGO07 Pulsoximetrie ERGO08 Indirekte alorimetrie ERGO09 Indirekte alorimetrie mit Haube ERGO0 HZV-Bestimmung über CO2-Rückatmung ERGO Atemantriebsmessung über CO2-Rückatmung HÄMA Blutbilder HÄMA0 kleines Blutbild HÄMA02 großes Blutbild HÄMA03 manuelles Differentialblutbild HÄMA04 Retikulozyten HÄMA05 CD4/CD8 LUFU Lungenfunktions-Messung LUFU00 Lungenfunktion, allgemein LUFU0 Langsame Spirometrie LUFU02 Forcierte Spirometrie (Fluß-Volumen) LUFU03 MVV (Maximal Voluntary Ventilation) GDT V2. (5/0) Seite 36 von 4

37 LUFU04 Bodyplethysmographie LUFU05 FRC pl (Lungenvolumen - Bodyplethysmographie) LUFU06 FRC He (Lungenvolumen - Helium Rückatmung) LUFU07 Resistance nach Verschlußdruckmethode LUFU08 Resistance nach Impulsoscillation-Methode LUFU09 Resistance nach Oszilloresistometrie-Methode LUFU0 Compliance LUFU Atemmuskulaturstärke-Messung LUFU2 Atemantrieb-Messung LUFU3 Diffusion Single-Breath LUFU4 Diffusion Steady-State LUFU5 Diffusion Rebreathing LUFU6 Diffusion Membranfaktor LUFU7 Capnographie LUFU8 Rhinomanometrie LUFU9 Ruheatmungsanalyse NEUR Neurologische Messung NEUR00 Neurologie, allgemein NEUR0 Langzeit-EEG NEUR02 EEG mit simultaner EG-Aufzeichnung NEUR03 Motorisches NLG NEUR04 Sensorisches NLG NEUR05 Evozierte Potentiale NEUR06 Rotationstest NEUR07 Nystagmusanalyse NEUR08 Sakkadentest NEUR09 Posture NEUR0 Biofeedback OPTO Augenheilkunde OPTO00 Augenheilkunde, allgemein OPTO0 Refraktionsbestimmung, objektiv GDT V2. (5/0) Seite 37 von 4

38 OPTO02 Refraktionsbestimmung, subjektiv OPTO03 Refraktionswerte Brille/ontaktlinse OPTO04 Blendenempfindlichkeitsmessung (Visus) OPTO05 Gesichtsfeldmessung OPTO06 Augendruckmessung OPTO07 Hornhautmessung (rümmungsradien/achslagen) OPTO08 Hornhautmessung (3D-Geometriedaten) OPTO09 Fundusbilder OPTO0 Angiographiebilder OPTO Spaltlampenbilder OPTO2 Topographiebilder OPTO3 Schichtbilder OPTO4 generische Bilddaten PROV Provokations-Test PROV00 Provokation, allgemein PROV0 Spezifische Aerosol-Provokation PROV02 Unspezifische Aerosol-Provokation PROV03 altluft Provokation PROV04 Bronchodilatation SONO Sonographie-Messungen SONO00 Sonographie, allgemein SONO0 Ultraschall-Doppler URO Urologie URO00 Urologie, allgemein URO0 Uroflowmetrie GDT V2. (5/0) Seite 38 von 4

39 6.3 Anhang C C-Programm zur Berechnung der CRC-6 short crc6(char *s, short len) { short bte, crc, i; crc = 0; while (len > 0) { len = len - ; bte = *s; s = s + ; i = 8; while (i > 0) { i = i - ; if (bte & 0x0080) { crc = crc ^ 0x8000; } if (crc & 0x8000) { crc = crc << ; crc = crc ^ 0x8005; } else { crc = crc << ; } bte = bte << ; } } return crc; } GDT V2. (5/0) Seite 39 von 4

40 6.4 Anhang D: Borland Pascal 7. 0 Programm zur Berechnung der CRC6 program Crc6Dem; { CRC6-Demo für Borland Pascal 7.0 } {$B-,I+,P+,T-,X+} function UpdateCrc6 (InitCrc: Word; var Data; Len: Word): Word; { CRC-6-Weiterberechnung, InitCrc sollte beim. Block 0 sein } type CrcByteArray = array[ ] of Byte; var Crc, I, J: Word; B : Byte; Begin Crc := InitCrc; for I := to Len do begin B := CrcByteArray(Data)[I]; for J := to 8 do begin if (B and $80) <> 0 then Crc := Crc xor $8000; if (Crc and $8000) <> 0 then begin Crc := Crc shl ; Crc := Crc xor $8005; end else Crc := Crc shl ; B := B shl ; end; end; UpdateCrc6 := Crc; end; function Crc6 (var Data; Len:Word); Word; { CRC-6-Berechnung, InitCrc := 0} begin Crc6 := UpdateCrc6(0, Data, Len); end; function Crc6Str (const St: String): Word; GDT V2. (5/0) Seite 40 von 4

41 { CRC-6-Berechnung für Strings unter Nichtberücksichtigung des Längenbytes } type TDataStr = record Len: Byte; Data: array[..255] of Char; end; var DataStr: ^TDataStr; begin DataStr Crc6Str := Crc6(DataStr^.Data, DataStr^.Len); end; begin { Crc6Dem } if ParamCount = 0 then WriteLn('Aufruf: crcdemo Demostring') else begin Write(ParamStr() + ': '); WriteLn(Crc6Str(ParamStr())); end; end. GDT V2. (5/0) Seite 4 von 4