libRASCH

General

Download

Documentation

Resources

This section gives a short overview about the design and concepts in libRASCH. A detailed description about the concepts will be provided in the User Manual.

General Structure of libRASCH

Figure 1 shows the components of libRASCH.

Figure 1: Components of libRASCH.

For specific tasks, libRASCH use plugins. Plugins are small "programs" which are loaded when libRASCH is initialized. The library code coordinates the usage of the plugins. (A list of available plugins can be found here.)

In libRASCH exits three principal types of plugins:

• access plugins
• process plugins
• view plugins

access plugin

Access plugins handle the access to measurement files. They hide the differences of the various data formats and offer an consistent interface to the measurements. (A list of of supported file formats can be found here.)

process plugin

Process plugins perform a specifc task on the measurement (e.g. the HRT plugin calculates the Heart Rate Turbulence parameters for an ECG or the detect plugin performs a beat detection in ECG's). When implementing processing algorithms as process plugins, the data processing is performed in a standardized way.

view plugin

View plugins display the signals on the computer screen. At the moment the following GUI's are supported:

• Qt from Trolltech (for Linux)
• MFC from Microsoft (for Windows)

Measurement

A measurement is the topmost object in libRASCH. Figure 2 shows the elements of the measurement. They contain one or more recording sessions, information about the measurement object (e.g. name, forename and birthday) and general informations about the measurement. Additionally, evaluations are stored in the measurement.

Figure 2: Structure of a measurement in libRASCH.

Session

A Session (see figure 2, middle part) is a recording for a specific time interval without any interruptions during that time interval. The measurement can contain more than one recording session, but the layout of the recording (see below) must not be changed.

Recording

A recording contains the measured data (e.g. ECG leads V1-V6) or two or more sub recordings (in the figure 2, 'rec 0' has two sub recordings ('rec 1' and 'rec 2')). Sub recordings are used if more than one recording device is used. For example when one ADC-system records 3 ECG leads and one blood pressure channel and another system records 12 eeg leeds, the measurement consists of one top recording with two sub recordings. The first sub recording contains 4 channels (3 ECG and 1 blood pressure channel) and the second sub recording contains 12 channels (12 eeg channels).

The channels of sub recordings are mapped to the parent recording. This allows the access to all channels through the top most recording. The top most recording appears to be one device, which measures all the data. In the above example, this means that 'rec 0' contains 16 channels: 3 ECG, 1 blood pressure and 12 eeg channels.

Evaluation

The results of an analysis (e.g. detection of qrs complexes in ECG's) are stored in an evaluation. The evaluation contains zero or more discrete events (like 'occurrence of a qrs complex') and/or zero or more continuous events (like 'time interval with noise').

Event

An event describes the occurrence of something in a recording (e.g. a heartbeat in an ECG). The event has one or more event properties.

Event Property

An event property is a specific property of the event (e.g. the position of the event, the type of the event). A specific event property is allowed only once in an evaluation, for example there can be not more than one 'qrs position' property.

Event Set

An event set describes a group of event properties. For example the event set 'heartbeat' contains all properties which belongs to a heart beat (like position of qrs complex, RR interval, type of qrs complex, systolic blood pressure).