GDT plugin

The GDT (Geräte-Daten-Träger) plugin provides a standardized interface for data exchange between the Vienna Test System (VTS) and external systems. It is available as plugin of the VTS Integration Service. It facilitates communication by exchanging .GDT files through a predefined directory, enabling seamless integration based on the GDT format standard. This plugin is ideal for environments that interact with other medical or diagnostic systems, as it ensures reliable and well-structured data transfer.

The GDT plugin implements the following so called “set types”, as defined in the GDT standard, version 2.1 (see https://www.qms-standards.de/standards/gdt-schnittstelle/):

6302 – New Test Request for importing new persons into VTS
6310 – Test Data Transfer for export of test result data out of VTS

Please note that only certain fields from these data sets are supported. For a detailed list of the implemented fields, refer to the sections about the input and output files below.

Overview of functionality

The GDT plugin periodically checks the input folder for new files that contains persons for import. When a new file is detected, the plugin automatically imports the persons into VTS. After a person completes a testing and VTS generates a PDF with the test results, the GDT plugin processes this PDF and generates a corresponding GDT file with customizable test result variables. This GDT result file is saved in the output folder, where your external system can process it further. The following diagram outlines the flow of data and the relevant folders:

The PDF version of the test results is also saved in the PDF output folder, making it available for external processing if needed.

Note: Data exchange between VTS and GDT plugin happens over an internal file system folder. This folder should not be accessed or modified by your external system to avoid interfering with the internal workflow.

Setup and configuration

In order for the GDT interface to function, the GDT plugin must be configured in the settings file of the VIS and the VTS must be configured to automatically export test results after every completed testing. Here is a short step by step guide on how to configure a minimal working GDT setup. For advanced options please refer to the sections below.

1. Adapt the VIS settings file

The GDT plugin must be enabled and configured in the settings file (appsettings.json) of the VIS, by default located in %PROGRAMFILES%\SCHUHFRIED GmbH\Vienna Test System 8\IntegrationService\appsettings.json
Note: This is the default installation path. If the Vienna Test System was installed to a different location, the actual path may vary accordingly.

This file contains the configuration of all available VIS plugins. All settings relevant to the GDT plugin can be found under the section starting with “GDTPlugin”.

CODE

"GDTPlugin": {
  //...
}

1.1. Enable the GDT plugin

In order to enable the GDT plugin, change the value of the Enabled property to true.

CODE

"Enabled": "true",

1.2. Configure your directories

The configuration file contains default values for the file paths used by the GDT plugin (GDTSourceDirectory, GDTOutputDirectory, PDFExportPath, StandardExportFolder). While the default values can be used, it is usually recommended to change them to a location of your choice:

GDTSourceDirectory, GDTOutputDirectory, PDFExportPath must also be accessible to the system that you want to connect to (e.g. your hospital information system).
StandardExportFolder is only used by VTS, its value must also be configured in VTS (detailed instructions below).

Note: Since the configuration is in a JSON file, all backslashes (“\”) must be escaped (“\\”). The use of network drives is possible, but Windows filesystem restrictions require that the logon account of the WTS Service has access to the chosen location. By default, the Local System Account is configured, which usually does not have such access.

Example

Example directory configuration in the appsettings.json file, assuming "C:\My-GDT-Exchange" is a custom folder intended for GDT file exchange.

CODE

"GDTPlugin": {
	"Enabled": "true",
    // ...
    "GDTSourceDirectory" : "C:\\My-GDT-Exchange\\VTS-Source",
    "GDTOutputDirectory" : "C:\\My-GDT-Exchange\\VTS-Output",
    // ...
    "PDFExportPath": "C:\\My-GDT-Exchange\\VTS-PDF-Export",
    "StandardExportFolder": "C:\\ProgramData\\SCHUHFRIED\\export\\_tempGDTExport",
    // ...
  },

1.3. Define export definition(s)

Although the GDT standard defines how data is exchanged, it doesn’t specify which results from VTS should be included. That’s why export definitions are needed — they determine which variables of the conducted tests, test sets, or test batteries will be exported. Only those listed in the ExportDefinitionssection will be included in the export. If a test, test set or test battery is not listed there, its results will not be sent.

Export definitions must be tailored to each specific use case; they depend on the tests used, the goals of the testing, and the connected system. By default, an example export definition is provided, but it only applies to the FEV test set. Therefore, in order to get a fully functional GDT connection, the required export definitions must be created in this step, usually together with psychological experts.

For a detailed description on how an export definition is defined, see Export definitions.

1.4. Apply changes

After saving changes to the settings file, you must restart the Windows service WTS Service to apply the updates and load the plugin with the new configuration. A description of how to restart the service can be found on the page: The VTS does not start from the troubleshooting section. If you are unsure how to restart a Windows service, you may also reboot your machine.

2. Configuration in the Vienna Test System administration software

Now that the GDT plugin is configured, the VTS must be configured accordingly, in order to enable generated test results to automatically trigger a GDT data exchange. The following settings must be configured in the Settings tab of the Vienna Test System administration software (old design in gray). Please note that those settings are currently only available in the old design of the Client, you may need to switch to it to access them. You can switch to the old design using the New design toggle button: .

2.1. Configuration of the default folder for data export

Go to Settings → Data export / import → Default folder for data export and use the folder selector to choose the directory where thr VTS will export test results to.

This folder must match the path specified in the StandardExportFolder element of the GDT plugin configuration in the settings file.

Click the Save button to apply the changes.

2.2. Configuration of the automatic test result output

Navigate to Settings → Test Results Output → Automation Options, then enable the checkbox Automatic test results output.

In the Automatic file name dropdown, select the option 3 – Personal ID and unique test ID.

Click Save to apply the changes.

2.3. Configuration of the automatic test result output for Direct testing

Required only if testing is done in Direct Testing mode.

Navigate to Settings → Direct Testing→ Scoring, then in the Automatic test results output dropdown, select the option 2 - Save the test results automatically as PDF file in the folder for data export.

In the Automatic file name dropdown, select the option 3 – Personal ID and unique test ID.

Click Save to apply the changes.

3. Test your setup

3.1. Import

Place an example GDT file into the configured GDTSourceDirectory. After a short time, it should be detected, processed and deleted by the VIS plugin. Verify that the person was created correctly.

See section Example input file for an example input file.

3.2. Export

Administer a test, test set or test battery for which an export definition is configured. After the testing is completed, a GDT output file should appear in the configured GDTOutputDirectory.

3.3. Troubleshooting

In all cases, you may check the log files for information about possible issues (see the Logging section).

Input files are not processed
- Make sure the configured directories are spelled exactly as required.
- Ensure you have a valid license for the VIS service.
- Ensure the WTS Service has been restarted and all settings are correctly applied.
Input files are processed but no persons get created (or not correctly)
- The input files could contain invalid or unsupported data.
- Make sure input files are encoded in UTF-8.
- Ensure that the Windows user running the WTS Service has sufficient rights to access the GDTSourceDirectory.
No output files are created
- Make sure the configured directories are spelled exactly as required.
- Ensure that the StandardExportFolder in the VIS settings file matches the configuration in VTS.
- Ensure there is a matching export definition for your tests.
- Ensure that the Windows user running the WTS Service has sufficient rights to access the output directories.
- Ensure the WTS Service has been restarted and all settings are correctly applied.
Unexpected GDT files are created for my finished tests / test battery
- When an export definition matches a test battery, it will overrule test definitions defined for single tests. On the other hand, if no export definition matches your test battery, export definitions for single tests apply. Make sure that the export definitions match your expectations.

Further information and reference

The following sections contain more detailed information about the various topics related to the GDT plugin and its functionality.

VIS settings file

The GDT plugin must be enabled and configured in the VIS settings file that is by default located in %PROGRAMFILES%\SCHUHFRIED GmbH\Vienna Test System 8\IntegrationService\appsettings.json
Note: This is the default installation path. If the Vienna Test System was installed to a different location, the actual path may vary accordingly.

This file contains the configuration of all available VIS plugins. All settings relevant to the GDT plugin can be found under the section starting with “GDTPlugin”.

Settings reference

Field	Description	Note
CODE `Enabled`	Defines if the plugin is enabled and should be started.	Must be set to `true`
CODE `GDTSourceDirectory`	Path to the folder from which the plugin will read the input GDT files containing personal data to import. Your system connected to VTS over the GDT interface must be configured to upload those files here.	Must be modified to match your setup. The use of network drives is possible, but Windows filesystem restrictions require that the logon account of the “WTS Service” has access to the chosen location. By default, the “Local System Account” is configured, which usually does not have such access.
CODE `GDTOutputDirectory`	Path to the folder where the plugin outputs GDT files with test results. Your system connected to VTS over the GDT interface must be configured to import from here.	Must be modified to match your setup.
CODE `StandardExportFolder`	Path to the folder where VTS outputs PDF files with results of finished tests.	Must be modified to match your setup.
CODE `PDFExportPath`	Path to the folder where GDT plugin uploads results in PDF format referenced in the exported GDT file.	Must be modified to match your setup if your receiving system must access results in pdf format in addition to GDT format.
CODE `GDTSender`	Short name of the system communicating with VIS. Used in name of the GDT file with test result data like [GDTSender][GDTReceiver].gdt . Maximal length defined by the GDT interface is 4 characters.	Modify only if needed.
CODE `GDTReceiver`	Identification of the system running VIS. Used to create name of the GDT file with test result data like [GDTSender][GDTReceiver].gdt Maximal length defined by the GDT interface is 4 characters.	Modify only if needed.
CODE `TimeoutInSec`	Defines how often will plugin check for new incoming GDT files with persons for import and how often will prepare newly finished test results for the export. The value is specified in seconds.	Modify only if needed.
CODE `PersonDefaultLanguage`	Default language used for the imported persons in case language is not provided in the GDT file with personal data to import.	Set only if person langue cannot be provided in the GDT file with personal data to import.
CODE `PersonDefaultEducationLevel`	Default education level used for the imported persons in case education level is not provided in the GDT file with personal data to import.	Set only if education level of the persons cannot be provided in the GDT file with personal data to import.
CODE `ExportRawScore`	Defines if raw scores are exported in addition to variables configured in the export definition.	Modify only if needed.
CODE `StoreProcessedFailedFiles`	Defines if system stores files exported by VTS after processing. If set to `true` system will create subfolders `Processed` and `Failed` in the `StandardExportFolder` and stores processed PDF files there instead of deleting them. Otherwise will processed files be deleted.	Modify only if needed.
CODE `ExportDefinitionGroup`	Definition of variables exported in the GDT file with test results. It is possible to create export definition for single tests as well as for a whole test battery or test battery with customized scoring. More information about the export definition can be found in the section below.	Must be modified to match used tests.

Export definitions

While the GDT standard clearly defines how data is exchanged, we still need to define which variables generated within VTS shall be exported. This is done via export definitions. To ensure export, every performed test, test set or test battery must have a corresponding export definition defined in the section ExportDefinitions. If a test or test set does not have an entry in the ExportDefinitions, its results will not be exported.

Each export definition must include a Name that matches the specific test, test set, or test battery it is intended for. It must also contain a list of Variables to be included in the export.

Each item in the Variables list should include the following fields:

TestName: The test label of the test from which the variable is exported. The test label is the commonly used short form of the test name, it is explicitly stated on the title page of the corresponding test manual.
ShortCode: A unique identifier for the variable used in the export. Available variables are described in the test manual or can easily be obtained by an example CSV export of a test result where each variable shows up as a column.
DisplayName: Optional. A descriptive label for the variable that will appear in the exported data (can be freely chosen). If not provided, description of the variable as defined by SCHUHFRIED is used.

Multiple export definitions can be provided, but each test, test set, or test battery may have only one export definition.

If a test battery is performed and it does not have its own export definition, the system will attempt to export each individual test within the battery based on their own export definitions. This means that even without a battery-level configuration, results for tests inside the battery can still be exported, provided those individual tests are configured correctly in the ExportDefinitions.

Example

Export definition for the AVEM and BFSI tests, as well as for a custom test battery TB1 and the FEV test set.

JSON

{
      "ExportDefinitions": [
           {
          "Name": "FEV", //test set
          "Variables": [
            {
              "TestName": "RT",
              "ShortCode": "MRZ",
              "DisplayName": "Reaktionsfähigkeit"
            },
            {
              "TestName": "COG",
              "ShortCode": "MTRN",
              "DisplayName": "Konzentrationsleistung"
            },
            {
              "TestName": "LVT",
              "ShortCode": "S",
              "DisplayName": "Orientierungsleistung"
            },
            {
              "TestName": "DT",
              "ShortCode": "ZV",
              "DisplayName": "Belastbarkeit"
            },
            {
              "TestName": "ATAVT",
              "ShortCode": "UEB",
              "DisplayName": "Aufmerksamkeitsleistung"
            }
          ]
        },
		{
          "Name": "TB1", //custom testbattery TB1
          "Variables": [
            {
              "TestName": "BFSI",
              "ShortCode": "A",
              "DisplayName": "TB Veträglichkeit"
            },
			{
              "TestName": "AVEM",
              "ShortCode": "DISTANZ",
			  "DisplayName": "TB Distanzierung"
            }
          ]
        },
		{
          "Name": "BFSI", //standard test
          "Variables": [
            {
              "TestName": "BFSI",
              "ShortCode": "A",
              "DisplayName": "Agreeableness"
            },
            {
              "TestName": "BFSI",
              "ShortCode": "C",
              "DisplayName": "Conscientiousness"
            },
            {
              "TestName": "BFSI",
              "ShortCode": "E",
              "DisplayName": "Extraversion"
            },
			{
              "TestName": "BFSI",
              "ShortCode": "N",
              "DisplayName": "Emotional stability"
            },
			{
              "TestName": "BFSI",
              "ShortCode": "O",
              "DisplayName": "Openness"
            }
          ]
        },
		{
          "Name": "AVEM", //standard test
          "Variables": [
            {
              "TestName": "AVEM",
              "ShortCode": "DISTANZ",
              "DisplayName": "Distancing ability"
            },
            {
              "TestName": "AVEM",
              "ShortCode": "EHRGEIZ",
              "DisplayName": "Work-related ambition"
            },
            {
              "TestName": "AVEM",
              "ShortCode": "ERFOLG",
              "DisplayName": "Experience of success at work"
            },            
          ]
        }
      ]
    }

GDT input files

The GDT input files containing personal data for import must follow the structure defined for the GDT set type 6302 – New Test Request. It must include all mandatory fields, and each line must be terminated with carriage return and line feed characters (CR LF).

To be processed, the input file must be placed in the preconfigured GDTSourceDirectory

The input GDT file must be encoded in UTF-8. Using any other encoding may result in incorrect handling of names containing special characters, and proper data processing cannot be guaranteed.

File name

Name of the file must match format [GDTReceiver][GDTSender][free text].gdt with the values of GDTReceiver and GDTSender as defined in the VIS settings file, see: GDT plugin | vis_config.

The following example file name matches the default values in the configuration: WTSBAD_max_mustermann.GDT:

“WTS” is the GDTReceiver
“BAD” is the GDTSender
“_max_mustermann” is just free text that is irrelevant for processing
“.GDT” is the mandatory file extension

File structure

The file structure must be exactly as defined in the GDT standard. The following description is only provided as contextual information. For details on the required file structure, see the GDT 2.1 standard.

The file consists of several lines in text format. Each line starts with 3 characters specifying the length of the line in total characters, including control characters. It is then followed by a 4 character field label and the content. Each line is terminated by a carriage return and line feed character.

Considering the example line “0133102John”, it consists of:

“013”: the total length (3 for “013” itself + 4 for the field label “3102” + 4 for “John” + the 2 control characters CR LF)
“3102”: the field label for Patient First Name
“John”: the value

Supported field labels

Field label	GDT Description	Field in VTS	Note
8000	Sentence ID		Mandatory Must contain 6302
8100	Sentence Length		Mandatory The system does not validate the Length field in incoming messages, even though this value is typically required. The field should indicate the total length of the entire message or sentence in bytes. However, VIS does not check this value and will not reject messages that contain an incorrect length.
9218	Version GDT		Mandatory Must be 2.10
3000	Patient Number / Patient Label	Personal ID	Mandatory Numerical number between 1 and 2147483647 No leading zeros allowed.
3101	Name of Patient	Last name	Mandatory
3102	Patient First Name	First name	Mandatory
3103	Patient Birth Date	Date of birth	Mandatory Format DDMMYYYY
3110	Patient Sex	Gender	Mandatory Allowed values: 1 - male 2 - female
3628	First Language of Patient	Language	Optional - Value taken from the configuration if not provided. Language code in BCP 47 format. E.g. de-DE for German, en-US for English.
4221	Education level	Education level	Optional - Value taken from the configuration if not provided. Numerical value between 0 and 5. ? - Education level unknown 1 - Compulsory schooling not completed (less than 9 years of school) or special school 2 - Completed compulsory schooling or an intermediate secondary school (9-10 years of school) 3 - Completed vocational training (10-12 years of school) 4 - High school graduation with university entrance exam (12-13 years of school) 5 - University or college degree

Example input file

CODE

01380006302
0128100128
01392182.10
01330001234
0123101Doe
0133102John
017310302031988
01031101
0143628de-DE
01042213

Example file for download: WTSBAD_example_input_file.gdt

Output GDT file

The output GDT file containing test result data follows the structure of GDT set type 6310 - Test Data Transfer

The output file is stored by the GDT plugin into predefined folder GDTOutputDirectory.

File name

Exported output GDT files have the following name structure [GDTSender][GDTReceiver].[gdt/incremental number] This means the extension will be .gdt for the first file, and a three digit number starting with 001 for all subsequent files, e.g. BADWTS.GDT, BADWTS.001, BADWTS.002.

Example output file

Example of an output GDT file containing test results for the BFSI test based on the example configuration

CODE

01380006310
0128100864
0138402BFSI
014921802.10
017300086220512
0153101Homola
0173102Vladimir
017310326042021
01031102
017620026052025
0156201143014
0356220Big-Five Struktur Inventar
0126303pdf
0136304BFSI
0506305C:\PDFexport\BADWTS_86220512_BFSI.pdf
0258410BFSI/S1 - A - PR
0228411Agreeableness
01084200
0108421%
0208410BFSI/S1 - A
0228411Agreeableness
0098420
0258410BFSI/S1 - C - PR
0268411Conscientiousness
01084200
0108421%
0208410BFSI/S1 - C
0268411Conscientiousness
0098420
0258410BFSI/S1 - E - PR
0218411Extraversion
01084200
0108421%
0208410BFSI/S1 - E
0218411Extraversion
0098420
0258410BFSI/S1 - N - PR
0288411Emotional stability
01084200
0108421%
0208410BFSI/S1 - N
0288411Emotional stability
0098420
0258410BFSI/S1 - O - PR
0178411Openness
01084200
0108421%
0208410BFSI/S1 - O
0178411Openness
0098420

Test result in PDF format

In addition to the GDT output file, the GDT plugin also generates a test result in PDF format. This PDF file is saved in the directory specified by the PDFExportPath setting and is referenced in the GDT file using field 6305 – Reference to the file.

Logging

The VIS and GDT plugin generate log data that can be used to analyze their functionality. This data is recorded in the following log files:

CODE

C:\ProgramData\Schuhfried\Logs\VTS.Integration.Service.log

Please note: The directory “C:\ProgramData” is hidden by default. You can either make hidden items visible in your Windows Explorer or simply paste the path to the file into its address bar.