GDT 3.0 Device data volume - Interface description for system-independent data transfer between medical information systems and medical ...
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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
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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 2 von 57 Date: 10/01/2013
Version Date Updated by Update reason / description 3.0 01/31/2013 Ralf Franke Final version pre-release 3.0 07/01/2013 Ralf Franke Editorial changes: Revision of example files, Release 1 graphics, typing errors 3.0 10/01/2013 Ralf Franke Final version for publication on the homepage of Release 1 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) GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 3 von 57 Date: 10/01/2013
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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 4 von 57 Date: 10/01/2013
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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 5 von 57 Date: 10/01/2013
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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 6 von 57 Date: 10/01/20131 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 Medical technology device (or corresponding driver program), standalone-
(DEVICE) unit or PC-based measuring device.
PVS Medical office administrative system ((Arzt-)PraxenVerwaltungsSystem).
KOMPONENTE Every participant of the data exchange, PVS (administrative system) or de-
(COMPONENT) 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).
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 7 von 57 Date: 10/01/20131.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-- =S Serial data transmission according to GDT is supported
=D Data transmission via files according to GDT is supported
= SD Both methods are supported
= 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- Gerätedatenträger, Version:3.0, Release 1.0 Seite 8 von 57 Date: 10/01/2013GDT-D-11 can work via file as SERVER and CLIENT
1.4.4 Labeling for DEVICE
GDT-- =S Serial data transmission according to GDT is supported
=D Data transmission via files according to GDT is supported
= SD Both methods are supported
= 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.
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 9 von 57 Date: 10/01/20132.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 sender>. (e.g.: PVS2GER.005)
or
< token of receiver>< token of sender>.GDT (e.g.: PVS2GER.GDT)
or
< token of receiver>< token of sender>_.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.
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 10 von 57 Date: 10/01/20132.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.
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 11 von 57 Date: 10/01/20132.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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 12 von 57 Date: 10/01/20132. 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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 13 von 57 Date: 10/01/2013Spirometry 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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 14 von 57 Date: 10/01/20132.6 Annotated example files
2.6.1 Structure of a GDT line:
0163101Schmidt
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)!
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 15 von 57 Date: 10/01/20132.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)
0082017↵↓ ; End of object
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
st
0346220Dies∨ist∨ein∨zweizeiliger↵↓ ; Findings 1 line (0346220This
is a two line …)
nd
0416220Befund∨zur∨24h-Blutdruckmessung.↵↓ ; Findings 2 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--------------------------------------------------↵↓
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 16 von 57 Date: 10/01/20130596228∨∨∨∨∨∨∨∨∨∨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
011820129↵↓ ; End of object
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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 17 von 57 Date: 10/01/20136302: 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 Occurrence Label Existence Annotations
iden-
tifier
1 2 3 4 of the field contents must/ca Condition
n (M/C)
…
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.
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 18 von 57 Date: 10/01/20133.1 Definition of record types: Request master data (Stammdaten
anfordern) „6300“
SA 6300 Field Occurrence Label Existence Annotations
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 xxxx 1 Obj_Kopfdaten M See Annex D
data (Obj_header_data)
Patient xxxx 1 Obj_Patient M See Annex D
Health- xxxx 1 Obj_Versichertenkarte C See Annex D
insurance (Obj_health-insurance_card)
card
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“
SA 6301 Field Occurrence Label Existence Annotations
iden-
tifier
Ä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 xxxx 1 Obj_Kopfdaten M See Annex D
data (Obj_header_data)
Patient xxxx 1 Obj_Patient M See Annex D
basic xxxx 1 Obj_Basisdiagnostik C See Annex D
diagn. (Obj_basic_diagnostics)
Health- xxxx 1 Obj_Versichertenkarte C See Annex D
insurance (Obj_health-insurance_card)
card
8202 1 End of record M Contains the number of transmitted
fields including FK 8000 and FK 8202
3.3 Definition of record types: Request new examination (Neue Un-
tersuchung anfordern) „6302“
SA 6302 Field Occurrence Label Existence Annotations
iden-
tifier
Ä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 xxxx 1 Obj_Kopfdaten M See Annex D
data (Obj_header_data)
Patient xxxx 1 Obj_Patient M See Annex D
Request xxxx 1 Obj_Anforderung (Obj_request) M See Annex D
basic xxxx 1 Obj_Basisdiagnostik C See Annex D
diagn. (Obj_basic_diagnostics)
Perma- xxxx 1 Obj_Dauermedikament C See Annex D
nent (Obj_permanent_medication)
medica-
tion
Request xxxx 1 Obj_Anforderung (Obj_request) C See Annex D
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 19 von 57 Date: 10/01/2013SA 6302 Field Occurrence Label Existence Annotations
iden-
tifier
Änd. 1 2 3 4 of the field contents M/C Condition
Perma- xxxx 1 Obj_Dauerdiagnosis C See Annex D
nent (Obj_permanent_diagnosis)
diagnosis
Health- xxxx 1 Obj_Versichertenkarte C See Annex D
insurance (Obj_health-insurance_card)
card
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 xxxx 1 Obj_Arztidentifikation C See Annex D
identifica- (Obj_physician_identification)
tion
8202 1 End of record M Contains the number of transmitted
fields including FK 8000 and FK 8202
3.4 Definition of record types: Cancel requested examination
(Angeforderte Untersuchung stornieren) „6303“
SA 6303 Field Occurrence Label Existence Annotations
iden-
tifier
Ä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 xxxx 1 Obj_Kopfdaten M See Annex D
data (Obj_header_data)
Patient xxxx 1 Obj_Patient M See Annex D
Request xxxx 1 Obj_Anforderung (Obj_request) M See Annex D
basic xxxx 1 Obj_Basisdiagnostik C See Annex D
diagn. (Obj_basic_diagnostics)
Request xxxx 1 Obj_Anforderung (Obj_request) C See Annex D
Perma- xxxx 1 Obj_Dauermedikament C See Annex D
nent (Obj_permanent_medication)
medica-
tion
Perma- xxxx 1 Obj_Dauerdiagnosis C See Annex D
nent (Obj_permanent_diagnosis)
diagnosis
Health- xxxx 1 Obj_Versichertenkarte C See Annex D
insurance (Obj_health-insurance_card)
card
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 xxxx 1 Obj_Arztidentifikation C See Annex D
identifica- (Obj_physician_identification)
tion
8202 1 End of record M Contains the number of transmitted
fields including FK 8000 and FK 8202
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 20 von 57 Date: 10/01/20133.5 Definition of record types: Transmission of examination data
(Daten einer Untersuchung übermitteln) „6310“
SA 6310 Field Occurrence Label Existence Annotations
iden-
tifier
Ä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 xxxx 1 Obj_Kopfdaten M See Annex D
data (Obj_header_data)
Patient xxxx 1 Obj_Patient M See Annex D
Request xxxx 1 Obj_Anforderung (Obj_request) M See Annex D
basic xxxx 1 Obj_Basisdiagnostik C See Annex D
diagn. (Obj_basic_diagnostics)
Request xxxx 1 Obj_Anforderung (Obj_request) M See Annex D
Health- xxxx 1 Obj_Versichertenkarte C See Annex D
insurance (Obj_health-insurance_card)
card
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 C With this, the GDT length restriction in
identifier 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 Random result text, formatted by the
exists device
Annex xxxx 1 Obj_Anhang (Obj_Annex) C See Annex D
6330, n Name of the free category C Even and
6332, following
odd field
6334, identifiers
… belong
6398 together.
6331, 1 Content of the free category M If previous
6333, field identi-
fier “Name
6335, of the free
… category”
6399 exists.
8405 1 Patient information C
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 21 von 57 Date: 10/01/2013SA 6310 Field Occurrence Label Existence Annotations
iden-
tifier
Änd. 1 2 3 4 of the field contents M/C Condition
Physician xxxx 1 Obj_Arztidentifikation C See Annex D
identifica- (Obj_physician_identification)
tion
8202 1 End of record M Contains the number of transmitted
fields including FK 8000 and FK 8202
3.6 Definition of record types: Display data of an examination
(Daten einer Untersuchung zeigen) „6311“
SA 6311 Field Occurrence Label Existence Annotations
iden-
tifier
Ä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 xxxx 1 Obj_Kopfdaten M See Annex D
data (Obj_header_data)
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 xxxx 1 Obj_Arztidentifikation C See Annex D
identifica- (Obj_physician_identification)
tion
8202 1 End of record M Contains the number of transmitted
fields including FK 8000 and FK 8202
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 22 von 57 Date: 10/01/20134 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 Label Length Type Rule Example
identifier
0102 Person/company responsible var (alphanumeric)lnum e.g. company
for software
0103 Software var alnum Name of the software
0132 Release stage of software var alnum 12.4
0201 (N)BSNR: Establishment num- 9 num 947812345
ber
0202 Name of the payer var alnum German Federal Pension
Fund
0212 LANR (lifetime physician num- 9 num 123456789
ber)
0950 Central pharmaceutical number var alnum 4877800
for permanent medication
0957 Administration form for perma- var alnum Caplet
nent medication
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 var alnum 123456M789
patient
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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 23 von 57 Date: 10/01/2013Field Label Length Type Rule Example
identifier
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- 10 alnum A123456780
tronic health card in Germany)
of the patient
3618 Cellphone number of the patient var alnum 0049-172 9335 172
3619 Email address of the patient var alnum j.doe@dummy.com
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- 1 alnum Z
manent diagnosis
3675 Body side localization for per- 1 alnum R
manent diagnosis
3676 Diagnosis explanation for per- var alnum ECG definite
manent diagnosis
3677 Diagnosis derogation for per- var alnum true
manent diagnosis
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 24 von 57 Date: 10/01/2013Field Label Length Type Rule Example
identifier
3700 Label of the basic-diagnostic var alnum Cardiovascular family
category history
3701 Content of the basic-diagnostic var alnum Yes
category
4104 No. of contracted health insur- 5 num 27106
ance
4106 Payer billing area 2 num 00
4109 Day of last reading of the healh- 8 date 07082012
insurance card in the quarter
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 1 num 1
accident
4203 Treatment according to . § 116b 1 num
SGB V
4204 Restricted entitlement according 1 num 1
to § 18 Abs. 3a SGB V
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- 9 num 123456700
ber of the initiator
4218 (N)BSNR Establishment number 9 num 234567800
of the referring person
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 1 num
infection
4237 Hospital name var alnum XYZ General Hospital
4241 LANR (lifetime physician num- 9 num 123456789
ber) of the initiator
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 25 von 57 Date: 10/01/2013Field Label Length Type Rule Example
identifier
4242 LANR (lifetime physician num- 9 num 234567890
ber) of the referring person
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- var alnum Condition after gender
sis derogation reassignment
6200 Day of storage of treatment data 8 date 008 12261993
(MMDDYYYY)
6201 Time of treatment data elicita- 6 time 110435
tion
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 var num 2
the identifier 6228
*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- var alnum
coded attachment
*N2.1 6330- Name of the free category var alnum PATINFO
6398
*N2.1 6331- Content of the free category var alnum Patient is cheerful
6399
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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 26 von 57 Date: 10/01/2013Field Label Length Type Rule Example
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 var alnum ECG01, see Annex B
characteristic map
8403 Schedule of fees 1 num 1
8404 Subcategory to field identifier Left kidney
8402
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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 27 von 57 Date: 10/01/2013Field Label Length Type Rule Example
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 var alnum
of sample collection
8510 Pregnancy 1 num 1 (0=nein, 1=ja)
8511 Gestation length (in weeks, 3 num 24,2
days)
8512 1st day of cycle (MMDDYYYY) 8 date 09102012
8601 Name of invoice recipient var alnum Doe
8602 Title, Forename of invoice recip- var alnum Dr. Jane
ient
8606 City of residence of the invoice var alnum 50226 Cologne
recipient
8607 Street of residence of the in- var alnum Main Street 1
voice recipient
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
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 28 von 57 Date: 10/01/2013date = 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 Category Check Description
rule.
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 Avoid key errors
gleich Maschinendatum
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:
[]
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 29 von 57 Date: 10/01/20136.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)
GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 30 von 57 Date: 10/01/2013Client sends: C: 1B00 01380006300|01681000000119|0228200Obj_Kopfdaten|0178315QMS- S: 1 C: 2B02 GDT1|0178316ROP200U1|014921803.00|01082015|01082028 S: 1 Server responds: S: 7B00 01380006301|01681000000217|0228200Obj_Kopfdaten|0178315ROP C: 1 S: 8B01 200U1|0178316QMS-GDT1|014921803.00|01082015|0208200Obj_Pat C: 1 S: 9B01 ient|014300010027|0123101Axt|0143102Berta|017310301041965 C: 1 S: 1B02 |01031102|01082017|011820215 C: 1 6.1.4.2 Procedure when transmission errors occur Upon receipt of 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. GDT- Gerätedatenträger, Version:3.0, Release 1.0 Seite 31 von 57 Date: 10/01/2013
You can also read
