gdt 3.0 device data volume - qms- · pdf fileintegration of medical instruments gdt 3.0 device...

Integration of medical instruments

GDT 3.0 Device data volume Interface description for system-independent data transfer between medical information systems and medical instruments

© QMS Qualitätsring Medizinische Software e. V. Düsseldorf, 2013 Version: 3.0 Release: 1.0 Date: 10/01/2013 Status: Released

GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 2 von 57 Date: 10/01/2013

Version 3.0 Release 1.0

Author Ralf Franke (Head of working group GDT)

Editors Silke Hochheim, Ralf Franke

Contributions of: QMS Arbeitskreis BDT/GDT/LDT and additional contributions: Arzt & Praxis GmbH, Awinta GmbH, CareFusion GmbH, DGN Deutsches Gesundheitsnetz Service GmbH, HABEL GmbH & Co. KG, Kassenärztliche Bundesvereinigung, ktberger-consulting, medatixx GmbH & Co. KG, Reinhold Mainz

Status Released

Released at / by 10/01/2013 / Qualitätsring Medizinische Software e.V.

Coordinated with Arbeitskreis GDT/BDT des QMS e.V. Änderungshistorie: Version Date Updated by Update reason / description 2.99.3.0.1 11/07/2011 Ralf Franke First draft

2.99.3.0.2 11/09/2011 Ralf Franke Supplements from feedback

2.99.3.0.3 11/10/2011 Ralf Franke • FK 9106 changed into in FK 9206 (GDT V 2.1)

• Extension FK 8402 (according to proposal)

• New object „ArztIdent“

2.99.3.0.4 01/16/2012 Ralf Franke Revision

2.99.3.0.5 02/03/2012 Ralf Franke Extension/Revision according to working group meeting BDT/GDT at 17.01.2012

2.99.3.0.6 03/01/2012 Ralf Franke Update of the QMS e.V. contact data

2.99.3.0.7 03/28/2012 Ralf Franke Update of comments

2.99.3.0.8 05/20/2012 Ralf Franke Inclusion of legwork/contributions of: ktberger-consulting, Arzt & Praxis GmbH und DGN Deutsches Gesundheitsnetz Service GmbH

2.99.3.0.9 08/06/2012 Ralf Franke • Update comments

• Revision box-chart

• Addition chapter Workflow

• New record type 6303 „Cancellation of an or-der“

2.99.3.1 08/30/2012 Silke Hochheim Editorial adaptation to new QMS-layout

2.99.3.2 09/24/2012 Ralf Franke Addition/Revision according to working group meet-ing BDT/GDT at 04.09.2012

3.0 10/15/2012 Ralf Franke Pre-release for comment period

3.0 01/17/2013 Ralf Franke Consideration of contributions from the comment period


Version Date Updated by Update reason / description 3.0 01/31/2013 Ralf Franke Final version pre-release

3.0 Release 1

07/01/2013 Ralf Franke Editorial changes: Revision of example files, graphics, typing errors

3.0 Release 1

10/01/2013 Ralf Franke Final version for publication on the homepage of the Qualitätsring Medizinische Software e.V.

Preface Only through the dedicated work of the Qualitätsring Medizinische Software e.V (hereinafter called QMS) has the present GDT data record description become possible. Anyone who wants to benefit from the results is therefore invited and advised to collaborate in consensual studies. Unfortunately, faulty and non-certified versions of the GDT interfaces have repeatedly emerged in the past under the guise of a “GDT interface” which might weaken the goal of a standardized data transfer between systems to ultimately undermine the efforts of the QMS for quality standards. We have therefore decided to list those faulty implementations and their publishers on the asso-ciation’s internal bulletin boards to reveal them only internally for now. This action is accompanied by a letter of the QMS management to the responsible company which contains the demand to submit to the standards and adapt the software or not to use the term "GDT interface" any longer. Hence: Become a member, contribute and become certified! (www.qms-standards.de)

http://www.qms-standards.de/


Inhaltsverzeichnis

1 INTRODUCTION 7

1.1 General remarks ............................................................................................................................. 7

1.2 Definition of terms .......................................................................................................................... 7

1.3 Communication .............................................................................................................................. 8

1.4 Labeling of the interface properties ............................................................................................. 8 1.4.1 General remarks ..................................................................................................................... 8 1.4.2 Minimum requirement for PVS and DEVICE .......................................................................... 8 1.4.3 Labeling for PVS ..................................................................................................................... 8 1.4.4 Labeling for DEVICE .............................................................................................................. 9 1.4.5 Examples for possible combinations PVS / DEVICE ............................................................. 9

2 INTERFACE DESCRIPTION 9

2.1 Identification of the components (GDT-ID) .................................................................................. 9

2.2 Character set .................................................................................................................................. 9

2.3 Communication via file ................................................................................................................10 2.3.1 File names ............................................................................................................................10 2.3.2 Directory ...............................................................................................................................10

2.4 Communication via serial interface ............................................................................................11 2.4.1 Hardware ..............................................................................................................................11 2.4.2 Procedure of communication ................................................................................................12

2.5 Examples to the procedure .........................................................................................................12

2.6 Annotated example files ..............................................................................................................15 2.6.1 Structure of a GDT line: ........................................................................................................15 2.6.2 Example file “Transmission of master data” (Stammdaten übermitteln) (6301) ...................15 2.6.3 Example file “Transmission of examination data” (Daten einer Untersuchung übermitteln) (6310) 16

3 CODE PAGE 17

3.1 Definition of record types: Request master data (Stammdaten anfordern) „6300“ ..............19

3.2 Definition of record types: Transmission of master data (Stammdaten übermitteln) „6301“19

3.3 Definition of record types: Request new examination (Neue Untersuchung anfordern) „6302“ ....................................................................................................................................................19


3.4 Definition of record types: Cancel requested examination (Angeforderte Untersuchung stornieren) „6303“ ................................................................................................................................20

3.5 Definition of record types: Transmission of examination data (Daten einer Untersuchung übermitteln) „6310“ ..............................................................................................................................21

3.6 Definition of record types: Display data of an examination (Daten einer Untersuchung zeigen) „6311“ .......................................................................................................................................22

4 FIELD CHART 23

5 CHART OF RULES 29

6 ANNEX 29

6.1 Annex A: Block format for serial data transmission, including examples .............................29 6.1.1 Transmission protocol ..........................................................................................................29 6.1.2 Transmission block ...............................................................................................................29 6.1.3 Meaning of the respective fields ...........................................................................................30 6.1.4 Examples ..............................................................................................................................30

6.2 Annex B: Device and process specific characteristic map „8402“ ........................................35

6.3 Annex C: Transmission of measurement data ..........................................................................40

6.4 Annex D: Building Blocks / Objects ...........................................................................................43

6.5 Example files “Best Practice“ .....................................................................................................44 6.5.1 Request master data “6300” (DEVICE to PVS) ....................................................................44 6.5.2 Transmission of master data “6301” (PVS to DEVICE) .......................................................44 6.5.3 Request new examination “6302” (PVS to DEVICE) ...........................................................44 6.5.4 Transmission of examination data “6310” (DEVICE to PVS) ...............................................45 6.5.5 Display data of an examination “6311” (PVS to DEVICE) ....................................................46 6.5.6 Appointment request “6302” (PVS to DEVICE) ....................................................................46 6.5.7 Referral to specialist “6302” (PVS to DEVICE) ....................................................................46 6.5.8 Hospitalization “6302” (PVS to DEVICE) ..............................................................................47 6.5.9 Transmission of emergency data “6302” (PVS to DEVICE) .................................................48

7 ILLUSTRATION OF THE WORKFLOWS 49

7.1 Basic-Workflow ............................................................................................................................49 7.1.1 Requirements .......................................................................................................................49 7.1.2 Illustration of results data ......................................................................................................50

7.2 Storage of patient master data ...................................................................................................50 7.2.1 Single or direct transmission of data ....................................................................................51


7.2.2 Batch transmission of master data .......................................................................................51

7.3 Simple form of a GDT request ....................................................................................................52 7.3.1 Result ....................................................................................................................................53

7.4 Asynchronous communication ..................................................................................................54

7.5 Asynchronous communication in equipment sharing .............................................................55 7.5.1 Process .................................................................................................................................56 7.5.2 Extensions of the GDT .........................................................................................................57 7.5.3 Necessity of a definition for transmission paths ...................................................................57


1 Introduction 1.1 General remarks The present interface description was developed by the QMS (Qualitätsring Medizinische Soft-ware e.V) to define a standardized interface between medical information systems and medical devices. The interface (Geräte-Daten-Träger – GDT device data volume) is therefore written in a neu-tral form and can be used by all health care market participants. It can be realized and used by both standalone devices as well as PC-based instruments. If a direct communication in accord-ance with this description is not technically feasible (e.g. older standalone devices with vendor-specific interface), a suitable GDT driver program should be provided by the device manufacturer. The new version is expected to develop into a voluntary standard for manufacturers of medical information systems and manufacturers of medical technology devices. A certificate will be held by the QMS. (The interface description is adopted by the Zentralinstitut (Central Institute) as an adjunct to the BDT record type description.) The objective of a further development of this interface description is the realization of a plug & play capability for the connection of medical devices to medical information systems. Thereby, the quality of the connection is improved and installation time is reduced.

1.2 Definition of terms The following important terms are used in the interface description: GDT Device data volume (Geräte-Daten-Träger), (Interface name inspired by

BDT, LDT, ADT, KVDT, …). GERÄT (DEVICE)

Medical technology device (or corresponding driver program), standalone-unit or PC-based measuring device.

PVS Medical office administrative system ((Arzt-)PraxenVerwaltungsSystem). KOMPONENTE (COMPONENT)

Every participant of the data exchange, PVS (administrative system) or de-vice (Gerät).

SERVER COMPONENT which waits for external requests and commands to be pro-cessed. (Annotation: The server in a PC network responds only to requests from the workstations).

CLIENT COMPONENT, which sends requests and commands. The terms CLIENT / SERVER are used here only to describe the transmitter and receiver behav-ior, and are therefore independent of PVS and DEVICE. At the time of installation it has to be determined which of the installed components works as SERVER or CLIENT to avoid conflicts. Because the real goal of a device connection is the communication of study data, a PVS should be able to work at least as SERVER (processing examination data) and a DEVICE should be able to work at least as CLIENT (sending examination data) (see 1.4).


1.3 Communication Basically, data communication is possible via three different mechanisms:

• File-interface The communication between DEVICE and PVS takes place via files which are created in specified directories (see below).

• Serial interface A connected DEVICE (or driver program) communicates with the PVS via serial interface.

• Program-program interface DEVICE and PVS support program - program interfaces (like Clipboard, DDE, OLE, UNIX-Pipes).

This version of the interface description is limited to the first two mechanisms: File interface and Serial interface. An extension to program-program interfaces is planned. Since all messages are transmitted in the form of GDT sets, the used data format is independent of the used communication channel.

1.4 Labeling of the interface properties 1.4.1 General remarks To clearly determine the technical description of the interface capability of different COMPONENTS, a specific labeling is used which is defined differently for PVS and DEVICE. To find out whether or not a specific PVS can communicate with a DEVICE it is only necessary to check the interface labels. A communication is possible, if at least one way of communication (serial or file related) and at least one SERVER-/CLIENT specification match. The technical documentation of a GDT enabled DEVICE or PVS therefore has to contain a corre-sponding specification about the nature of the realized interface. 1.4.2 Minimum requirement for PVS and DEVICE The PVS should be able to work as a SERVER at least, that is being reply to record type 6300 with record type 6301 and being able to process record types 6310. The DEVICE should work as a CLIENT at least, that is being able to send record types 6310 1.4.3 Labeling for PVS GDT-<xx>-<nn> <xx> = S Serial data transmission according to GDT is supported = D Data transmission via files according to GDT is supported = SD Both methods are supported <nn> = 10 PVS can work as a SERVER = 01 PVS can work as a CLIENT = 11 PVS can work as a SERVER or a CLIENT Example: GDT-S-10 / PVS can only work as a serial SERVER,


GDT-D-11 can work via file as SERVER and CLIENT 1.4.4 Labeling for DEVICE GDT-<xx>-<nn> <xx> = S Serial data transmission according to GDT is supported = D Data transmission via files according to GDT is supported = SD Both methods are supported <nn> = 01 DEVICE can work as a SERVER = 10 DEVICE can work as a CLIENT = 11 DEVICE can work as a SERVER or a CLIENT Example: GDT-D-10 can work via file as SERVER and CLIENT 1.4.5 Examples for possible combinations PVS / DEVICE Here are examples of COMPONENTS which can communicate with each other:

PVS DEVICE GDT-S-11 GDT-SD-01 GDT-D-10 GDT-D-11 GDT-SD-01 GDT-S-01

Here are examples of COMPONENTS which cannot communicate with each other:

PVS DEVICE GDT-S-11 GDT-D-11 GDT-SD-10 GDT-S-01

2 Interface description 2.1 Identification of the components (GDT-ID) The GDT-ID is used to uniquely identify the components involved in the communication and is set during installation. The ID consists of a total of 8 random characters which are allocated manufacturer and device-specifically. Since the entire message assignment is based on this ID, it is essential to ensure a unique allocation; especially for DEVICES which exist multiple times in a room (like ECG record-ers of the same manufacturer).

2.2 Character set The allowed character set within the GDT frame is the IMB-8-Bit character set (code page 437) with ≥ 20 hex characters (32 dec.). Furthermore, additional character sets can be supported.


2.3 Communication via file 2.3.1 File names The transmission of information takes place via (text) files whose file name is to be clearly defined during installation. The structure of the file name is defined in the following way: <token of receiver>< token of sender>.<incrementing number> (e.g.: PVS2GER.005)

or < token of receiver>< token of sender>.GDT (e.g.: PVS2GER.GDT)

or < token of receiver>< token of sender>_<incrementing number>.GDT (e.g.:

PVS2GER_4711.GDT) The file name is composed of a maximum of 4 characters as a token for the receiver and a max-imum of 4 characters as a token for the sender of the file (see above). The file name extension (Extension) is a 3-digit incrementing number that is sequentially as-signed for a specific file name. The file number starts with .001 (guiding zeros) at a continuous extension. This ensures that multiple files (for example multiple files from one DEVICE) can be sent to the PVS. Note: If it is foreseeable that the three digits of the extension are not sufficient for the consecutive numbering, the extension can also be inserted into the file, as long as the receiver can process file names of this sort(e.g.: PVS2GER_4711.GDT). Some operating systems have restrictions regarding the extension of the file name. If certain systems can only configure one specific file name, the extension “GDT” should be pro-vided for it (e.g.: PVS1EKG1.GDT). The used file type (fixed or incrementing) is to be defined for every DEVICE at the time of installa-tion. The files are produced by the respective sender, whereas the extension is incremented accord-ingly. If a file with the extension ‘.GDT’ is still present (receiver has not yet read the file) it must not be overwritten from the sender (otherwise there will be a loss of data). The processing of the data by the receiver has to happen sorted by date/time (FIFO). After the files have been read, the receiver has to delete the files. To avoid problems in communication, the sender should write the communication file without a pause. If an interruption is necessary, a new file with incremented number has to be generated. If the communication file contains an attachment, the attachment should be initially generated with a temporary file name (e.g.: file name without extension). Only after the writing process is fin-ished, the attachment has to be renamed to the name configured for the receiver. This secures that the communication file is only processed after the whole content has been written down. It is possible that several consecutive sentences exist in a file. It is also possible that multiple record types of different patients are used in one file. 2.3.2 Directory The hard drive and directory in which the communication files are stored have to be determined at the time of installation and have to be specified in the DEVICE-/PVS configuration.


2.4 Communication via serial interface 2.4.1 Hardware The communication happens via three-wire serial cable (RxD, TxD, GND) as minimum require-ment, without a hardware-handshake. Optionally, further interface-signals can be supported (RTS, CTS, DTR, etc.). Interface parameter (Minimum requirement) Baud rate = 2400 Baud (optionally others) Date bits = 8 Parity = none Start bits = 1 Stop bits = 1 Connection cable (Minimum requirement) (Pin Assignment for 25-pin plugs / in brackets for 9-pin plugs)

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 Volume Detect)

For a simple connection only lines a) + b) + c) are necessary. To use a software protocol, lines d) + e) on both sides of the lines and lines f) + g) + h) have to be overridden. The maximal cable length is dependent of the Baud rate that shall be used. Important: The mapped description is the crossed version of a) + b)! A “1:1” variant is possible, however, depending on the type of the device. In this case Pin 2 of the first device is connected to Pin 2 of the second device. The same happens then for Pin 3 (alt-hough this does not happen very often). Please contact the respective producer of the device to clarify the correct polarity.


2.4.2 Procedure of communication The defined set and field identifiers are used as data fields. All data fields are transmitted in a fixed block format (see Annex A). Since a personal software handshake is defined within the protocol, the use of an external handshake software (XON-XOFF) is not necessary. To maintain compatibility, the set and line lengths of the transmitted files are always calculated with CR / LF (as defined in the GDT). Rather than sending those two characters, a field separator (1Ch) is sent since CR is defined as the separator for a serial transmission (see examples in An-nex A).

2.5 Examples to the procedure The examples are based on the following office-compilation with the listed components. The medical office works with PVS “PRAX_PVS” (GDT-SD-11) and has three connected devices:

(1) A phoropter (GDT-S-10) which is connected via serial line and which can only send examina-tion data to the PVS by the push of a button (not using master data management), (PVS is the SERVER / DEVICE is the CLIENT).

(2) A PC-based ECG recorder (GDT-D-01) which has its own master data management and which is opened from the file card (PVS is the CLIENT / DEVICE is the SERVER). The corre-sponding PC program to start the ECG is located at C:\REST: ECG and is called ECG.BAT.

(3) A pulmonary function setup (GDT-D-10) with incorporated master data management which is operated from the device and communicates with the PVS (PVS is the SERVER / DEVICE is the CLIENT). The spirometry program is called D: \ LUFU SPIRO.exe.

1. Communication between PVS and phoropter (no possibility for master data manage-ment

PVS = SERVER DEVICE = CLIENT

Metering at the phoropter is performed

The push of a button on the DEVICE sends the test results as record type 6310 via serial line

PVS receives data and associates it with the current patient


2. Communication between PVS and ECG recorder PVS = CLIENT DEVICE = SERVER

Patient for the next examination is chosen in the PVS

PVS writes file F: \ GDT \ EKG1PVS1.001 with record type 6302 to request a new examination (resting ECG: 8402 = EKG01)

Switchover to device software by opening the program via the ECG.BAT in the directory C:\REST.ECG

DEVICE reads/processes and deletes the file F:\GDT\EKG1PVS1.001

Resting ECG for the (from the DEVICE) transmitted patient is performed

DEVICE writes file F: \ GDT \ PVS1EKG1.001 with record type 6310 to communicate the results, exit the program and then switch to PVS

PVS reads and deletes file F: \ GDT \ PVS1EKG1.001 PVS assigns data to the current patient

3. Communication between PVS and pulmonary function setup PVS = Server DEVICE = CLIENT

Patient for the examination is available in the PVS

The push on a button of the the DEVICE requests patient data: DEVICE writes file F:\GDT\PVS_LUFU.001 with record type 6300

to request the current patient data

PVS reads/processes and deletes the file F: \ GDT \ PVS_LUFU.001 PVS writes the file F: \ GDT \ LUFU_PVS.001 with

record type 6301 to transmit the current master data set

DEVICE reads/processes and deletes the file F:\GDT\LUFU_PVS.001


Spirometry for the (from PVS transmitted) patient is performed

DEVICE writes file F:\GDT\PVS_LUFU.002 with record type 6310 to transfer the results

Another spirometry for the same patient is performed

DEVICE writes the file F:\GDT\PVS_LUFU.003 with record type 6310 to transfer the results

PVS reads/processes and deletes the files F:\GDT\PVS_LUFU.002 and PVS_LUFU.003

PVS allocates the files to the patient


2.6 Annotated example files 2.6.1 Structure of a GDT line: 0163101Schmidt<CR><LF> Length of line incl. CR LF Field identifier of the line content Content of the resp. data field End of line (CR/ LF) 2.6.2 Example file “Transmission of master data” (Stammdaten übermitteln) (6301) 01380006301↓↵ ; Record type “Transmission of master data” (Stammdaten

übermitteln) 01681000000292↓↵ ; Record length 0228200Obj_Kopfdaten↓↵ ; Start identifier object „Obj_Kopfdaten“ (Obj_header_data) 0178315EKG_TYP1↓↵ ; GDT-ID of the receiver (e.g. ECG recorder) 0178316PRAX_PVS↓↵ ; GDT-ID of the sender 014921803.01↓↵ ; Version number GDT 01082015↓↵ ; End of object (Object contains 5 fields) 0208200Obj_Patient↓↵ ; Start identifier object “Obj_Patient” (Obj_patient) 014300002345↓↵ ; Patient number 0193101Doe↓↵ ; Name 0143102John↓↵ ; First name 017310301101945↓↵ ; Date of birth (DOB) 01031101↓↵ ; Gender (1=male) 01082017↓↵ ; End of object (Object contains 7 fields) 0288200Obj_Basisdiagnostik↓↵ ; Start identifier object “Obj_Basisdiagnostik”

(Obj_basic_diagnostics) 0153622178.00↓↵ ; Height 0153623079.00↓↵ ; Weight 01082014↓↵ ; End of object (Object contains 4 fields) 011820219↓↵ ; End of record (Record contains 19 fields)

↓↵ = CR / LF

Each line has to be closed with CR / LF (0D 0A hex)!


2.6.3 Example file “Transmission of examination data” (Daten einer Untersuchung über-

mitteln) (6310)

01380006310↵↓ ; Record type

01681000001073↵↓ ; File length

0228200Obj_Kopfdaten↵↓ ; Start of a new object

(Obj_header_data)

0178315PRAX_PVS↵↓ ; GDT-ID of the receiver

0178316LZBD_SYS↵↓ ; GDT-ID of the sender

014921803.01↵↓ ; Version number GDT

01082015↵↓ ; End of object

0208200Obj_Patient↵↓ ; Start of a new object

(Obj_patient)

014300002345↵↓ ; Patient number

0193101Doe↵↓ ; Name

0143102John↵↓ ; First name

017310301101945↵↓ ; Date of birth (DOB)

01031101↵↓ ; Gender (1=male)


0288200Obj_Basisdiagnostik↵↓ ; Start of new object

(Obj_basic_diagnostics)

0153622178.00↵↓ ; Height

0153632079.00↵↓ ; Weight

0148402BDM01↵↓ ; Examination: 24h blood pres-

sure

017620023101998↵↓ ; Date of the examination

0346220Dies∨ist∨ein∨zweizeiliger↵↓ ; Findings 1st line (0346220This

is a two line …)

0416220Befund∨zur∨24h-Blutdruckmessung.↵↓ ; Findings 2nd line

(…0416220finding of a 24h

blood pressure reading)

0566227Anmerkungen∨zu∨einer∨Langzeit-Blutdruckmessung.↵↓ ; Commentary

(056627Commentary to a

permanent blood-pressure

reading

0506228Kurzzusammenfassung∨24∨h∨Blutdruckmessung↵↓ ; formatted text of results (Con-

clusion of the results)

0596228--------------------------------------------------↵↓


0596228∨∨∨∨∨∨∨∨∨∨diurnal phase∨∨∨∨∨∨∨nocturnal phase∨∨∨percentage loss ↵↓

0596228∨∨∨∨∨∨∨∨∨6 AM – 10 PM∨∨∨∨∨10 PM – 6 AM∨∨∨∨∨Day/Night↵↓

0596228Ps[mmHg]∨∨∨∨∨143∨∨∨∨∨∨∨∨∨∨∨∨∨∨134∨∨∨∨∨∨∨∨∨∨∨∨∨∨-6∨%↵↓

0596228Pd[mmHg]∨∨∨∨∨∨92∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨92∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨0∨%↵↓

0596228HF[P/min]∨∨∨∨∨∨71∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨70∨∨∨∨∨∨∨∨∨∨∨∨∨-1∨%↵↓

0168410SYSMXTG↵↓ ; Test identification (Manufac-

turer specific)

0298411Systole∨max∨Tagphase↵↓ ; Name of the test (Systole

max. diurnal phase)

0128420142↵↓ ; Value

0138421mmHg↵↓ ; Unit

017843223101998↵↓ ; Date of reading

0158439163400↵↓ ; Time of reading

0128462140↵↓ ; Upper limit

0168410SYSMNTG↵↓ ; Next test identification

0298411Systole∨min∨Tagphase↵↓ ; Name of the test (Systole min.

diurnal phase)

0128420112↵↓ ; Value

0138421mmHg↵↓ ; Unit

017843224101998↵↓ ; Date of reading

0158439031200↵↓ ; Time of reading


011820244↵↓

∨ = blank space (20 hex) resp. (32 decimal) ↵ ↓ = CR and LF (0D 0A hex) resp. (13 10 decimal)

3 Code page In the following, the record types 6300, 6301, 6302, 6310 and 6311, which are the ones defined for the connection of medical devices, are described Every record starts with the field “8000” which marks the respective record type. Only the record type 6300 “Request master data” (Stammdaten anfordern) requires the record type 6301 “Transmission of master data” (Stammdaten übermitteln) in response. The other record types (6301, 6302, 6310 and 6311) can be transmitted at any time and do not require a response. Generally, the following directions of communication can be applied: 6300: DEVICE PVS 6301: PVS DEVICE


6302: PVS DEVICE 6310: DEVICE PVS 6311: PVS DEVICE DEVICE = Medical device PVS = Medical office administrative system ((Arzt-)PraxenVerwaltungsSystem) Please note:

• The objects described in the record types are stored in a separate file „GDT-Objektkatalog“ (GDT object catalogue). Updates to the objects are performed in this file, but it has no influence on the currently present version of the interface.

• Column “Occurrence” The frequency of the field is presented in the column “Occurrence” whereas the specifica-tion “n” marks those fields which can occur any number of times. Additionally, a level of hierarchy is allocated to every field in the column “Occurrence” . This means the appear-ance of this field is connected to the existence of another field, that is exactly the field which the superior level of hierarchy refers to.

• In The column “Existence”, M and C stands for ‘must’ or ‘can’ exist.

• The following exemplary extract of a record chart shall illustrate the structure of a record according to the specifications in the column “Occurrence”

Field iden-tifier

Occurrence Label Existence Annotations

1 2 3 4 of the field contents must/can (M/C)

Condition

… 8401 1 Field 8401 can only occur one time

per record … 8410 n Field 8410 can occur any number of

times 8411 1 Field 8411 can only occur one time

per field 8410 … 8460 n Field 8460 can occur any number of

times per 8410.


3.1 Definition of record types: Request master data (Stammdaten anfordern) „6300“

SA 6300 Field iden-tifier


Änd. 1 2 3 4 of the field contents M/C Condition 8000 1 Record identification M Record type: Request master data 8100 1 Length of record C Length of record Header data

xxxx 1 Obj_Kopfdaten (Obj_header_data)

M See Annex D

Patient xxxx 1 Obj_Patient M See Annex D Health-insurance card

xxxx 1 Obj_Versichertenkarte (Obj_health-insurance_card)

C See Annex D

8202 1 End of record M Contains the number of transmitted fields including FK 8000 and FK 8202

3.2 Definition of record types: Transmission of master data (Stammdaten übermitteln) „6301“



Änd. 1 2 3 4 of the field contents M/C Condition 8000 1 Record identification M Record type: Transmission of master

data 8100 1 Length of record C Length of record Header data


M See Annex D

Patient xxxx 1 Obj_Patient M See Annex D basic diagn.

xxxx 1 Obj_Basisdiagnostik (Obj_basic_diagnostics)

C See Annex D

Health-insurance card


C See Annex D


3.3 Definition of record types: Request new examination (Neue Un-tersuchung anfordern) „6302“



Änd. 1 2 3 4 of the field contents M/C Condition 8000 1 Record identification M Record type: request new examination 8100 1 Length of record C Length of record Header data


M See Annex D

Patient xxxx 1 Obj_Patient M See Annex D Request xxxx 1 Obj_Anforderung (Obj_request) M See Annex D basic diagn.


C See Annex D

Perma-nent medica-tion

xxxx 1 Obj_Dauermedikament (Obj_permanent_medication)

C See Annex D

Request xxxx 1 Obj_Anforderung (Obj_request) C See Annex D




Änd. 1 2 3 4 of the field contents M/C Condition Perma-nent diagnosis

xxxx 1 Obj_Dauerdiagnosis (Obj_permanent_diagnosis)

C See Annex D



C See Annex D

Referral xxxx 1 Obj_Überweisung (Obj_referral) C See Annex D Diagnosis xxxx 1 Obj_Diagnosis C See Annex D Annex xxxx 1 Obj_Anhang (Obj_Annex) C See Annex D Receiver xxxx 1 Obj_Empfänger (Obj_receiver) C See Annex D Physician identifica-tion

xxxx 1 Obj_Arztidentifikation (Obj_physician_identification)

C See Annex D


3.4 Definition of record types: Cancel requested examination (Angeforderte Untersuchung stornieren) „6303“



Änd. 1 2 3 4 of the field contents M/C Condition 8000 1 Record identification M Record type: cancel requested exami-

nation 8100 1 Length of record C Length of record Header data


M See Annex D



C See Annex D

Request xxxx 1 Obj_Anforderung (Obj_request) C See Annex D Perma-nent medica-tion

xxxx 1 Obj_Dauermedikament (Obj_permanent_medication)

C See Annex D

Perma-nent diagnosis

xxxx 1 Obj_Dauerdiagnosis (Obj_permanent_diagnosis)

C See Annex D



C See Annex D

Referral xxxx 1 Obj_Überweisung (Obj_referral) C See Annex D Diagnosis xxxx 1 Obj_Diagnosis C See Annex D Annex xxxx 1 Obj_Anhang (Obj_Annex) C See Annex D Receiver xxxx 1 Obj_Empfänger (Obj_ receiver) C See Annex D Physician identifica-tion


C See Annex D



3.5 Definition of record types: Transmission of examination data (Daten einer Untersuchung übermitteln) „6310“



Änd. 1 2 3 4 of the field contents M/C Condition 8000 1 Record identification M Record type: Transmission of exami-

nation data 8100 1 Length of record C Length of record Header data


M See Annex D



C See Annex D

Request xxxx 1 Obj_Anforderung (Obj_request) M See Annex D Health-insurance card


C See Annex D

6200 1 Day of storage for treatment data C MMDDYYYY of examination 6205 n Current Diagnosis C 6206 1 Central pharmaceutical number C 6210 1 Medication prescribed M If 6206

exists

6211 1 Medication without prescription M If 6206 exists

6214 1 Number of packages (factor) C 6218 1 Information about intake C 6406 1 Free of charge C 0=no, 1=yes 6407 1 Nocturnal C 0= no, 1=yes 6408 1 BVG C 0= no, 1=yes 6409 1 Accident C 0= no, 1=yes 6431 1 Me-too prescription C 0= no, 1=yes 6220 N Findings C 6221 N External findings C e.g. findings notice generated by the

device 6227 N Commentary C 6226 N Number of following lines after the

identifier C With this, the GDT length restriction in

6228 transmissions can be bypassed. For example, if the value 2 is assigned here, the following two 6228 lines make an overall row that should be assembled by the receiver.

6228 n Result text, formatted m If 6226 exists

Random result text, formatted by the device

Annex xxxx 1 Obj_Anhang (Obj_Annex) C See Annex D 6330, n Name of the free category C Even and

following odd field identifiers belong together.

6332, 6334, … 6398 6331, 1 Content of the free category M If previous

field identi-fier “Name of the free category” exists.

6333, 6335, … 6399 8405 1 Patient information C




Änd. 1 2 3 4 of the field contents M/C Condition Physician identifica-tion


C See Annex D


3.6 Definition of record types: Display data of an examination (Daten einer Untersuchung zeigen) „6311“



Änd. 1 2 3 4 of the field contents M/C Condition 8000 1 Record identification M Record type: display data of an exami-

nation 8100 1 Length of record C Length of record Header data


M See Annex D

Patient xxxx 1 Obj_Patient M See Annex D Request xxxx 1 Obj_Anforderung (Obj_request) M See Annex D 4111 1 Health insurance number C Physician identifica-tion


C See Annex D



4 Field chart A chart of the field identifies that are used in the record types 6300, 6301, 6302, 6310, 6311. * Changes in the field chart are labeled as following at the most left column: * L Change of length * N New field which has been allocated only for the “GDT” version in accordance with the

Central Institute * R Rule changes to preceding version

Rule number for format and content checks * Nx.x New field from version x.x onwards * Obj Reference to object catalogue. Field identifier is described there Field

identifier Label Length Type Rule Example

0102 Person/company responsible for software

var (alphanumeric)lnum e.g. company

0103 Software var alnum Name of the software

0132 Release stage of software var alnum 12.4

0201 (N)BSNR: Establishment num-ber

9 num 947812345

0202 Name of the payer var alnum German Federal Pension Fund

0212 LANR (lifetime physician num-ber)

9 num 123456789

0950 Central pharmaceutical number for permanent medication

var alnum 4877800

0957 Administration form for perma-nent medication

var alnum Caplet

3000 Patient number/patient ID var alnum 123456

3100 Name affix of the patient var alnum Von

3101 Name of the patient var alnum Doe

3102 First name of the patient var alnum Jane

3103 DOB of patient (MMDDYYYY) 8 date 020/304 04121946

3104 Title of the patient var alnum Dr.

3105 Health-insurance number of the patient

var alnum 123456M789

3106 Full residence of the patient var alnum 50859 Cologne (Germa-ny)

3107 Home street of the patient var alnum Holzweg 106

3108 Type of insurance, MFR 1 num 116 3

3110 Gender of the patient 1 num 112 1


Field identifier

Label Length Type Rule Example

3112 Postal code of the patient var alnum 50859

3113 Hometown of the patient var alnum Cologne

3114 Residence country code var alnum GER

3116 Health-insurance area 2 num 17

3119 Health-insurance number (elec-tronic health card in Germany) of the patient

10 alnum A123456780

3618 Cellphone number of the patient var alnum 0049-172 9335 172

3619 Email address of the patient var alnum [email protected]

3622 Height of the patient in cm var float 175.50

3623 Weight of the patient in kg var float 90.50

3626 Phone number of the patient var alnum 0049-951 3458 200

3628 Native language of the patient var alnum English

3649 Start of permanent diagnosis 8 date 01012012

3650 Permanent diagnosis var alnum Diabetes mellitus

3651 Start of permanent medication 8 date 12112011

3652 Permanent medicament var alnum Adalat

3654 Risk factor var alnum Smoker

3656 Allergies var alnum Neurodermatitis

3658 Accidents var alnum Motor bike accident

3660 Surgeries var alnum Appendix

3662 Anamnesis var alnum Premature delivery

3664 Number of deliveries var num 2

3666 Number of children var num 3

3668 Number of pregnancies var num 4

3670 Permanent therapy var alnum Patient-controlled Anal-gesia (PCA)

3672 Follow-up appointment 8 date 01121993

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

3674 Diagnostic confidence for per-manent diagnosis

1 alnum Z

3675 Body side localization for per-manent diagnosis

1 alnum R

3676 Diagnosis explanation for per-manent diagnosis

var alnum ECG definite

3677 Diagnosis derogation for per-manent diagnosis

var alnum true


Field identifier


3700 Label of the basic-diagnostic category

var alnum Cardiovascular family history

3701 Content of the basic-diagnostic category

var alnum Yes

4104 No. of contracted health insur-ance

5 num 27106

4106 Payer billing area 2 num 00

4109 Day of last reading of the healh-insurance card in the quarter

8 date 07082012

4110 Valid-to date 4 num 0913

4111 Health-insurance number 7 num 12568008

4112 Insurance status 4 num 1000

4113 Status addition / DMP-labeling 1 alnum 1

4121 Schedule of fees 1 num 1

4122 Billing area 2 num 00

4200 Desired date (MMDDYYYY) var alnum 05142002

4202 Accident, Consequences of accident

1 num 1

4203 Treatment according to . § 116b SGB V

1 num

4204 Restricted entitlement according to § 18 Abs. 3a SGB V

1 num 1

4205 Assignment var alnum

4207 (Suspected) Diagnosis var alnum Suspected hepatitis

4208 Findings / Medication var alnum

4209 Assignment/diagnosis/suspicion var alnum X-ray left hand

4217 (N)BSNR: Establishment num-ber of the initiator

9 num 123456700

4218 (N)BSNR Establishment number of the referring person

9 num 234567800

4219 Referral from other physician var alnum General medicine

4220 Referral to var alnum Radiologist

4221 Type of treatment 1 num 1

4229 Exceptional medical indication 5 num 32005

4231 Follow-up exam of a known infection

1 num

4237 Hospital name var alnum XYZ General Hospital

4241 LANR (lifetime physician num-ber) of the initiator

9 num 123456789


Field identifier


4242 LANR (lifetime physician num-ber) of the referring person

9 num 234567890

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

6003 Diagnostic confidence 1 alnum Z

6004 Body side localization 1 alnum R

6006 Diagnosis explanation var alnum clinical

6008 Statement of facts for a diagno-sis derogation

var alnum Condition after gender reassignment

6200 Day of storage of treatment data (MMDDYYYY)

8 date 008 12261993

6201 Time of treatment data elicita-tion

6 time 110435

6205 Current diagnosis var alnum Diabetes test

6206 Central pharmaceutical number var alnum 4877800

6210 Medication prescribed var alnum Adalat

6211 Medication without prescription var alnum Sostril

6214 Number of packages (factor) 3 num 008

6218 Information about intake var alnum 1-0-0

6220 Findings var alnum High blood pressure

6221 External findings var alnum Suspicion of obstruction

*N2.1 6226 Number of following lines after the identifier 6228

var num 2

*N 6227 Commentary var alnum Belastung abgebrochen

*N 6228 Formatted result charts text var alnum See examples in annex

6302 File archiving label var alnum 000001

6303 File format var alnum PDF

6304 Content of file var alnum File analysis

6305 File path var alnum \\FS1\DATA\00712.PDF

6329 Content of the file in BASE64-coded attachment

var alnum

*N2.1 6330-6398

Name of the free category var alnum PATINFO

*N2.1 6331-6399

Content of the free category var alnum Patient is cheerful

6406 Free of charge 1 num 0=no, 1=yes

6407 Noctu 1 num 0=no, 1=yes

6408 BVG 1 num 0=no, 1=yes

6409 Unfall 1 num 0=no, 1=yes


Field identifier


6431 Aut Idem 1 num 0=no, 1=yes

8000 Record identification 4 alnum 6301

8100 Length of record 7 num 0000747

8200 ObjektIdent (object identifier) var alnum e.g.: Obj_Kopfdaten (Obj_header_data)

8201 End of object var num Contains the number of transmitted fields in the object, including 8200 and 8201

8202 End of record var num Contains the number of transmitted fields in the record, including 8000 and 8202 (Example: 7)

8310 Request identifier var alnum 223

8314 Request UID var alnum Secured and unique request ID (UID)

*N 8315 GDT-ID of the receiver var alnum ROP200U1

*N 8316 GDT-ID of the sender var alnum PRAX_PVS

*L 8402 Device and process specific characteristic map

var alnum ECG01, see Annex B

8403 Schedule of fees 1 num 1

8404 Subcategory to field identifier 8402

Left kidney

8405 Information about patient var alnum Additional information: Overweight

8407 Gender 1 num 2

8410 Test identifier var alnum FEV1

8411 Label of test var alnum Obj. refr. cyl. right

8412 Test-OID var alnum

8413 Test/device ID var alnum

8418 Status of the test 1 alnum B

8420 Result value var float -3.70

8421 Unit var alnum Diopter

8425 Budget-free 1 num 1

8428 Sample identifier var alnum SE

8429 Sample index 2 num 01

8430 Sample label var alnum Smear test

8431 Sample specification var alnum Left eye

8432 Date of collection (MMDDYYYY) 8 date 008 01311994


Field identifier


8433 Time of collection 6 time 091520

*N 8437 Unit(s) for data stream var alnum Min, mmHg, mmHg

*N 8438 Data stream var alnum 5,120,80… or (5,120,80),(10,128,92)… can contain float values

*N*R 8439 Time of collection 6 time 090 125600

8460 Normal value text var alnum negative

*N 8461 Normal value lower bound var float -15.00

*N 8462 Normal value upper bound var float 12.00

8470 Test-related notes var alnum Frozen serum required

8480 Results text var alnum negative

8501 Urgency 1 num 1 (1=emergency, 2=urgent)

8504 Intake of medication at the time of sample collection

var alnum

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

8511 Gestation length (in weeks, days)

3 num 24,2

8512 1st day of cycle (MMDDYYYY) 8 date 09102012

8601 Name of invoice recipient var alnum Doe

8602 Title, Forename of invoice recip-ient

var alnum Dr. Jane

8606 City of residence of the invoice recipient

var alnum 50226 Cologne

8607 Street of residence of the in-voice recipient

var alnum Main Street 1

8608 Commentary/Reference number var alnum 222/234AH

8609 Type of billing 1 alnum P

8610 Private charges 1 num 2

8615 Principal var alnum 123456600

8990 Signature (sign of initials) var alnum Dr. Huber

9103 Date of creation (MMDDYYYY) 8 date 10202012

*N2.1 9152 Counter URL 4 num 1

*N2.1 9153 Description URL var alnum Data scale of Pat. 00712

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

*N2.1 9206 Used character set 1 num 2

*N 9218 Version GDT 5 alnum 03.00


date = Date in the format MMDDYYYY time = Time in the format HHMMSS num = numerical, fields with fixed lengths have to be filled with leading zeros alnum = alphanumerical float = Floating-point number with a dot as decimal mark.

5 Chart of rules The rules are divided into number ranges according to their nature: 000 – 099 Format check 100 – 199 Content check 200 – 299 Existence check 300 – 399 Context check

No. of rule.

Category Check Description

008 Format MMDDYYYY MM=Month, DD=Day, YYYY=Year

020 Format MMDDYYYY Range of value: MM=00-12, DD=00-31; JJJJ=0000-9999

090 Format HHMMSS HH=Hours; MM=Minutes; SS=Seconds

Range of value: HH=00-24; MM=00-59; SS=00-59 (possibly miss-ing seconds have to be inserted with 00)

112 Allowed content 1, 2

116 Allowed content 1, 2, 5 Type of insurance MFR

304 Context Datum kleiner oder gleich Maschinendatum

Avoid key errors

6 Annex 6.1 Annex A: Block format for serial data transmission, including

examples 6.1.1 Transmission protocol The file is transferred in blocks. The reception of a transmission block has to be confirmed within 10 seconds by sending an ACK (06h), followed by a 1 (31h) for a complete and correct transmis-sion or a 0 (30h) for an incomplete transmission. 6.1.2 Transmission block A transmission block is constructed as follows: <Send sequence number><Label>[<data field>]<CRC-16><CR>


6.1.3 Meaning of the respective fields

Send sequence number Length: 1 Byte The send sequence number is incremented cyclically from 1 (31h) to 9 (30h). If the same trans-mission block has to be resent because of a faulty transmission, the send sequence number re-mains the same. The value 0 (30h) is used for synchronization. It is used for the first transmission after switching on the device and after the occurrence of transmission errors. Label Length: 3 Bytes The following labels are defined: B00 Start of transmission / first data block B01 Data block B02 End of transmission / last data block Data field Length: max. 128 Bytes The data field contains the actual data. Multiple lines can be combined into a data field. A line can also be distributed across several data fields. The character 1 Ch (field separator FS) is used for the separation of two lines. The record length and length of lines are calculated including CR /LF. With the exception of the field separator, no ASCII-characters smaller than 20h may be used within the data field. CRC-16 Length: 4 Bytes 16 Bit CRC within send sequence number, label and data field. The value is sent as ASCII-Hex. Example: 2A9Eh is sent as 32h 41h 39h 45h. (To generate the checksum according to CRC-16, please refer to the source code examples of older GDT record descriptions or to sources from the internet, such as “WIKIPEDIA”.) CR Length: 1 Byte Carriage return (0Dh) completes the data block. 6.1.4 Examples Please note: The character ‚|‘ signifies the field separator (1Ch). For illustrational purposes the data field length has been limited to 32 characters. 6.1.4.1 Request of master data (see definition charts on p. 19ff. for translation of the ob-

ject names)


Client sends: 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 responds: 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 Procedure when transmission errors occur Upon receipt of <ACK> 0 or after the occurrence of a timeout, the last transmission block is sent again. If an error occurs two times in a row, the send sequence number is set back to 0 and the transmission is repeated from the first data block. After the second unsuccessful attempt to trans-fer the file, the transmission is aborted. The error handling takes place on a higher level.


6.1.4.3 Examples for transmissions including errors Repetition of a transmission block C: 1B00 01380006300|01681000000119|0228200Obj_Kopfdaten|0178315QMS-<CRC> <CR> S: <ACK> 1 C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR> S: <ACK> 0 Error occured Resend data block with the same send sequence number (in this example, number 2) C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR> S: <ACK> 1 this time the data block is received correctly Synchronization after transmission errors C: 1B00 01380006300|01681000000119|0228200Obj_Kopfdaten|0178315QMS-<CRC> <CR> S: <ACK> 1 C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR> S: <ACK> 0 Error occured Resend data block with the same send sequence number (in this example, number 2) C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR> S: <ACK> 0 Error occurred a second time C: 0B00 01380006300|01681000000119|0228200Obj_Kopfdaten|0178315QMS-<CRC> <CR>

New synchronization with send se-quence number 0

S: <ACK> 1 C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR> S: <ACK> 1 Abortion of a transmission after transmission errors C: 1B00 01380006300|01681000000119|0228200Obj_Kopfdaten|0178315QMS-<CRC> <CR> S: <ACK> 1 C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR> S: <ACK> 0 Error occured Resend data block with the same send sequence number (in this example, number 2) C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR> S: <ACK> 0 Error occured


C: 0B00 01380006300|01681000000119|0228200Obj_Kopfdaten|0178315QMS-<CRC> <CR> New synchronization with send se-quence number 0

S: <ACK> 1 C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR> S: <ACK> 0 Error occured C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR> S: <ACK> 0 Error occured Sender stops the transmission. Receiver remains in standby mode. Transmission error at request of master data The problem that both client and server try to send a file can occur in the following situation: 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]

Confirmation of receipt sent by server but the client does not receive it C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028<CRC> <CR>

Repeated transmission of the same block S: 7B00 01380006301|01681000000217|<CRC> <CR> Server already sends the 1st block of

the requested master data C: 0B00 01380006300|01681000000119|0228200Obj_Kopfdaten|0178315QMS-<CRC> <CR> Repeated transmission by the client with a new synchronization S: 7B00 01380006301|0158100000217|<CRC> <CR> Server repeats transmission of the

1st block of the master data (ACK 1 of the client is missing)

C: 0B00 01380006300|01681000000119|0228200Obj_Kopfdaten|0178315QMS-<CRC> <CR> Client repeats attempt of synchroni-

zation


S: 0B00 01380006301|0158100000217|<CRC> <CR> Repeated transmission by the serv-

er with new synchronization S: 0B00 01380006301|01681000000217|<CRC> <CR> Server repeats attempt of synchro-

nization The transmission is aborted by server and client after the timeout (“wait for ACK”) (see 6.1.4.2).


6.2 Annex B: Device and process specific characteristic map „8402“

Field 8402 was defined as follows in the revision of the GDT: Field identifier: 8402 Label: Device and process specific characteristic map Function: The field is used to group the transmission data. Typ: The previous type of 2 (alnum) was extended to 1-6 (alnum). Regel: The content of the field consist of one text part with a maximum of 4 char-

acters for the group identifier plus a following 2-digit number ranging from 00-99 (e.g. LUFU09). The number 00 is thereby generally reserved as field identifier for non-specified examinations. The group identifier ALLG (gener-ally ALLG00) is appointed for non-classified examinations.

The list of field contents is dynamic and is centrally administered by the ZI (CI). The subse-quently listed groups and field identifiers are therefore only a first draft which is optionally extend-able. Contrary to the field identifier 8402, the respective Testidents (test identifiers) can be assigned manufacturer-specifically. ALLE__ Allergology

ALLE01 Allergological anamnesis ALLE02 Allergological findings ALLE03 Allergological diagnosis ALLE04 Prick test ALLE05 Intradermal test ALLE06 Challenge test (e.g. histamine challenge test) ALLE07 In vitro test ALLE08 Insect poison ALLE09 Patch test ALLE10 Daily desensitization

ALLG__ Examinations, general

ALLG00 Non-classified examinations APNO__ Sleep apnea examinations

APNO00 Apnea, general APNO01 Long-term sleep apnea screening APNO02 Polysomnography

AUDI__ Audiometric examinations


AUDI00 Audiometry, general AUDI01 Pure-tone audiogram AUDI02 EEG-Audiometry

BDM__ Measurement of blood pressure

BDM00 Measurement of blood pressure, general BDM01 Long-term measurement of blood pressure

CTG__

Cardiotocography

CTG01 Cardiotocography DERM__ Dermatology

DERM01 Dermal camera (serial) DICO__ DICOM

DICO01 CT DICO02 MRT

EKG__ Electrocardiography

EKG00 ECG, general EKG01 Resting-ECG EKG02 Arrhythmia-ECG EKG03 Late potentials ECG EKG04 Long-term ECG

ERGO__ Stress examinations

ERGO00 Stress-examinations, general ERGO01 Stress-ECG ERGO02 Stress flow-volume ERGO03 Blood gases ERGO04 Stress blood gases ERGO05 Spiroergometry ERGO06 Breath gas analysis ERGO07 Pulse oximetry ERGO08 Indirect Calorimetry ERGO09 Indirect Calorimetry with canopy cover ERGO10 Cardiac output determination via CO2 feedback ERGO11 Respiratory drive measurements via CO2 feedback


FILE__ File transfer

FILE01 Camera (Video/Digital), general via interface HÄMA__ Blood count

HÄMA01 Smaller blood count HÄMA02 Major blood count HÄMA03 Manual differential leukocyte count HÄMA04 Reticulocytes HÄMA05 CD4/CD8

LUFU__ Pulmonary function test

LUFU00 Pulmonary function, general LUFU01 Slow spirometry LUFU02 Forced spirometry (flow volume) LUFU03 MVV (Maximal Voluntary Ventilation) LUFU04 Body plethysmography LUFU05 FRC pl (lung volume – Body plethysmography) LUFU06 FRC He (lung volume – Helium feedback) LUFU07 Resistance after wedge pressure method LUFU08 Resistance after impulse oscillation method LUFU09 Resistance after oscilloresistometry method LUFU10 Compliance LUFU11 Measurement of respiratory muscles LUFU12 Measurement of respiratory drive LUFU13 Diffusion Single-Breath LUFU14 Diffusion Steady-State LUFU15 Diffusion Rebreathing LUFU16 Diffusion membrane factor LUFU17 Capnography LUFU18 Rhinomanometry LUFU19 Calm breath analysis

NEUR__ Neurological measurement

NEUR00 Neurology, general NEUR01 Long-term EEG NEUR02 EEG with simultaneous ECG recording NEUR03 Motoric NLG


NEUR04 Sensorial NLG NEUR05 Evoked potential responses NEUR06 Rotational testing NEUR07 Nystagmus analysis NEUR08 Saccades test NEUR09 Posture NEUR10 Biofeedback NEUR11 ERG/EOG NEUR12 EMG of the eye muscles

NULL__ Empty Device

NULL01 Empty Device, only for sending patient master data to the database

OPTO__ Ophthalmology

OPTO00 Ophthalmology, general OPTO01 Monocular testing, objective OPTO02 Monocular testing, subjective OPTO03 Monocular testing glasses/contact lense OPTO04 Aperture sensitivity measurement (visual acuity) OPTO05 Perimetry measurement OPTO06 Intraocular pressure measurement OPTO07 Cornea measurement (curvature/axial position) OPTO08 Cornea measurement (3D geometry data) OPTO09 Fundus images OPTO10 Angiography images OPTO11 Slit lamp images OPTO12 Topography images OPTO13 Layer images OPTO14 Generic image data

PROV__ Provocation Test

PROV00 Provocation, general PROV01 Specific Aerosol provocation PROV02 Unspecific Aerosol provocation PROV03 Cold air provocation PROV04 Bronchodilatation


SCAN__ Scanner SCAN01 Scanner, general with TWAIN standard

SONO__ Sonography measurements

SONO00 Sonography, general SONO01 Ultrasound doppler

URO__ Urology

URO00 Urology, general URO01 Uroflowmetry

VDDS__ VDDS dental interface

VDDS01 Dental x-ray system with VDDS interface VIDE__ Video coverage

VIDE01 Sonography VIDE02 Angiography VIDE03 Endoscopy VIDE04 Laparascopy VIDE05 Arthroscopy VIDE06 Microscopy VIDE20 C-arm

XRAY__ X-ray image

XRAY01 X-ray image


6.3 Annex C: Transmission of measurement data Measurement data can have various dimensions. In the easiest case, there is only one single result value, a one-dimensional number which is important in itself.

0 reading point This case of one or more one-dimensional numbers is represented in the GDT with the following sequence 8410 Test-Ident … 8420 Result value Example (Body height at a certain time): 8410 Height … 8420 184 Often, however, the development of measuring data compared to equidistant time frames.

Time [months] This case can easily and effectively be displayed with the sequence 8410 Test-Ident … 8417 Bitstream (as single value) Example (Body height over a specific period):

8410 Height … 8417 184,185,187,190,190 If the measuring data is not equidistant, the second dimension has to be directly indicated: 8410 Test-Ident … 8417 Bitstream (as a couple)

Height [cm]


Again the same example (Body height and months since start of measurement):

8410 Height … 8417 (184,0),(186,2),(188,7),(190,20) The illustration of several measurement parameters is possible since the sequence 8410 … 8417 can occur n-times. Again the same example (but with the additional evolution of weight next to height):

a) At equidistant measurement values (Height and weight were measured in the same time frames):

8410 Height … 8417 (184,65),(186,65),(188,69),(190,72)

b) If, however, the measurement values were measured at different times, which means that for every value an additional time reference is given, the following sequence occurs:

8410 Height … 8417 (184,0),(186,2),(188,7),(190,20) … 8410 Weight … 8417 (65,0),(66,4),(69,7),(72,20) Extension of the GDT compared to Version 1.0 But what happens, if the measurement values of several samples (or samples taken at different times) shall be transmitted at the same time, to be displayed comparatively by an analysis pro-gram? Until now, the GDT did not offer a direct possibility for such a scenario. Measurement values

Sample 1

Sample 2 Time


Therefore, sample and time of the measurement are defined as a new level of hierarchy: 3000 Patient data … 8402 Measuring device … 8405 Sample … 8406 Date 8407 Time … 8410 Test-Ident … 8420 Measurement values … or 8417 multiple measurement values With the additional introduction of time as a hierarchy level, time series can be transmitted more easily and clearly (compared to the use of multidimensional tuples in field 8417). The possibility of transferring time as an autonomous dimension in the field 8417 continues to exist, however. This gives the following set of data representation: 6310 record Existence 1 2 3 4 3000 Patient data 1 … 8402 Device 1 … 6205-6228 Description 1 … 8405 Sample n … 8406 Date 1 8407 Time 1 8410 Test-Ident n … 8417 Bitstream n


… 8420 Messwert (alternativ) 1 This kind of display allows the directional representation of all necessary measurement data. It is downward compatible to the GDT Version 1.0! If the fields 8405 (Sample) and 8406 (Date) exist only once or not at all, the structure of the record set is the same (as far as the illustration of data is concerned) as in the GDT Version 1.0.

6.4 Annex D: Building Blocks / Objects Here you find the list of objects that are used in the record description. You can find a detailed description of these objects (composition of the field labels, rules for their existence, descriptions, etc.) in the document “Object catalogue as extension to the xDT data record description” (‘Objektkatalog als Ergänzung zu den xDT-Datensatzbeschreibungen’ in German).

Obj_Anforderung (Obj_request)

Obj_Diagnosis Obj_Schein (Obj_certificate)

Obj_Anhang (Obj_annex) Obj_Einweisung (Obj_admission)

Obj_Terminanfrage (Obj_appointment_request)

Obj_Arztidentifikation (Obj_physician_identification)

Obj_Kopfdaten (Obj_header_data)

Obj_Ueberweisung (Obj_referral)

Obj_Basisdiagnostikdia (Obj_basic_diagnostics

Obj_Patient Obj_Versichertenkarte (Obj_health-insurance_card)

Obj_Dauerdiagnosis (Obj_permanent_diagnosis)

Obj_RgEmpfänger (Obj_invoice_recipient)

Obj_Dauermedikament (Obj_permanent_medication)

Obj_Satzende (Obj_end_of_record)


6.5 Example files “Best Practice“ The following example files show common practical processes with their required field labels and record types: Key notes: DEVICE = Medical device, PVS = (Arzt-)PraxenVerwaltungsSystem (medical office administrative system) 6.5.1 Request master data “6300” (DEVICE to PVS) Construction of record type 6300 Commentary Request master data (6300) is a pro-

cess from the medical device (DEVICE) to the PVS. In the object Obj_Patient, an identification can occur via 3119 as an alternative to the patient number. Otherwise, the data of the current pa-tient is requested.

1. Obj_Kopfdaten (Obj_header_data)

2. Obj_Patient

3. Obj_Satzende (Obj_end_of_record)

Process: DEVICE to PVS. Example as before 6.5.2 Transmission of master data “6301” (PVS to DEVICE) Construction of record type 6301 Commentary Example of a minimal master data

transmission; generally the object Obj_ArztIdent (Obj_physician_identification) should be transferred in every process where the PVS sends data to the DEVICE.


2. Obj_Patient

3. Obj_ArztIdent (Obj_physician_identification)


Process: PVS to DEVICE. Example with physician identification 6.5.3 Request new examination “6302” (PVS to DEVICE) Example 1: Construction of record type 6302 Commentary Minimal version. The request of an ex-

amination, including the physician identi-fication and the request identification. 1. Obj_Kopfdaten (Obj_header_data)

2. Obj_Patient

3. Obj_Anforderung (Obj_request)




Process: PVS to DEVICE. In this case with physician identification Example 2: Construction of record type 6302 Commentary Request of an examination including

data of the health insurance card as well as detailed permanent medical infor-mation and the basic diagnosis.


2. Obj_Patient


4. Obj_Versichertenkarte (Obj_health-insurance_card)

5. Obj_Basisdiagnostik (Obj_basic_diagnostics)

6. Obj_DauerDiag (Obj_permanent diagnostics)

7. Obj_DauerMed (Obj_permanent_medication)



Process: PVS to DEVICE. In addition to the must-have objects Obj_Kopfdaten (Obj_header_data) and Obj_Patient, the objects Obj_Versichertenkarte (Obj_health-insurance card), Obj_Basisdiagnostik (Obj_basic diagnos-tics), Obj_DauerMed (Obj_permanent_medication), and Obj_DauerDiag (Obj_permanent_diagnosis) are transmitted. The medical device is initialized with the permanent medi-cal data, the basic diagnosis and the insurance data. 6.5.4 Transmission of examination data “6310” (DEVICE to PVS) Construction of record type 6310


2. Obj_Patient

3. Obj_Untersuchung (Obj_exam)

4. Obj_Anhang (Obj_annex)


Process: DEVICE to PVS


6.5.5 Display data of an examination “6311” (PVS to DEVICE) Construction of record type 6311


2. Obj_Patient




Process: PVS to DEVICE; The specification says 4111, but this is not listed in the example. 6.5.6 Appointment request “6302” (PVS to DEVICE) Construction of record type 6302 Commentary For an appointment request, the fields

SMS text message and email address have to be filled out in the object Obj_Patient, to guarantee confirmation of the appointment. In the object Obj_Terminanfrage, the listing of the suspected diagnosis as well as the re-quest of referral to a specialist, are es-pecially important for the ongoing work-flow.


2. Obj_Patient


4. Obj_Terminanfrage (Obj_appointment_request)



Process: PVS to DEVICE; Phone number for text message or email address have to be assigned to the object Obj_Patient 6.5.7 Referral to specialist “6302” (PVS to DEVICE) Construction of record type 6302 Kommentar With the process referral to specialist,

an appointment request is initiated, which includes detailed permanent med-ical data and the basic diagnosis. The object Obj_Untersuchung (Obj_exam) can be used to provide previous find-


2. Obj_Patient




ings. The object Obj_Anhang (Obj_annex) can be used to display the declaration of content or previous find-ings of other physicians. 5. Obj_Basisdiagnostik (Obj_basic_diagnostics)


7. Obj_Einweisung (Obj_admission)







Process: PVS to DEVICE; Phone number for text message or email address have to be assigned to the object Obj_Patient 6.5.8 Hospitalization “6302” (PVS to DEVICE) Construction of record type 6302 Commentary With the process hospitalization, an

appointment request is initiated, which includes detailed permanent medical data and the basic diagnosis. The object Obj_Untersuchung (Obj_exam) can be used to provide previous findings. The object Obj_Anhang (Obj_annex) can be used to display the declaration of content or previous findings of other physicians.


2. Obj_Patient





7. Obj_Einweisung (Obj_admission)








Process: PVS to DEVICE; Phone number for text message or email address have to be assigned to the object Obj_Patient 6.5.9 Transmission of emergency data “6302” (PVS to DEVICE) Construction of record type 6302 Commentary In the area of emergency cases, the

provision of permanent medical infor-mation and basic diagnostics is crucial. Additionally, the required emergency data set can be initialized with this rec-ord type.


2. Obj_Patient





7. ArztIdent (Obj_physician_identification)


Process: PVS to DEVICE


7 Illustration of the workflows The GDT interface was created for the communication of the PVS with all kinds of medical devic-es (DEVICE). The PVS thereby transmits chosen master data and, if applicable, medical data of a patient to the medical device. The concept of the GDT interface is based on one basic work-flow. In reality, however, further workflows exist which shall be displayed in the following section.

7.1 Basic-Workflow 7.1.1 Requirements

• PVS

o Selection of patient

o (optional) choosing patient

o (optional) choosing procedure

o (optional) additional text

o Creation of a request according to record type 6302

Save as file

Sending via V.24 / RS232 interface or

Writing in a file according to naming convention of the GDT

Waiting for results

• DEVICE

o Waiting for request from PVS

o Evaluates the requirement data and starts the requested procedure

o Process and evaluation time of the DEVICE


o Creation of a result and/or end signal with record type 6310



Terminating the operation

• PVS

o Reception and storage of results data

7.1.2 Illustration of results data

• PVS

o Selection of patient


Save as file



(optional) Waiting for termination of the operation on this DEVICE

• DEVICE

o Selection of the patient’s examination and/or treatment data

o Consideration of the results and/or further interactive work with the existing data

o Finishing the evaluation

7.2 Storage of patient master data Record type 6301 has been defined to allow the synchronization of databases. The aim is that all master data of the PVS (both new and changed data) can be transmitted to the DEVICE.


7.2.1 Single or direct transmission of data The DEVICE must be able and in the condition to directly receive and process master data.

• PVS

o Selection of the patient


Save as file



NO waiting on the DEVICE

• DEVICE

o Takeover of the master data into the own database

7.2.2 Batch transmission of master data In this mode, the transmission via serial interface is not possible. However, the DEVICE does not have to able to receive master data permanently, but can do this periodically.


• PVS

o Selection of the patient


Save as file


NO waiting on the DEVICE

• DEVICE

o Takeover of the master data into the own database

7.3 Simple form of a GDT request In reality, it has turned out that for many executions only a simple data transmission has been realized. This simple form was mostly the result of the necessity to actively control the DEVICE with the PVS. The advantage of this method is its flexibility. Various DEVICES can be installed which can be controlled by the operator him/herself.


• PVS

o Creation of a request according to record type 6301 (at most times, a file is stored at the selection of a patient)

• DEVICE

o The DEVICE is selected by the operator and the working mod of the device is started

o Working with the DEVICE

o (optional) creating of a result in form of record type 6310

• PVS

o When the work with one patient is finished (e.g. exiting the medical documentation/file card, the existence of a record type 6310 is checked and added to the patient data, if existent.

7.3.1 Result Same process as in 7.3.


7.4 Asynchronous communication Modern PVSs have the possibility to process and transmit GDT requests without having to wait for the results. Arriving result data is automatically accepted and processed by background utility programs which work in batch modes.

• Request new examination (record type 6302)

o FK 8402 device and process specific characteristic map. This information is given per medical device

o FK 8404 subcategory to FK 8402 (e.g. choice of an organ)

o FK 8408 allocation of a Study-UID, so that several result files can be created for one examination (.e.g. creation of more than one image; record type 6310 exists multiple times)

o FK 8409 allocation of an identifier (text) for one examination procedure

o FK 8410 test identifier: Multiple test identifiers can be allocated in a series of tests

o FK 8411 labeling of the tests

o FK 8491 Referring physician (e.g. Dr. med. Doe/123456499)

• Transmission of examination data (record type 6310)

o All fields from the previously created record type 6302 and optionally

o FK 6325 labeling of the (partial) task (e.g. reference to a picture: later hand, hand AP axial)

o FK 8412 file name of a result file (e.g. thumbnail-image)


7.5 Asynchronous communication in equipment sharing As part of the construction and rationalization of equipment sharing, medical health care centers and laboratory joint practices, medical devices are used by multiple medical offices. Most of the time, the devices have their own rooms.


7.5.1 Process


Multiple PVSs send an exanimation or treatment request to a central DEVICE. The DEVICE has a work list with pending processes. After the DEVICE has finished the processes, the medical offices need to be able to access the data again. 7.5.2 Extensions of the GDT

• Necessity to generate globally individual labels for requested operations of a medical device as well as mapping the results.

7.5.3 Necessity of a definition for transmission paths As long as the data is only shared in an office’s own LAN (network), the data transmission can be freely defined via various transmission paths. As soon as the data leaves the office network, however, medical data protection (e.g. encryption) and other norms have to be considered to avoid an unnecessary complication of communication in heterogeneous networks.

gdt 3.0 device data volume - qms- · pdf fileintegration of medical instruments gdt 3.0 device...

Documents