Qualitätsring Medizinischer Software

Transcription

Integration of medical instruments
GDT 3.0
Device data
volume
Interface description for systemindependent 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 order“
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 meeting 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
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 association’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)
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
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
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
Seite 6 von 57
Date:
10/01/2013
1 Introduction
1.1 General remarks
The present interface description was developed by the QMS (Qualitätsring Medizinische Software 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 neutral 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 accordance with this description is not technically feasible (e.g. older standalone devices with vendorspecific 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), standaloneunit or PC-based measuring device.
PVS
Medical office administrative system ((Arzt-)PraxenVerwaltungsSystem).
KOMPONENTE
(COMPONENT)
Every participant of the data exchange, PVS (administrative system) or device (Gerät).
SERVER
COMPONENT which waits for external requests and commands to be processed. (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 behavior, 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).
Seite 7 von 57
Date:
10/01/2013
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, UNIXPipes).
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 corresponding 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>
<nn>
Example:
=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
GDT-S-10 /
PVS can only work as a serial SERVER,
Seite 8 von 57
Date:
10/01/2013
GDT-D-11
1.4.4
Labeling for DEVICE
GDT-<xx>-<nn>
<xx>
<nn>
Example:
1.4.5
can work via file as SERVER and CLIENT
=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
GDT-D-10
can work via file as SERVER and CLIENT
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 devicespecifically. 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 recorders 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.
Seite 9 von 57
Date:
10/01/2013
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 maximum 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 assigned 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 provided for it (e.g.: PVS1EKG1.GDT).
The used file type (fixed or incrementing) is to be defined for every DEVICE at the time of installation.
The files are produced by the respective sender, whereas the extension is incremented accordingly. 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 finished, 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.
Seite 10 von 57
Date: 10/01/2013
2.4 Communication via serial interface
2.4.1
Hardware
The communication happens via three-wire serial cable (RxD, TxD, GND) as minimum requirement, 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)
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)
DTR
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 (although this does not happen very often). Please contact the respective producer of the device to
clarify the correct polarity.
Seite 11 von 57
Date: 10/01/2013
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 (XONXOFF) 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 Annex 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 examination 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 corresponding 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 management
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
Seite 12 von 57
Date: 10/01/2013
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

Seite 13 von 57
Date: 10/01/2013
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
Seite 14 von 57
Date: 10/01/2013
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↓↵
0288200Obj_Basisdiagnostik↓↵
; Start identifier object “Obj_Basisdiagnostik”
(Obj_basic_diagnostics)
0153622178.00↓↵
; Height
0153623079.00↓↵
; Weight
01082014↓↵
011820219↓↵
; End of record (Record contains 19 fields)
↓↵
=
CR / LF
Each line has to be closed with CR / LF (0D 0A hex)!
Seite 15 von 57
Date: 10/01/2013
2.6.3
Example file “Transmission of examination data” (Daten einer Untersuchung übermitteln) (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
0153622178.00↵↓
; Height
0153632079.00↵↓
; Weight
0148402BDM01↵↓
; Examination: 24h blood pressure
017620023101998↵↓
; Date of the examination
0346220Dies∨ist∨ein∨zweizeiliger↵↓
; Findings 1 line (0346220This
st
is a two line …)
0416220Befund∨zur∨24h-Blutdruckmessung.↵↓
; Findings 2
nd
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 (Conclusion of the results)
0596228--------------------------------------------------↵↓
Seite 16 von 57
Date: 10/01/2013
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 (Manufacturer 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
CR and LF
(20 hex) resp. (32 decimal)
(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
Seite 17 von 57
Date: 10/01/2013
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 „GDTObjektkatalog“ (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 specification “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 appearance 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
identifier
Occurrence
Label
Existence
1
of the field contents
must/ca Condition
n (M/C)
2
3
4
Annotations
…
8401
1
Field 8401 can only occur one time
per record
n
Field 8410 can occur any number of
times
…
8410
8411
1
Field 8411 can only occur one time
per field 8410
n
Field 8460 can occur any number of
times per 8410.
…
8460
Seite 18 von 57
Date: 10/01/2013
3.1 Definition of record types: Request master data (Stammdaten
anfordern) „6300“
SA 6300 Field
identifier
Änd.
Header
data
Patient
Healthinsurance
card
Occurrence
Label
Existence
1
M/C Condition
Record identification
Length of record
Obj_Kopfdaten
(Obj_header_data)
Obj_Patient
Obj_Versichertenkarte
(Obj_health-insurance_card)
M
C
M
Record type: Request master data
Length of record
See Annex D
M
C
See Annex D
See Annex D
End of record
M
Contains the number of transmitted
fields including FK 8000 and FK 8202
8000
8100
xxxx
1
1
1
xxxx
xxxx
1
1
8202
1
2
3
4
Annotations
3.2 Definition of record types: Transmission of master data
(Stammdaten übermitteln) „6301“
SA 6301 Field
identifier
Änd.
Header
data
Patient
basic
diagn.
Healthinsurance
card
Occurrence
Label
Existence
1
M/C Condition
2
3
4
Annotations
8000
1
M
8100
xxxx
1
1
C
M
xxxx
xxxx
1
1
M
C
See Annex D
See Annex D
xxxx
1
Length of record
Obj_Kopfdaten
(Obj_header_data)
Obj_Patient
Obj_Basisdiagnostik
Record type: Transmission of master
data
Length of record
See Annex D
C
See Annex D
8202
1
End of record
M
3.3 Definition of record types: Request new examination (Neue Untersuchung anfordern) „6302“
SA 6302 Field
identifier
Änd.
Occurrence
Label
Existence
1
M/C Condition
Length of record
Obj_Kopfdaten
(Obj_header_data)
Obj_Patient
Obj_Anforderung (Obj_request)
Obj_Basisdiagnostik
Obj_Dauermedikament
(Obj_permanent_medication)
M
C
M
Record type: request new examination
Length of record
See Annex D
M
M
C
See Annex D
See Annex D
See Annex D
C
See Annex D
C
See Annex D
8000
8100
xxxx
1
1
1
xxxx
xxxx
xxxx
1
1
1
Permanent
medication
xxxx
1
Request
xxxx
1
Header
data
Patient
Request
basic
diagn.
2
3
4
Seite 19 von 57
Annotations
Date: 10/01/2013
SA 6302 Field
identifier
Änd.
Occurrence
M/C Condition
Permanent
diagnosis
xxxx
1
Obj_Dauerdiagnosis
(Obj_permanent_diagnosis)
C
See Annex D
Healthinsurance
card
xxxx
1
C
See Annex D
Referral
xxxx
xxxx
xxxx
xxxx
xxxx
1
1
1
1
1
Obj_Überweisung (Obj_referral)
Obj_Diagnosis
Obj_Anhang (Obj_Annex)
Obj_Empfänger (Obj_receiver)
Obj_Arztidentifikation
(Obj_physician_identification)
C
C
C
C
C
See Annex D
See Annex D
See Annex D
See Annex D
See Annex D
8202
1
End of record
M
Diagnosis
Annex
Receiver
Physician
identification
1
2
3
4
Label
Existence
Annotations
3.4 Definition of record types: Cancel requested examination
(Angeforderte Untersuchung stornieren) „6303“
SA 6303 Field
identifier
Änd.
Occurrence
Label
Existence
1
M/C Condition
2
3
4
Annotations
8000
1
M
8100
xxxx
1
1
C
M
xxxx
xxxx
xxxx
1
1
1
M
M
C
See Annex D
See Annex D
See Annex D
xxxx
xxxx
1
1
Length of record
Obj_Kopfdaten
(Obj_header_data)
Obj_Patient
Obj_Basisdiagnostik
Obj_Dauermedikament
Record type: cancel requested examination
Length of record
See Annex D
C
C
See Annex D
See Annex D
Permanent
diagnosis
xxxx
1
Obj_Dauerdiagnosis
C
See Annex D
Healthinsurance
card
xxxx
1
C
See Annex D
Referral
xxxx
xxxx
xxxx
xxxx
xxxx
1
1
1
1
1
Obj_Überweisung (Obj_referral)
Obj_Diagnosis
Obj_Empfänger (Obj_ receiver)
C
C
C
C
C
See Annex D
See Annex D
See Annex D
See Annex D
See Annex D
8202
1
End of record
M
Header
data
Patient
Request
basic
diagn.
Request
Permanent
medication
Diagnosis
Annex
Receiver
Physician
identification
Seite 20 von 57
Date: 10/01/2013
3.5 Definition of record types: Transmission of examination data
(Daten einer Untersuchung übermitteln) „6310“
SA 6310 Field
identifier
Änd.
Header
data
Patient
Request
basic
diagn.
Request
Healthinsurance
card
Occurrence
Label
Existence
1
2
M/C Condition
8000
1
M
8100
xxxx
1
1
C
M
xxxx
xxxx
xxxx
1
1
1
M
M
C
See Annex D
See Annex D
See Annex D
xxxx
xxxx
1
1
Length of record
Obj_Kopfdaten
(Obj_header_data)
Obj_Patient
Obj_Basisdiagnostik
Record type: Transmission of examination data
Length of record
See Annex D
M
C
See Annex D
See Annex D
6200
6205
6206
6210
1
C
C
C
M
MMDDYYYY of examination
1
Day of storage for treatment data
Current Diagnosis
Central pharmaceutical number
Medication prescribed
1
Medication without prescription
M
Number of packages (factor)
Information about intake
Free of charge
Nocturnal
BVG
Accident
Me-too prescription
Findings
External findings
C
C
C
C
C
C
C
C
C
n
1
6211
6214
6218
6406
6407
6408
6409
6431
6220
6221
1
1
1
1
1
1
1
N
N
6227
6226
N
N
6228
Annex
xxxx
6330,
6332,
6334,
…
6398
6331,
6333,
6335,
…
6399
8405
3
If 6206
exists
If 6206
exists
0=no, 1=yes
0= no, 1=yes
0= no, 1=yes
0= no, 1=yes
0= no, 1=yes
e.g. findings notice generated by the
device
Commentary
C
Number of following lines after the C
identifier
n
1
n
1
1
4
Annotations
Result text, formatted
m
Name of the free category
C
C
Content of the free category
M
Patient information
C
If 6226
exists
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.
Random result text, formatted by the
device
See Annex D
Even and
following
odd field
identifiers
belong
together.
If previous
field identifier “Name
of the free
category”
exists.
Seite 21 von 57
Date: 10/01/2013
SA 6310 Field
identifier
Änd.
Occurrence
M/C Condition
Physician
identification
xxxx
1
C
See Annex D
8202
1
End of record
M
1
2
3
4
Label
Existence
Annotations
3.6 Definition of record types: Display data of an examination
(Daten einer Untersuchung zeigen) „6311“
SA 6311 Field
identifier
Änd.
Header
data
Patient
Request
Physician
identification
Occurrence
Label
Existence
1
2
3
4
Annotations
M/C Condition
8000
1
M
8100
xxxx
1
1
C
M
xxxx
xxxx
4111
xxxx
1
1
1
1
Length of record
Obj_Kopfdaten
(Obj_header_data)
Obj_Patient
Health insurance number
M
M
C
C
See Annex D
See Annex D
8202
1
End of record
M
Seite 22 von 57
Record type: display data of an examination
Length of record
See Annex D
See Annex D
Date: 10/01/2013
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
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 number
9
num
947812345
0202
Name of the payer
var
alnum
German Federal Pension
Fund
0212
LANR (lifetime physician number)
9
num
123456789
0950
for permanent medication
var
alnum
4877800
0957
Administration form for permanent 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
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 (Germany)
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
Seite 23 von 57
Rule
020/304
Example
04121946
Date: 10/01/2013
Field
identifier
Label
Length
Type
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 (electronic 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
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 Analgesia (PCA)
3672
Follow-up appointment
8
date
01121993
3673
Permanent diagnosis ICD-Code
3,5,6
alnum
E10.21
3674
Diagnostic confidence for permanent diagnosis
1
alnum
Z
3675
Body side localization for permanent diagnosis
1
alnum
R
3676
Diagnosis explanation for permanent diagnosis
var
alnum
ECG definite
3677
Diagnosis derogation for permanent diagnosis
var
alnum
true
Seite 24 von 57
Rule
Example
Date: 10/01/2013
Field
identifier
Label
Length
Type
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 insurance
5
num
27106
4106
Payer billing area
2
num
00
4109
Day of last reading of the healhinsurance 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
4205
Assignment
var
alnum
4207
(Suspected) Diagnosis
var
alnum
4208
Findings / Medication
var
alnum
4209
Assignment/diagnosis/suspicion
var
alnum
X-ray left hand
4217
(N)BSNR: Establishment number 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 number) of the initiator
9
num
123456789
Seite 25 von 57
Rule
Example
1
Suspected hepatitis
Date: 10/01/2013
Field
identifier
Label
Length
Type
4242
LANR (lifetime physician number) 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 diagnosis derogation
var
alnum
Condition after gender
reassignment
6200
Day of storage of treatment data
(MMDDYYYY)
8
date
6201
Time of treatment data elicitation
6
time
110435
6205
Current diagnosis
var
alnum
Diabetes test
6206
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 BASE64coded attachment
var
alnum
*N2.1
63306398
Name of the free category
var
alnum
PATINFO
*N2.1
63316399
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
Seite 26 von 57
Rule
008
Example
12261993
Date: 10/01/2013
Field
identifier
Label
Length
Type
6431
Aut Idem
1
num
0=no, 1=yes
8000
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
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
Rule
Example
Left kidney
Seite 27 von 57
008
01311994
Date: 10/01/2013
Field
identifier
Label
Length
Type
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
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 recipient
var
alnum
Dr. Jane
8606
City of residence of the invoice
recipient
var
alnum
50226 Cologne
8607
Street of residence of the invoice 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
Seite 28 von 57
Rule
090
Example
125600
Date: 10/01/2013
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 missing 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 transmission 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>
Seite 29 von 57
Date: 10/01/2013
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 transmission block has to be resent because of a faulty transmission, the send sequence number remains 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 object names)
Seite 30 von 57
Date: 10/01/2013
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 transfer the file, the transmission is aborted. The error handling takes place on a higher level.
Seite 31 von 57
Date: 10/01/2013
6.1.4.3
Examples for transmissions including errors
Repetition of a transmission block
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
correctly
this time the data block is received
Synchronization after transmission errors
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 occurred a second time
New synchronization with send sequence 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
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
Seite 32 von 57
Date: 10/01/2013
New synchronization with send sequence 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:
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
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)
Client repeats attempt of synchronization
Seite 33 von 57
Date: 10/01/2013
S: 0B00 01380006301|0158100000217|<CRC> <CR>
Repeated transmission by the server with new synchronization
S: 0B00 01380006301|01681000000217|<CRC> <CR>
Server repeats attempt of synchronization
The transmission is aborted by server and client after the timeout (“wait for ACK”)
(see 6.1.4.2).
Seite 34 von 57
Date: 10/01/2013
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 characters 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 (generally ALLG00) is appointed for non-classified examinations.
The list of field contents is dynamic and is centrally administered by the ZI (CI). The subsequently listed groups and field identifiers are therefore only a first draft which is optionally extendable.
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__
ALLG00
Examinations, general
Non-classified examinations
APNO__
Sleep apnea examinations
APNO00
Apnea, general
APNO01
Long-term sleep apnea screening
APNO02
Polysomnography
AUDI__
Audiometric examinations
Seite 35 von 57
Date: 10/01/2013
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
Cardiotocography
CTG__
CTG01
Cardiotocography
DERM__
DERM01
Dermatology
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
Seite 36 von 57
Date: 10/01/2013
FILE__
FILE01
File transfer
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
Seite 37 von 57
Date: 10/01/2013
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__
NULL01
Empty Device
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
Seite 38 von 57
Date: 10/01/2013
SCAN__
SCAN01
Scanner
Scanner, general with TWAIN standard
SONO__
Sonography measurements
SONO00
Sonography, general
SONO01
Ultrasound doppler
URO__
Urology
URO00
Urology, general
URO01
Uroflowmetry
VDDS__
VDDS01
VDDS dental interface
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__
XRAY01
X-ray image
X-ray image
Seite 39 von 57
Date: 10/01/2013
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.
Height
[cm]
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)
Seite 40 von 57
Date: 10/01/2013
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 program? Until now, the GDT did not offer a direct possibility for such a scenario.
Sample 1
Measurement
values
Sample 2
Time
Seite 41 von 57
Date: 10/01/2013
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
3000
Patient data
1
Device
1
Description
1
2
3
4
…
8402
…
6205-6228
…
8405
Sample
n
…
8406
Date
1
8407
Time
1
8410
Test-Ident
n
Bitstream
n
…
8417
Seite 42 von 57
Date: 10/01/2013
…
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_Kopfdaten
(Obj_header_data)
Obj_Ueberweisung
(Obj_referral)
Obj_Basisdiagnostikdia
(Obj_basic_diagnostics
Obj_Patient
Obj_Dauerdiagnosis
Obj_RgEmpfänger
(Obj_invoice_recipient)
Obj_Dauermedikament
Obj_Satzende
(Obj_end_of_record)
Seite 43 von 57
Date: 10/01/2013
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 process 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 patient 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)
Commentary
2. Obj_Patient
3. Obj_ArztIdent (Obj_physician_identification)
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.
Process: PVS to DEVICE. Example with physician
identification
6.5.3
Request new examination “6302” (PVS to DEVICE)
Example 1:
Commentary
Minimal version. The request of an examination, including the physician identification and the request identification.
2. Obj_Patient
3. Obj_Anforderung (Obj_request)
Seite 44 von 57
Date: 10/01/2013
Process: PVS to DEVICE. In this case with physician
identification
Example 2:
Commentary
Request of an examination including
data of the health insurance card as well
as detailed permanent medical information and the basic diagnosis.
2. Obj_Patient
4. Obj_Versichertenkarte (Obj_healthinsurance_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 musthave objects Obj_Kopfdaten (Obj_header_data)
and Obj_Patient, the objects
Obj_Versichertenkarte (Obj_health-insurance
card), Obj_Basisdiagnostik (Obj_basic diagnostics), Obj_DauerMed
(Obj_permanent_medication), and Obj_DauerDiag
(Obj_permanent_diagnosis) are transmitted. The
medical device is initialized with the permanent medical data, the basic diagnosis and the insurance data.
6.5.4
Transmission of examination data “6310” (DEVICE to PVS)
2. Obj_Patient
3. Obj_Untersuchung (Obj_exam)
4. Obj_Anhang (Obj_annex)
Process: DEVICE to PVS
Seite 45 von 57
Date: 10/01/2013
6.5.5
Display data of an examination “6311” (PVS to DEVICE)
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)
Commentary
2. Obj_Patient
4. Obj_Terminanfrage
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 request of referral to a specialist, are especially important for the ongoing workflow.
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)
2. Obj_Patient
Kommentar
With the process referral to specialist,
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 find-
Seite 46 von 57
Date: 10/01/2013
ings. The object Obj_Anhang
(Obj_annex) can be used to display the
declaration of content or previous findings of other physicians.
7. Obj_Einweisung (Obj_admission)
object Obj_Patient
6.5.8
Hospitalization “6302” (PVS to DEVICE)
Commentary
2. Obj_Patient
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.
7. Obj_Einweisung (Obj_admission)
Seite 47 von 57
Date: 10/01/2013
object Obj_Patient
6.5.9
Transmission of emergency data “6302” (PVS to DEVICE)
Commentary
In the area of emergency cases, the
provision of permanent medical information and basic diagnostics is crucial.
Additionally, the required emergency
data set can be initialized with this record type.
2. Obj_Patient
7. ArztIdent (Obj_physician_identification)
Process: PVS to DEVICE
Seite 48 von 57
Date: 10/01/2013
7 Illustration of the workflows
The GDT interface was created for the communication of the PVS with all kinds of medical devices (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 workflow.
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
Seite 49 von 57
Date: 10/01/2013
o
•
7.1.2
•



Terminating the operation
PVS
o
•
Creation of a result and/or end signal with record type 6310
Reception and storage of results data
Illustration of results data
PVS
o
Selection of patient
o

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.
Seite 50 von 57
Date: 10/01/2013
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
o

Save as file



NO waiting on the DEVICE
DEVICE
o
7.2.2
Takeover of the master data into the own database
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.
Seite 51 von 57
Date: 10/01/2013
•
•
PVS
o
Selection of the patient
o

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.
Seite 52 von 57
Date: 10/01/2013
•
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
7.3.1
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.
Result
Same process as in 7.3.
Seite 53 von 57
Date: 10/01/2013
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)
Seite 54 von 57
Date: 10/01/2013
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.
Seite 55 von 57
Date: 10/01/2013
7.5.1
Process
Seite 56 von 57
Date: 10/01/2013
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.
Seite 57 von 57
Date: 10/01/2013

Qualitätsring Medizinischer Software

Transcription

Similar documents

zeanischer Blues

boso profil-manager XD Home

DMP-Qualitätssicherungsbericht 2010

Kleinwuchs bei Kindern - FERRING Arzneimittel GmbH