Entwicklung einer erweiterbaren Struktur zur Abbildung medizinischer Instrumente [original]

Universität Ulm | 89069 Ulm | Germany Fakultät für

Medizin

Institut für Medizinische

Systembiologie

Entwicklung einer erweiterbaren

Struktur zur Abbildung

medizinischer Instrumente

Masterarbeit an der Universität Ulm

Vorgelegt von:

Maximilian Scheurich

[email protected]

Gutachter:

Prof. Dr. Hans A. Kestler

Prof. Dr. Manfred Reichert

Betreuer:

Dr. Johannes Schobel

2020

Fassung 21. Mai 2020

This work is licensed under the Creative Commons. Attribution-NonCommercial-ShareAlike 3.0

License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/de/

or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California,

94105, USA.

Satz: PDF-L

TEX2ε

Kurzfassung

Die Erfassung und Verarbeitung von Daten spielt in der Medizin eine große Rolle. Von

der Patientenaufnahme bis hin zur Abbildung von Krankheitsverläufen und Therapie-

ansätzen werden Daten erfasst, verarbeitet und analysiert. Zahlreiche Arbeiten haben

sich in den letzten Jahren mit dieser Thematik auseinander gesetzt um diesen Weg zu

digitalisieren und zu optimieren. Strukturen, wie sie in standardisierten Protokollen oder

Dateiverwaltungssystemen zu finden sind, gewährleisten eine typsichere und einheitliche

Möglichkeit Daten zu sichern und zu übertragen. Motivation dieser Arbeit ist es nicht nur

eine Struktur zu schaffen, die die Abbildung von medizinischen Instrumenten ermöglicht.

Vielmehr zielt diese Arbeit darauf ab eine einheitliche Grundlage für datenverarbeitende

Systeme in der Medizin zu erstellen.

Trotz der vielen guten Ansätze in Bezug auf die Erfassung von Daten im Bereich der

Medizin, kommt es aufgrund fehlender Standardisierung oftmals zu Problemen bei der

Verarbeitung und dem Austausch dieser Informationen. Ein Lösungsansatz bietet eine

gemeinsame Struktur, welche unabhängig von dem Anwendungssystem verwendet

werden kann. Ziel dieser Arbeit soll es nicht sein eine vollendete Datenstruktur zu

präsentieren. Viel mehr soll das Ergebnis eine Grundlage schaffen, auf die zukünftige

Projekte aufbauen können. Es soll eine Vorgabe geschaffen werden, die aber zugleich

eine dynamische Erweiterung ermöglicht und zukünftige Vorhaben nicht begrenzt. Eine

Grundvoraussetzung für das Gelingen ist die strukturelle Vereinfachung ein medizini-

scher Datenerfassung.

iii

Danksagung

An dieser Stelle möchte ich mich bei all denjenigen bedanken, die mich während der

Anfertigung dieser Masterarbeit unterstützt und motiviert haben.

Ein besonderes Dankeschön geht an meinen Betreuer Dr. Johannes Schobel, der für

hilfreiche Anregungen und konstruktive Kritik bei der Erstellung dieser Arbeit gesorgt

hat.

Inhaltsverzeichnis

1 Einleitung 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Grundlagen 5

2.1 Medizinische Instrumente . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Internationalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Endbenutzer Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Verwandte Arbeiten 11

3.1 FHIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 openEHR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 CDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4 QuestionSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Konzept 17

4.1 Datenerfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Datenverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Anforderungsanalyse 23

5.1 Aufgabenanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Einsatzziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.2 Benutzerprofilanalyse . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2 Systemaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . 26

5.2.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . 29

vii

Inhaltsverzeichnis

6 Architektur 31

6.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.1 Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2 Konfigurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7 Ausgewählte Implementierungsaspekte 47

7.1 Verwendete Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.1.1 GoJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.1.2 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.1.3 class-validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.2 Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.2.1 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.2.2 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.2.3 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2.4 Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.3 Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.4 Anwendungslogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8 Diskussion 63

9 Zusammenfassung und Ausblick 69

9.1 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

A Anhang 79

viii

Einleitung

Folgende Abschnitte bringen dem Leser die Motivation dieser Arbeit, sowie die damit

einhergehende Zielsetzung und auftretende Probleme näher. Zuletzt folgt eine Beschrei-

bung des Aufbaus dieser Arbeit.

1.1 Motivation

Die Erfassung und Verarbeitung von Daten spielt in der Medizin eine große Rolle. Von der

Patientenaufnahme bis hin zur Abbildung von Krankheitsverläufen und Therapieansätzen

werden Daten erfasst, verarbeitet und analysiert. Zahlreiche Arbeiten haben sich in den

letzten Jahren mit dieser Thematik auseinander gesetzt um diesen Weg zu digitalisieren

und zu optimieren. Einen Beweis und die Grundlage für den Bedarf einer Digitalisierung

in diesem Bereich liefert unter anderem die Arbeit [31].

Die Universität Ulm, insbesondere das Institut für Datenbanken und Informationssysteme,

hat dazu mit den veröffentlichten Arbeiten [

] einen großen

Beitrag geleistet.

Strukturen, wie sie in standardisierten Protokollen oder Dateiverwaltungssystemen zu

finden sind, gewährleisten eine typsichere und einheitliche Möglichkeit Daten zu sichern

und zu übertragen. Motivation dieser Arbeit ist es nicht nur eine Struktur zu schaffen, die

die Abbildung von medizinischen Instrumenten ermöglicht. Vielmehr zielt diese Arbeit

darauf ab eine einheitliche Grundlage für datenverarbeitende Systeme in der Medizin zu

erstellen.

1 Einleitung

1.2 Problemstellung

Trotz der vielen guten Ansätze in Bezug auf die Erfassung von Daten im Bereich

der Medizin, kommt es aufgrund fehlender Standardisierung oftmals zu Problemen

bei der Verarbeitung und dem Austausch dieser Informationen. Die Arbeit [

] zielt

darauf ab Daten von schwangerer Frauen zur Erfassen und zu Bearbeiten. Dagegen

befasst sich die Arbeit [

] mit der Erfassung von Astmahnpatienten. Aufgrund fehlender

Standarisierung in Bezug auf die zugrundeliegende Datenstruktur ist es nur möglich

diese beiden Ansätze durch die Entwicklung mehrerer Schnittstellen in Einklang zu

bringen.

Ein Austausch von Patientendaten zweier medizinischer Institutionen, die nicht das

selbe Anwendungssystem zur Erfassung und Abbildung von Daten besitzen stoßen

auf ähnliche Probleme. Für den Austausch ist in diesem Fall entweder eine manuelle

Eingabe der Daten oder eine erneute Befragung oder Untersuchung des Patienten

nötig. In beiden Fällen ist der Patient der Leid tragende. Eine wiederholte Analyse kostet

Zeit und belastet den Patienten unnötig. Eine manuelle Eingabe wiederum belastet die

Ressourcen des medizinischen Instituts.

Ein Lösungsansatz bietet eine gemeinsame Struktur, welche unabhängig von dem

Anwendungssystem verwendet werden kann.

1.3 Zielsetzung

Ziel dieser Arbeit soll es nicht sein eine vollendete Datenstruktur zu präsentieren. Viel

mehr soll das Ergebnis eine Grundlage schaffen, auf die zukünftige Projekte aufbauen

können.

Es soll eine Vorgabe geschaffen werden, die aber zugleich eine dynamische Erweiterung

ermöglicht und zukünftige Vorhaben nicht begrenzt. Eine Grundvoraussetzung für das

Gelingen ist es durch ein strukturelle Vereinfachung ein komplexes Systems in ein

kompliziertes zu überführen, welches beherrschbar ist.

1.4 Struktur der Arbeit

Die Arbeit ist wie folgt in neun Kapitel unterteilt. Die Definition und Bedeutung medizi-

nischer Instrumente wird in Kapitel 2 geklärt. In Kapitel 3 werden mehrere verwandte

Arbeiten vorgestellt. Es werden die Kernaspekte dieser Arbeiten erläutert, um eine

Einordnung der zu entwickelnden Datenstruktur vorzunehmen.

Kapitel 4 beschäftigt sich mit der Erhebung von Daten, sowie mit der daraus resultieren-

den Technik zur Entwicklung einer erweiterbaren Software im Sinne der Endbenutzer-

Entwicklung, die in Kapitel 2 erläutert wird.

Das Kapitel 5 befasst sich mit den Anforderungen an die Datenstruktur. Sowohl funktio-

nale, als auch nicht-funktionale Anforderungen werden in diesem Abschnitt definiert.

Das Kapitel 6 soll einen Einblick in den Aufbau der Datenstruktur geben und wird

durch das folgende Kapitel 7 ergänzt, in dem die wichtigsten verwendeten Technologien

vorgestellt werden. Kapitel 8 nimmt Bezug auf die in Kapitel 5 definierten Anforderungen

anhand einer exemplarischen Erweiterung der Datenstruktur ein. In Kapitel 9 wird

abschließend ein Fazit über das behandelte Thema gezogen und eine Prognose in

Hinblick auf zukünftige Arbeiten erstellt.

Grundlagen

Diese Kapitel bringt dem Leser einige Grundlagen näher und schafft ein gemeinsames

Verständnis für den Begriff „medizinische Instrumente“.

2.1 Medizinische Instrumente

Der Begriff „medizinisches Instrument“ wird traditionell mit praktischen Werkzeugen

in der Medizin assoziiert. Eine Erweiterung der Bedeutung dieses Begriffs schließt

heutzutage psychologische Hilfsmittel, zur Messung menschlichen Verhaltens mit ein.

Darunter fallen Fragebögen, so wie Interviews [22].

Diese Arbeit beschränkt sich auf die Instrumente in den Bereichen des Gesundheitswe-

sen und der Psychologie. Bei der Betrachtung eines medizinischen Instrumentes unter

dem Aspekt des psychologischen Hilfsmittels lassen sich viele wiederkehrende Bereiche

erkennen. Diese werden im Verlauf dieser Arbeit als Elementen eines medizinischen

Instrumentes bezeichnet. Das Ziel dieser Arbeit ist es diese Elemente zu definieren, zu

kategorisieren und schlussendlich in einer Datenstruktur abzubilden.

Elemente medizinischer Instrumente

Im Verlauf dieser Arbeit wird der Begriff „medizinisches Instrument“ häufig mit dem

englischen Wort für Fragebogen (engl.: Questionnaire) gleichgesetzt. Es handelt sich

bei einem Fragebogen um eine konkrete Form eines medizinischen Instruments.

2 Grundlagen

Die Tabelle 2.1 soll einen Überblick über die in dieser Arbeit behandelten Elemente

geben. Es wird zwischen vier Arten von Elementen unterscheiden. Die Strukturelemente

bilden das Gerüst des

Questionnaires

. Sie sind Träger der Datenerfassungselemen-

te und dienen zur Abbildung komplexer Filterfragen. Unter den Ereigniselemente sind

alle Elemente versammelt, die eine Bedingung für ein Ereignis tragen oder den Ausgang

bestimmen. Die Beschreibungselemente dienen der Informationsmitteilung. Es kann sich

hierbei um Bilder, als auch um längere Erklärungstexte handeln. Die Datenerfassungs-

elemente beinhalten alle Elemente, die direkt oder indirekt Patientendaten erfassen

können. Hierzu zählen auch Sensoren, welche keine aktive Bearbeitung benötigen [

Strukturelemente

Page Gruppiert mehrere Datenerfassungselemente.

Start

Besitzt die gleichen Eigenschaften wie

Page

, kann aber nur einmal

in einem medizinischen Instrument vorkommen.

End

Besitzt die gleichen Eigenschaften wie

Page

, kann aber nur einmal

in einem medizinischen Instrument vorkommen.

Gateways

AND-Gateway

Eröffnet mehrere Pfade, die in beliebiger Reihenfolge bearbeitet

werden können.

XOR-Gateway

Eröffnet mehrere Pfade, die sich über eine Bedingung gegenseitig

ausschließen.

LOOP-Gateway Ermöglicht es einen Pfad n-mal zu durchlaufen, mit n∈N\ {0}.

Ereigniselemente

Case

Markiert Pfade mit einem Fall, bei der Verwendung eines XOR-

Gateways.

Condition Beinhaltet die Bedingung eines XOR- oder LOOP-Gateways.

Event Führt eine Aktion aus, wenn dieses Element betreten wird.

Beschreibungselemente

Text Hält Texte zur genaueren Beschreibung für den Benutzer bereit.

Custom Hält eine benutzerdefinierte Informationsübergabe bereit.

Headline Überschrift zur Beschreibung eines Abschnittes.

Media

Hält verschiedene Informationsquellen bereit, wie Bilder oder Vi-

deos.

2.2 Internationalisierung

Datenerfassungselemente

Sensor

Ermöglicht das einlesen von Daten über verschiedene Sensoren,

wie Blutdruck- oder Pulsmessungen.

Questions

Matrix Erlaubt Auswahlmöglichkeiten in einer Matrixanordnung.

FreeInt Erlaubt die Eingabe einer Zahl.

FreeText Erlaubt die Eingabe eines Textes.

FreeDate Erlaubt die Eingabe eines Datums.

Slider Erlaubt die Eingabe über einen Schieberegler.

DropDown Erlaubt die Auswahl aus einem Dropdown-Menü.

Buttongrid Erlaubt die Eingabe über ein Schaltflächenraster.

Likert

Erlaubt die Erfassung von persönlichen Einstellungen nach der

Likert-Skala.

Ranking Erlaubt eine Einordnung.

YesNo Erlaubt nur Antworten mit „Ja“ und „Nein“.

MultipleChoice Erlaubt die Auswahl mehrere Artikel.

Distribution Erlaubt eine Antwort über eine Verteilung.

SingleChoice Erlaubt die Auswahl von genau einem Artikel

Tabelle 2.1:

Gliederung der Struktur-, Ereignis-, Beschreibungs- und Datenerfassungselementen

2.2 Internationalisierung

Internationalisierung (i18n) spielt eine zentrale Rolle bei der benutzerorientierten Soft-

wareentwicklung. Sie bietet die Möglichkeit Texte, Zahlen und Daten an die sprachlichen

und kulturellen Eigenschaften des Benutzer oder des Patienten anzupassen ohne den

Quellcode ändern zu müssen [23].

Grundlage für die erfolgreiche Einbindung von Sprachpaketen sind die Datenobjekte,

auf welchen das Programm aufbaut. Für eine erfolgreiche Umsetzung der Datenstruktur

ist es deshalb unabdinglich frühzeitig die Internationalisierung einzuplanen. Zu diesem

Zweck wurde eine Schnittstelle definiert, die eine einheitliche Erstellung von Sprachpake-

2 Grundlagen

ten erlaubt. Dem Benutzer soll es bei der Erstellung eines

Questionnaire

außerdem

möglich sein eigene Texte in Abhängigkeit von den eingebundenen Sprachpaketen zu

setzten.

Das Listing 2.1 zeigt, wie ein

TextElement

mit den Sprachen Deutsch und Englisch

erstellt werden kann.

1export class TextElement extends BaseElement {

2@IsI18n()

3headline: I18n = {};

4@IsI18n()

5text: I18n = {};

8const text = new TextElement();

9text.headline = {

10 de: "Überschrift",

11 en: "Headline"

12 };

13 text.text = {

14 de: "Das ist ein Beispieltext",

15 en: "This is a sample text"

16 };

Listing 2.1: Internationalisierung am Beispiel TextElement

2.3 Endbenutzer Entwicklung

Laut des Artikels [

] zählen sich 90 Millionen Amerikaner zu einer Gruppe, die einfache

Programmieraufgaben in ihrer täglichen Arbeit bewältigt. Mit der steigenden Digitalisie-

rung und dem täglichen Einsatz von Computern soll diese Zahl über die nächsten Jahre

noch weiter ansteigen.

Unter dem Begriff „Endbenutzer Entwicklung“ versteht man in der Informatik die Entwick-

lung eine Software, die es dem Benutzer ermöglicht Erweiterungen und Anpassungen

vorzunehmen. Das bekannteste Beispiel hierfür ist die Makroprogrammierung in Tabel-

lendokumenten, wie LibreOffice oder Microsoft Excel. Die Endbenutzer Entwicklung ist

2.3 Endbenutzer Entwicklung

auch unter Endbenutzer Programmierung bekannt, welche sich auf Werkzeuge bezieht

mit denen der Endbenutzer eine Änderung von Software-Artefakten vornehmen kann,

ohne erweiterte Programmierkenntnisse zu besitzen [18, 28, 36].

Ein Teilgebiet der Endbenutzer Entwicklung beschäftigt sich mit grafischen Programmier-

sprachen, die es dem Benutzer ermöglichen Code durch visuelle Elemente zu schreiben

und nicht wie bei den üblichen Programmiersprachen durch die Eingabe eines Textes.

Durch die Verwendung von Blöcken, die über Linien verbindet werden können, soll es

dem Benutzer erleichtert werden Programme leichter zu verstehen.

Für diese Arbeit wird das Konzept der Endbenutzer Entwicklung auf die Erstellung

einer medizinischen Instruments übertragen. Jedem Benutzer muss es möglich sein ein

medizinisches Instrument zu erstellen.

Die Arbeit [

] dient als Vorlage bei der Entwicklung einer Anwendung, die es dem

Benutzer in nur wenigen Schritten ermöglichen soll Anpassungen vorzunehmen, ohne

erweiterte Programmierkenntnisse zu haben.

Verwandte Arbeiten

Dieses Kapitel setzt sich mit verwandten Arbeiten und deren Umsetzung auseinan-

der. Es soll den aktuellen Stand des behandelten Themas widerspiegeln, sowie erste

Erkenntnisse bezüglich der Anforderungen und Problemstellung liefern.

3.1 FHIR

Der FHIR (Fast Health Interoperability Resources) Standard der Stiftung HL7

FHIR

dient dem Austausch von Daten im Gesundheitswesen. Einer der Vorgänger von FHIR

war HL7 v2 und ist in vielen Krankenhausgemeinschaften vertreten.

Dieser Standard dient dem Austausch von Gesundheitsinformationen, so wie elek-

tronischer Krankenakteninformationen. FHIR beschränkt sich allerdings nicht nur auf

Patientendaten, die dessen Gesundheitszustand betreffen. Es lassen sich mithilfe des

FHIR Standards ganze Prozesse abbilden, die sowohl Patienten als auch Ärzte, Geräte

und Organisationen betreffen. Daten von und über den Patienten können ebenfalls

erfasst werden. Mit FHIR können nicht nur Diagnosen und Allergien, sowie familiäre

Zusammenhänge abgebildet werden, sonder auch die Medikation eines Patienten über-

wacht werden.

Die Abbildung 3.1 zeigt die grundlegenden Datentypen des FHIR Standards. Es wird

unterscheiden zwischen primitiven und komplexen Datentypen. Im Rahmen dieser

Arbeit sind vor allem Zweitere von Bedeutung. Mithilfe der Elemente

Identifier

HumanName

und

Address

lassen sich ganz leicht Informationen eines Patienten ab-

bilden, die nicht unmittelbar in Zusammenhang mit seiner Gesundheit stehen. Sogar

3 Verwandte Arbeiten

wiederkehrende Ereignisse lassen sich durch das

Period

-Element wiedergeben. Die

Datentypen lassen sich sowohl in XML, als auch in JSON abbilden [15].

Abbildung 3.1: FHIR Datentypen [6]

Der Aufbau eines Fragebogens nach FHIR Standard besteht aus

Elementen, für die

gilt

n∈N∧n≥0

. Der Fragebogen selbst enthält Metadaten, wie den Verfasser, das

Erstellungsdatum und den Titel. Ein Element des Fragebogens kann in eine von drei

Kategorien eingeteilt werden. Die Anzeige-Elemente spiegeln Texte wieder, die Anwei-

sungen, Hintergrundinformationen oder andere informative Inhalte besitzen können.

Ein Anzeige-Element hat, wie auch eine Gruppen-Element keine Möglichkeit Daten zu

erfassen. Ein Gruppen-Element gliedert den Inhalt des Fragebogens und kann mehrere

Frage-Elemente enthalten. Ein Frage-Element besitzt eine spezifische Frage, welche

eine Antwort zulässt. Die Art der Frage bestimmt dabei sowohl die Antwort, als auch

den Type des Frage-Elements [12].

Der FHIR Standard ist ein mächtiger Apparat zur Abbildung von Daten, die auf das

Gesundheitswesen bezogen sind. Eine so umfangreiche Datenstruktur hat, wie auch

schon der Vorgänger HL7 v3, seinen Preis zu Gunsten der Komplexität der Bedienung.

3.2 openEHR

openEHR ist eine Lösung für Informationssystem im Gesundheitswesen. Die verschiede-

nen Bereiche von openEHR werden durch die internationale gemeinnützige Organisation

3.2 openEHR

openEHR verwaltet. Abbildung 3.2 gibt einen Überblick über die Zusammensetzung des

Systems.

Abbildung 3.2: openEHR Überblick [11]

Die relevanten Aspekte des openEHR Systems beschränken sich im Rahmen dieser

Arbeit auf die Bereiche Reference Model und Foundation types, Definitions, Identifiers.

Während in dem Abschnitt zu Foundation types, Definitions, Identifiers grundlegende

primitive Datentypen spezifiziert und definiert werden, werden in Abschnitt Reference

Model konkretere Vorgaben in Hinblick auf die Informationsaufnahme von und für Pati-

enten gemacht. Die Abbildung 3.3 zeigt den Aufbau eine Datenstruktur anhand einer

exemplarischen Gewichtsmessung.

3 Verwandte Arbeiten

Abbildung 3.3: Beispiel Datenstruktur einer Gewichtsmessung [5]

Das Element

HISTORY

beinhaltet einen einmaligen Event, gekennzeichnet durch das

Attribut

is_periodic = False

. Das Item

POINT EVENT

, welcher den Event festhält

referenziert die Daten. In diesem Fall wird eine

ITEM_SINGLE

erzeugt, das schlussend-

lich die Werte, in diesem Fall das Gewicht, speichert.

Die openEHR Datenstruktur zeichnet sich vor allem durch die Detailgenauigkeit aus die

sie bietet. Wie allerdings die Spezifikationen zeigen, welche unter

https://specifications.openehr.org/ nachgelesen werden können, ist die Datenstruktur

und die Bereiche darum komplex und lassen sich nicht mit Leichtigkeit in bestehende

Systeme übertragen [26].

3.3 CDA

CDA (Clinical Document Architecture) ist eine auf XML basierende Datenstruktur zur

Abbildung von klinischen Daten. Einer der Vorteile von XML ist es, dass es sowohl von

Menschen gelesen werden, als auch von Maschinen bearbeitet werden kann. Dennoch

unterscheidet die CDA Spezifikation zwischen freien und strukturierten Abschnitten die

3.3 CDA

speziell für die Verarbeitung vorgesehen sind. In Listing A.1 ist dies deutlich zu sehen.

In Zeile 9 beginnt das frei Modul zur Wiedergabe von Vitalparametern eines Patienten.

In Zeile 21 beginnt ein gesonderter Abschnitt zur Verarbeitung durch Maschinen für den

gleichen Inhalt. Es werden hier allerdings, wie Zeile 25 Zeigt genau Vorgaben zu Werten

und Einheiten gemacht.

Die CDA Datenstruktur ermöglicht es des weiteren Bilder und andere Multimediainhalte

aufzunehmen. Der Aufbau eines CDA konformen XML-Dokuments lässt sich aus Tabelle

3.1 entnehmen [17].

CDA-Header

Patienteninformationen, Autor, Erstellungsdatum, Dokumenttyp,

Anbieter, etc.

CDA-Body

Klinische Details, Diagnose, Medikamente, Nachsorge, etc. Wird

als freier Text in einem oder mehreren Abschnitten präsentiert und

kann optional auch kodierte Einträge enthalten.

CDA Level 1

Die Wurzelhierarchie und die uneingeschränkteste Version des

Dokuments. Ebene Eins unterstützt die volle CDA-Semantik und

hat eine begrenzte Kodierfähigkeit für den Inhalt. Ein Beispiel für

eine Beschränkung des Dokumenttyps auf Ebene Eins wäre eine

„Entladungszusammenfassung“ mit nur textlichen Anweisungen.

CDA Level 2

Zusätzliche Einschränkungen für das Dokument durch Vorlagen

auf der Ebene „Abschnitt“ (freier Text). Ein Beispiel für eine Be-

schränkung der Ebene zwei wäre eine „Entlassungszusammen-

fassung“ mit einem als Medikamente kodierten Abschnitt.

CDA Level 3

Zusätzliche Einschränkungen für das Dokument auf der Ebene

„Eingang“ (kodierter Inhalt) und optionale zusätzliche Einschrän-

kungen auf der Ebene „Abschnitt“. Ein Beispiel für eine Einschrän-

kung der Ebene drei wäre eine „Entlassungsübersicht“ mit ei-

nem als Medikamente kodierten Abschnitt mit kodierten RxNORM-

Einträgen für jedes Medikament.

Tabelle 3.1: CDA-Struktur [1, 2, 3]

3 Verwandte Arbeiten

3.4 QuestionSys

QuestionSys [

] ist ein Projekt des Instituts für Datenbanken und Informationssyste-

me der Universität Ulm, welches sich mit der Erstellung und Auswertung von mobilen

Fragebögen im Bereich der Psychologie befasst. Das Projekt entstand auf Grundlage

der Doktorarbeit von Dr. Johannes Schobel [

]. Ziel dieses Projektes ist die Mini-

mierung der Arbeit, die bei der Entwicklung von komplexen Auswertungsbögen anfällt.

Die Anwendung des Systems bezieht sich hauptsächlich auf die Benutzung mobiler

Endgeräte.

Wie die Abbildung 3.4 verdeutlichen soll, ermöglicht QuestionSys eine übersichtliche

und einfach zu handhabende Darstellung eines komplexen Arbeitsschritts bei der Er-

stellung von geführten Fragebögen. Die Erstellung eines Fragebogens ist in Form von

Prozessmodellen definiert. Die Bereitstellung eines Editors



für eine prozessorientierte

Modellierung eines Fragebogens erlaubt dem Fachexperten eine einfache Verwendung.

Darüber hinaus unterstützt QuestionSys den gesamten Lebenszyklus eines digitalen

Fragebogens, bis hin zur Evaluierung durch einen Fachexperten. Dieser wird ebenfalls

in seiner Aufgabe durch eine Datenaufbereitung



unterstützt. Diese Arbeit konnte

zeigen, dass elektronische Fragebögen den Fachexperten von kostspieligen manuellen

Aufgaben entlasten, wie die Übertragung, Transformation und Analyse der gesammelten

Daten [35, 41, 43].

Abbildung 3.4: QuestionSys Projekt-Übersicht [13]

Konzept

Dieses Kapitel soll dem Leser Einsatzmöglichkeiten der Datenstruktur, sowie Vorteile

einer gemeinsamen Basis vermitteln. Es werden in dieser Arbeit zwischen zwei Ein-

satzbereichen unterschieden. Im Bereich der Datenerfassung geht es darum welche

Informationseingabemöglichkeiten einem Benutzer und einem Patienten zur Verfügung

stehen. Bei der Datenverarbeitung geht es um die Speicherung und die Präsentation auf

stationären und mobilen Endgeräten. Die Datenanalyse wird, aufgrund des komplexen

Umfangs, in dieser Arbeit nicht behandelt.

4.1 Datenerfassung

Um ein Konzept für eine Struktur zu entwickeln, die medizinische Instrumente abbilden

soll, ist es notwendig die Einsatzziele dafür zu kennen. Der Bereich Datenerfassung spielt

eine große Rolle, da die Informationsgewinnung essenziell für die Informationswiederga-

be ist. In den nächsten zwei Abschnitten wird skizziert wie eine mögliche Datenerfassung

durch den Benutzer/Ersteller eines medizinischen Instrumentes aussehen und durch

den Patienten Daten erfasst werden können. Einen guten Anhaltspunkt liefert die Arbeit

[34], welche sich intensiv mit der Crowd Sensing Datenerfassung beschäftigt.

Benutzer

Die Abbildung 4.1 zeigt einen Konfigurator der einem Benutzer, in diesem Fall einem

möglichen Psychologen, die Möglichkeit gibt ein medizinisches Instrument in Form eines

Questionnairs zu erstellen. Unabhängig von der Oberfläche, die in Abbildung 4.1 gezeigt

4 Konzept

wird kann man feststellen, dass für die Erstellung eines medizinischen Instrumentes

häufig wiederkehrende Elemente verwendet werden. Daraus lässt sich eindeutig ableiten,

dass eine objektorientierte Herangehensweise von Vorteil ist. Es wird außerdem klar,

dass eine Abstraktionen von verschiedenen Elementen Vorteile bei sich wiederholenden

Datensätzen zur Folge hat. Durch eine Abstraktion und objektorientierte Vorgehensweise

lassen sich komplexere Aufbauten abspeichern und wiederverwenden.

Abbildung 4.1: Erstellungsvorgang eines medizinischen Instrumentes

Patienten

Auf Seiten des Patienten ist für die Datenerfassung schematisch die Abbildung 4.2

dargestellt. Es werden in der Abbildung 4.2 verschiedene Arten von Datenerfassungs-

elementen gezeigt, die es zu Untersuchen gilt. Die ersten drei Elemente erfassen

Informationen des Patienten über Texteingabe, Schieberegler und der Eingabe eines

Datums. Elemente vier und fünf heben sich aufgrund ihrer komplexeren Struktur von

den ersten drei ab. Es wird eine andere Struktur, bzw. ein komplexer Datentyp benötigt

für die Abbildung der Itemauswahl in Element vier und die Tabelle in Element fünf.

4.2 Datenverarbeitung

Abbildung 4.2:

Schematische Darstellung des digitalen Fragebogens aus Sicht des

Patienten

Durch Abbildung 4.2 wird außerdem klar, dass die zu entwickelnde Datenstruktur Ei-

genschaften enthalten muss, welche die Darstellung, bzw. die Art der Elemente für den

Entwickler seitens der Anwendung unterstützen. Ein objektorientierter Ansatz stellt sich

auch in diesem Kontext als vorteilhaft heraus.

4.2 Datenverarbeitung

Die Datenverarbeitung spielt bei der Entwicklung einer Struktur zur Abbildung von

medizinischen Instrumenten eine zentrale Rolle. Variable und horizontal ausgeprägte

Strukturen haben den Vorteil flexibel anpassbar zu sein und könne einfacher auf Aus-

nahmen reagieren. Soll eine große Menge an Daten in kurzer Zeit verarbeitet werden,

so sind statische Strukturen im Vorteil. Ein vergleichbares Phänomen ist im Bereich von

NoSQL und SQL Datenbanken zu sehen. In der Arbeit [

] wird diesbezüglich Stellung

genommen.

4 Konzept

In den kommenden zwei Abschnitten gilt es herauszufinden welchen Einfluss der Aufbau

der Struktur, die in dieser Arbeit entwickelt werden soll, auf die Datenverarbeitung hat.

Backend

Die Abbildung 4.3 zeigt die Schnittstelle des QuestionSys Projektes, welches dem Institut

für Datenbanken und Informationssysteme (DBIS) angehört. Diese API (Programmier-

schnittstelle) entstand auf Basis der Dissertation von Dr. Johannes Schobel [

]. Die

unter der Bezeichnung „Instruments“ aufgelisteten Pfade der Schnittstelle zeigen alle

Methoden, die für eine Speicherung, Bearbeitung und Löschung eines medizinischen

Instrumentes zu Verfügung stehen. Bei der darunterliegenden Datenbank handelt es

sich um eine Postgres SQL Datenbank. Der Vorteil gegenüber einer NoSQL Datenbank

oder einer anderen SQL Datenbank liegt in der Fähigkeit von PostgreSQL neben der

performanten Datenverarbeitung auch mit JSON Objekten umgehen zu können. Durch

diese Besonderheit wurde darauf geachtet, dass eine Anpassung der Datenstruktur der

medizinischen Instrumente keine Neuentwicklung des Backends benötigt wird.

Abbildung 4.3: QuestionSys Server API

4.2 Datenverarbeitung

Endgeräte

Eine Studie des Pew Research Center [

] im Jahr 2019 hat ergeben, dass 76% aller

an der Umfrage beteiligte Erwachsenen in Ländern mit fortgeschrittener Wirtschaft

ein Smartphone besitzen. In Entwicklungsländern sind es im Durchschnitt 45%. Diese

Tatsache, sowie die immer stärker wachsende digitale Branche legt nahe, insbesondere

Smartphones bei der Betrachtung von Benutzerendgeräten zu berücksichtigen. Das

wurde auch schon in den Arbeiten [

] deutlich, die sich mit der Datenerfassung auf

mobilen Endgeräten beschäftigt haben.

Eine Analyse der am häufigsten verwendeten Programmiersprachen auf GitHub von

RedMonkey [

] ergab, dass sich JavaScript, Python und Java unter den Top drei der

beliebtesten Programmiersprachen auf GitHub befinden, wie das Diagramm 4.4 zeigt.

Abbildung 4.4: RedMonk Q120 Programming Language Rankings [30]

4 Konzept

Diese Analyse, sowie die Tatsache, dass immer mehr Menschen ein eigenes Smart-

phone besitzen gibt Aufschluss über das zu verwendende Datenobjekt für diese Arbeit.

Sowohl JavaScript, als auch Python und Java unterstützen nativ oder mithilfe von Stan-

dartbibliotheken die JavaScript Object Notation (JSON). Für die Verwendung von JSON

spricht ebenfalls die Plattformunabhängigkeit, denn Framework wie Ionic [

] bieten

Entwicklern die Möglichkeit unabhängig von dem Betriebssystemen Applikation auf

Basis eines Webentwicklers (HTML, CSS, JavaScript) zu schreiben. Das hat den Vorteil,

dass Programmiercode webbasierte Frontend Anwendungen für herkömmliche Brow-

ser (Chrome, Firefox, IE, Safari) bei der Entwicklung für Smartphone Anwendungen

wiederverwendet werden können.

Die Wahl des Datenobjekts, welches in dieser Arbeit für die Umsetzung der Struktur ein-

gesetzt wird, fällt auf JSON. Die in der Arbeit [

] aufgezeigten Unterschiede von JSON

und XML tragen einen wesentlichen Anteil dieser Entscheidung. Es wird insbesondere

TypeScript verwendet, welches eine objektorientierten Programmieransatz bietet, somit

wird ebenfalls der Daten erfassende Anteil abgebildet.

Anforderungsanalyse

In diesem Kapitel werden anhand der gegebenen Problemstellung Anforderungen an

das System definiert. Es wird zunächst eine Aufgabenanalyse durchgeführt und die

Einsatzziele untersucht. Darüber hinaus wird eine Benutzerprofilanalyse erstellt, um den

Umfang der Anforderungen an die Struktur genauer einordnen zu können. In Abschnitt

5.2 wird bei der Systemaufgabenanalyse zwischen funktionalen und nicht-funktionalen

Anforderungen unterschieden.

5.1 Aufgabenanalyse

In diesem Abschnitt werden die genauen Aufgaben der zu entwickelnden Struktur

anhand einer Benutzerprofilanalyse eingegrenzt. Dieser Prozess spielt vor allem bei

der Entwicklung von Anwendungssystemen eine große Rolle. Zu beachten ist, dass die

Dramenstruktur die im Rahmen dieser Arbeit entwickelt werden soll, die Grundlage bildet

auf der zukünftige Anwendungssystem arbeiten werden. Es ist gerade deswegen von

großer Wichtigkeit diese Faktoren bei der Entwicklung der Struktur miteinzubeziehen. Je

detaillierter die Anforderungen an die Struktur herausgearbeitet werden, desto einfacher

ist es funktionsfähige und brauchbare Anwendungssysteme dafür herzustellen.

5.1.1 Einsatzziele

Die Einsatzziele von Fragebögen sind über alle Bereiche des Lebens verteilt. Man

begegnet ihnen bei Online-Umfragen, sowie bei den örtlichen Behörden in Form von

Formularen. In anderen Bereichen, wie zum Beispiel der Psychologie ist die Absicht der

5 Anforderungsanalyse

Verwendung von Fragebögen offensichtlicher. Unabhängig von der Art des Auftretens

erfüllen Fragebögen im Allgemeinen den Zweck, Informationen und Meinungen bezüglich

eines im Fragebogen angesprochenen Themas zu sammeln. Die Auswertung führt

häufig zu einem besseren Verständnis der Verhaltensweise von Personen in bestimmten

Situationen oder zur Aufnahme von Personendaten ohne analytischen Hintergrund.

Insbesondere bei der Entwicklung von Fragebögen im Bereich der Psychologie kann

es zu hohem Arbeitsaufwand kommen. Der Grund hierfür ist der analytische Aspekt,

welcher über eine gezielte Fragestellung erreicht werden soll. Bei der Beantragung

eines Führerscheins zum Beispiel sind die gestellten Fragen unabhängig von der Per-

sonengruppe immer gleich aufgestellt. Eine psychologische Umfrage bezüglich des

Trinkverhaltens hingegen muss zwischen Personengruppen differenziert und teilweise

nach Antwortmöglichkeiten gefiltert werden. Ein hervorragende Einsatzmöglichkeit von

digitalen Fragebögen liefert der Artikel „Outpatient Tinnitus Clinic, Self-Help Web Plat-

form, or Mobile Application to Recruit Tinnitus Study Samples?“ [

], in welchem die

Sammlung von Informationen zum Krankheitsbild „Tinnitus“ beschrieben wird.

Besonders in der Psychologie würde man von einer verbesserten Entwicklungsmetho-

de profitiert. Somit fokussiert sich das Einsatzziel, welches im Rahmen dieser Arbeit

betrachtet wird, auf die Entwicklung psychologischer Fragebögen.

5.1.2 Benutzerprofilanalyse

Softwareentwicklung, insbesondere die Entwicklung von Benutzerschnittstellen ist abhän-

gig von der jeweiligen Benutzergruppe. Da bei einer homogenen Gruppe von Nutzern,

welche sich in relevanten Eigenschaften ähneln, auch ähnliche Erwartungen an Benut-

zerschnittstellen vorausgesetzt werden können, fasst man sie in einer Benutzerkategorie

zusammen. Für jede Benutzerkategorie wird ein Benutzerprofil erstellt, welches Auf-

schluss über die Entscheidung im Hinblick einer Benutzerschnittstelle liefern kann. Unter

der Prämisse, dass sich die Benutzergruppe hauptsächlich auf den Bereich der For-

schung, insbesondere der Psychologie, beschränkt, wird ein Psychologe die Stelle des

Repräsentanten einnehmen.

5.2 Systemaufgaben

Die Erwartungen und Kenntnisse dieses Benutzerprofils können wie folgt beschrieben

werden. Ein Psychologe besitzt in der Regel umfangreiche Kenntnisse im Bereich der

Psychologie. Aufgrund seiner Ausbildung beschränken sich die IT-Kenntnisse häufig

nur auf die Verwendung von Anwendungen. Im Bereich der Anwendungssoftware wird

eine simple und intuitive Bedienung vorausgesetzt, die effektives Arbeiten ermöglicht.

Dennoch kann davon ausgegangen werden, dass Funktionalität vor Design gestellt

wird. Diese Beurteilung schließt sich aus dem Berufsprofil, welches als rational und

strukturiert beschrieben wird.

Basierend auf den relevanten Eigenschaften eines Psychologen lässt sich schließen,

dass jede Person als Benutzer in Frage kommt, welche ein Grundverständnis von

Anwendungssoftware besitzt, keine Ausbildung in der Softwareentwicklung absolviert

hat und mit der Erstellung von Fragebögen vertraut ist.

5.2 Systemaufgaben

Der folgende Abschnitt beschäftigt sich mit den Aufgaben, die an die Datenstreukur

gestellt werden. Es werden alle zuvor angesprochenen Funktionen in konkrete Anforde-

rungen formuliert.

Die Priorisierung der Anforderungen wird im Sinne der MoSCoW-Priorisierung [

]

durchgeführt. Die MoSCoW-Priorisierung ist eine Methode, die im Bereich des Projekt-

managements erfolgreich zur Priorisierung der Anforderungsumsetzung anhand ihrer

Wichtigkeit eingesetzt wird.

Nach MoSCoW wird folgender Wertebereich differenziert:

•MUSS (eng.: MUST, unbedingt erforderlich)

•SOLL (eng.: SHOULD, sollte umgesetzt werden)

•KANN (eng.: COULD, kann umgesetzt werden, sollten wichtigere Anforderungen

schon abgeschlossen sein)

•SPÄTER (eng.: WONT, wird für einen späteren Zeitpunkt vorgemerkt)

5 Anforderungsanalyse

5.2.1 Funktionale Anforderungen

In diesem Abschnitt geht es um die konkreten funktionalen Aufgaben, die das System er-

füllen soll. Die aufgelisteten Anforderungen werden in nachfolgenden Tabellen priorisiert

und beschrieben.

Allgemeine funktionale Anforderungen

Es werden grundsätzliche Anforderungen an die zu entwickelnde Struktur, die eine

Abbildung medizinischer Instrumente darstellt, aufgelistet.

BEZEICHNUNG PRIORITÄT BESCHREIBUNG

Speichern MUSS

Der Benutzer muss die Möglichkeit haben ein medi-

zinisches Instrument in serialisierter Form für eine

spätere Bearbeitung zwischenlagern können.

Laden MUSS

Der Benutzer muss das abgelegte medizinisches

Instrument zur weiteren Bearbeitung nach der Spei-

cherung abrufen können.

Löschen MUSS

Der Benutzer muss ein medizinisches Instrument

löschen können.

Import SOLL

Der Benutzer soll bereits erstellte Teilabschnitte ei-

nes medizinischen Instrumentes zur weiteren Verar-

beitung importieren können.

Export SOLL

Der Benutzer soll ein medizinisches Instrument ex-

portieren können. Diese Funktion soll zu Speicher-

zwecken oder auch zur weiteren Verwendung des

Fragebogens in einem externen System benutzt wer-

den können.

5.2 Systemaufgaben

Metadaten SOLL

Der Benutzer soll persönliche Daten, sowie ein Er-

stellungsdatum an ein medizinisches Instrument an-

hängen können. Das bietet die Möglichkeit einer

besseren Datenverwaltung bei steigender Anzahl

von Datensätzen.

Validierung MUSS

Der Benutzer hat die Möglichkeit sein Datenobjekt

auf Korrektheit zu überprüfen.

Tabelle 5.1: Allgemeine funktionale Anforderungen

Funktionale Anforderungen an die einzelnen Elemente der Struktur

Es werden nachfolgend Anforderungen definiert, die sich direkt auf die verschiedenen

Typen von Fragebogenelemente beziehen.

BEZEICHNUNG PRIORITÄT BESCHREIBUNG

Strukturelemente

Page MUSS

Der Benutzer muss eine Seitenstruktur erstellen kön-

nen, die es ermöglicht Datenerfassungs- und Be-

schreibungselemente aufzunehmen.

Start MUSS

Der Benutzer muss einen Startpunkt für ein medizi-

nisches Instrument festlegen können.

End MUSS

Der Benutzer muss einen Endpunkt für ein medizini-

sches Instrument festlegen können.

AND-Gateway MUSS

Der Benutzer muss gleichberechtigte Pfade erstellen

können, welche den gleichen Bedingungen wie dem

Ausgangspfad unterliegen.

5 Anforderungsanalyse

XOR-Gateway MUSS

Der Benutzer muss sich ausschließende Pfade er-

stellen können.

LOOP-Gateway MUSS

Der Benutzer muss sich wiederholende Pfade erstel-

len können.

Ereigniselemente

Case MUSS

Der Benutzer muss einem Pfad ein Fallergebnis zu-

weisen können.

Condition MUSS

Der Benutzer muss einem Gateway eine Bedingung

zuweisen können.

Event SOLL

Der Benutzer soll die Möglichkeit haben, einem Pfad

ein Event zuweisen zu können.

Beschreibungselemente

Text MUSS

Der Benutzer muss einer Seitenstruktur Beschrei-

bungstexte beifügen können.

Custom KANN

Der Benutzer kann benutzerdefinierte Elemente ei-

ner Seitenstruktur hinzufügen.

Headline MUSS

Der Benutzer muss Überschriften an eine Seiten-

struktur setzten können.

Media MUSS

Der Benutzer muss Medieninhalte in eine Seiten-

struktur einbinden können.

Datenerfassungselemente

5.2 Systemaufgaben

Sensor MUSS

Der Benutzer muss eine Schnittstelle für einen Sen-

sor in die Seitenstruktur einbinden können.

FreeInput MUSS

Der Benutzer muss freie Eingabeelemente in Form

von Text-, Zahl- und Dateneingaben, in die Seiten-

struktur aufnehmen können.

Slider MUSS

Der Benutzer muss Schieberegler als Mittel zu Da-

tenerfassung in die Seitenstruktur aufnehmen kön-

nen.

Choice MUSS

Der Benutzer muss Fragen zur Datenerfassung mit

vordefinierten Auswahlmöglichkeiten in die Seiten-

struktur einbinden können.

Likert MUSS

Der Benutzer muss Fragen zur Messung persönli-

cher Einstellungen nach dem Likert-Skala Verfahren

einbinden können.

Ranking MUSS

Der Benutzer muss eine Datenerfassung mithilfe von

Einstufungsfragen einbinden können.

Tabelle 5.2: Funktionale Anforderungen

5.2.2 Nicht-funktionale Anforderungen

In diesem Abschnitt werden die nicht-funktionalen Anforderungen an der Struktur defi-

niert. Diese spezifizieren im Wesentlichen die Qualitätsansprüche an die Struktureigen-

schaften. Die aufgelisteten Anforderungen werden in nachfolgenden Tabellen priorisiert

und beschrieben.

BEZEICHNUNG PRIORITÄT BESCHREIBUNG

5 Anforderungsanalyse

Benutzbarkeit MUSS

Die Struktur muss selbsterklärend und übersichtlich

sein.

Portierbarkeit MUSS

Das Struktur muss auf unterschiedlichen Plattfor-

men zugänglich sein.

Korrektheit MUSS

Die Struktur muss ein medizinisches Instrument kor-

rekt und vollkommen abbilden können.

Flexibilität KANN

Die Struktur kann auf unterschiedliche Datenobjekte

übertragen werden.

Erweiterbarkeit MUSS

Das Struktur muss sich mit wenig Aufwand erweitern

oder ändern lassen.

Tabelle 5.3: Nicht-funktionale Anforderungen

Architektur

Dieses Kapitel beschäftigt sich mit der grundlegenden Datenstruktur und den Rela-

tionen der einzelnen Elemente. Zunächst wird in Abschnitt 6.1 ein Überblick über die

Struktur gegeben und geklärt, wie entsprechend Designentscheidungen gefällt wurden.

Im Anschluss daran wird in Abschnitt 6.1.1 die entwickelte Struktur anhand Pseudo-

UML-Klassendiagramme vorgestellt. In Abschnitt 6.2 wird der Konfigurator vorgestellt,

der parallel bei der Entwicklung der Datenstruktur entstanden ist. Dieser Konfigurator

zeigt die Anwendbarkeit der Datenstruktur im Sinne eines „Proof of Concept“. Hierzu

wird in Abschnitt 6.2 durch das Aufzeigen der Modellvalidität bei der Erstellung eines

medizinischen Instruments mithilfe des Konfigurators Stellung genommen.

6.1 Aufbau

Durch das Aufzeigen einer formalen Grammatik soll in diesem Abschnitt der Aufbau

und Zusammenhang eines medizinischen Instrumentes (

Questionnaires

) erklärt

werden. Die Bereiche eines

Questionnaire

, einer

Group

und einer

Node

werden

mithilfe von „

{

“ und „

}

“ abgegrenzt. Verbindungen oder auch

Links

werden über „

“

dargestellt. Startpunkt eines medizinischen Instruments ist das Instrument selbst. Auf

ein Questionnaire folgen immer Groups, wie die Abbildung 6.1 zeigt.

6 Architektur

Abbildung 6.1: Formale Grammatik eines Questionnaires

Groups

lassen sich durch eine

Group

oder die Verkettung von

Group

und

Groups

aus-

drücken. Eine

Group

besteht entweder aus

Groups

oder

Nodes

. Durch die Möglichkeit

der Einbindung von

Groups

Group

können komplexere Gebilde mithilfe mehrerer

Verzweigungen entstehen. Der Vorteil einer solchen Anordnungsmöglichkeit wird in den

nachfolgenden Kapitel deutlich. In der Abbildung 6.2 wird der Aufbau von

Groups

und

einer Group grafisch dargestellt.

Abbildung 6.2: Formale Grammatik der Groups

Die Abbildung 6.3 beschreibt alle möglichen Zusammensetzungen der

Nodes

können, wie auch

Groups

, aus einer

Node

oder einer Verkettung von

Node

und

Nodes

bestehen. Durch diese Regel kann eine

Group

eine oder mehrere

Nodes

enthalten. Die

formale Grammatik terminiert mit der Auflösung einer

Node

, die eine

Node

mit

Element

zurück liefert.

6.1 Aufbau

Abbildung 6.3: Formale Grammatik der Nodes

Durch das Relationsschaubild 6.4 werden Zusammenhänge der in Tabelle 2.1 vorgestell-

ten Strukturelemente erläutert. Das Schaubild zeigt von links nach rechts die Zusammen-

setzung eines validen medizinischen Instruments. Der Einstieg ist definiert durch das

Start

-Element auf das eine oder mehrere

Group

-Elemente folgen können. Es kann

sich bei einer

Group

, wie das Schaubild zeigt, auch um das besondere

Page

-Element

handeln. Durch die dotierten Bereiche sind in den folgenden Elementen die unterschiedli-

chen

Gateways

-Gruppen gekennzeichnet. Beginnend mit dem

AND-Gateway

, welches

es erlaubt mehrere parallele Pfade zu beschreiten. An dieser Stelle ist es möglich,

sowhol beide

Pages

zu durchlaufen, als auch die nächste

XOR-Gateway

-Gruppe zu

erreichen. Ein

XOR-Gateway

erlaubt es einem Patienten, anders als die

AND-Gateway

Gruppe, nur eine Pfad bei der weiteren Ausführung des medizinischen Instrumentes

zu beschreiten. Es kann folglich entweder die

Page

durchlaufen werden oder aber das

LOOP-Gateway

betreten werden. Ein

LOOP-Gateway

besitzt die Eigenschaft

den Patienten einen definierten Pfad wiederholt durchlaufen zu lassen. Gekennzeich-

net wird diese Besonderheit durch die rückläufige Verbindung. Nach durchlaufen des

medizinischen Instrumentes bildet ein End-Element immer den Abschluss.

6 Architektur

Abbildung 6.4: Relationsschaubild der Strukturelemente [25]

6.1.1 Datenstruktur

Die entwickelte Datenstruktur soll in diesem Abschnitt anhand mehrere UML-Klassen-

diagramme vorgestellt werden. Die gezeigten UML-Klassendiagramme entsprechen aus

Anschauungszwecken nicht der Norm und spiegeln nur den schematischen Aufbau der

Struktur wider. Sie werden im Verlauf dieser Arbeit als „Pseudo-UML-Klassendiagramme“

bezeichnet.

Questionnaire

Zentrales Element der Struktur ist das medizinische Instrument (

Questionnaire

Abbildung 6.5 zeigt den

Questionnaire

, welcher für die Darstellung im Konfigurator

von den Klasse

go.Diagram

erbt. Das Klassendiagramm zeigt außerdem die verschie-

denen Abhängigkeiten und Zusammenhänge, die für eine medizinisches Instrument

bestehen.

6.1 Aufbau

Ein

Questionnaire

enthält Metadaten, die sowohl den Ersteller, als auch eine Be-

schreibung und die Version des Instruments festhalten. Über die Schnittstelle

Changelog

soll es in einer späteren Version dieser Struktur möglich sein Zwischenstände des

Objektes wiederherzustellen. Der

Questionnaire

ist außerdem die zentrale Sammel-

stelle für Medieninhalte. Diese Wahl wurde aufgrund einer besseren Offlineverarbeitung

getroffen. Medieninhalte, die in Datenerfassungs- oder Beschreibungselementen ein-

gebunden werden, stellen Verknüpfungen dar, die auf die tatsächlichen Inhalte zeigen.

Eines der wichtigsten Eigenschaften bei der Erstellung ist die Verwendungsmöglichkeit

verschiedenen Sprachen. Hierfür können mithilfe des Klasse

AvailableLanguages

unterschiedlichste Sprachpakete hinzugefügt werden, die über ein Interface definiert

sind. Dem Ersteller eines

Questionnaire

kann es so auch ermöglicht werden eigenen

Sprachpakete zu installieren.

Diagram

Changelog

I18n

category

identifiziert jede Instanz dieser Klasse eindeutig mit einem

Link

vom Typen

LinkType.CONDITIONAL.

Die Klasse

ConditionalLink

besitzt außerdem noch ein Besonderheit, das

element

Attribut. Diese Besonderheit dient der Fallunterscheidung, wie es in der Programmierung

eingesetzt wird (Switch-Case-Anweisung). Ein

ConditionalLink

kommt immer dann

zum Einsatz, wenn ein XOR-oder LOOP-Gatway aus den Strukturelementen in Tabelle

2.1 verwendet wird. Im Falle eines XOR-Gateways sind alle ausgehenden

Links

der

Transmitternode von der Klasse

ConditionalLink

und besitzen ein

CaseElement

Jeder dieser

ConditionalLinks

hält einen Fall bereit für die Bedingung, die in der

TransmitterNode

definiert ist. Dieses Vorgehen hat den Vorteil bei der Pfadüberprü-

fung nicht jede Node, auf die ein Link zeigt, aufrufen zu müssen.

7.2 Modelle

1export class ConditionalLink extends BaseLink {

3@IsEnum(LinkType)

4category = LinkType.CONDITIONAL;

6@ValidateNested()

7element: CaseElement;

Listing 7.6: ConditionalLink-Klasse

7.2.4 Elements

Jedes Objekt der in Auflistung 7.3 gezeigten Klasse besitzt ein standardisiertes Element,

welches in Listing 7.7 zu sehen ist. Ein Basiselement besitzt nur ein einziges Attribut,

den Titel. Der Title dient zur besseren Differenzierbarkeit für den Anwender.

1export abstract class BaseElement {

3@IsString()

4title: string;

Listing 7.7: BaseElement-Klasse

Ein

QuestionElement

, dessen Klasse in Auflistung 7.8 zu sehen ist, erweitert das

Basiselement um vier weitere Attribute. Das Attribut

type

definiert die Art des Elementes.

Diese redundante Art der Typisierung dient der eindeutigen Zuordnung des Elementes

bei einem Serialisierungsvorgang. Das Kennzeichen

required

stell fest, ob es sich

bei diesem Element um ein Pflichtelement handelt. Die

instruction

enthält mögliche

Anweisung die zur Beantwortung der Frage nötig sind. Durch die Verwendung des

I18n-Typs kann die Anweisung in beliebig vielen Sprachen verfasst werden. Das letzte

Merkmal result hält das typspezifische Ergebnis fest.

7 Ausgewählte Implementierungsaspekte

1export abstract class QuestionElement extends BaseElement {

3@IsEnum(QuestionType)

4abstract type: QuestionType;

6@IsBoolean()

7required = false;

9@IsI18n()

10 instruction: I18n = {};

12 abstract result;

14 }

Listing 7.8: QuestionElement-Klasse

Listing 7.9 zeigt eine spezifizierte

QuestionElement

Klasse. Die

FreeIntQuestion

wird zusätzlich zum Typ der Klasse durch das

type

Attribut definiert. Für die Datener-

hebung über ein Endgerät eines Benutzers besitz eine Instanz der Klasse

FreeInt-

Question

die Attribute:

unit

placeholder

min

und

max

. Das Attribut

unit

be-

stimmt die Einheit, in der ein Benutzereingabe gemacht werden soll. Ein Platzhalter wird

über das Attribut

placeholder

bestimmt. Sowohl

unit

, als auch

placeholder

ist

vom Typ

I18n

. Für das Anzeigen eines Platzhalters in der deutschen Sprache lautet

des Aufruf

new FreeIntQuestion.placeholder['de']

. Voraussetzung hierfür ist,

dass das benötigte Sprachpaket vorhanden ist.

7.3 Validierung

1export class FreeIntQuestion extends QuestionElement {

3@IsEnum(QuestionType)

4type = QuestionType.FREE_INT;

6@IsI18n()

7unit: I18n = {};

9@IsI18n()

10 placeholder: I18n = {};

12 @IsNumber()

13 min: number;

15 @IsGreaterOrEqual('min')

16 @IsNumber()

17 max: number;

19 @IsGreaterOrEqual('min')

20 @IsLessOrEqual('max')

21 @IsNumber()

22 @IsResult()

23 result: number;

25 }

Listing 7.9: FreeIntQuestion-Klasse

7.3 Validierung

In diesem Abschnitt soll der technische Aspekt der Validierung genauer erläutert werden.

Es wird gezeigt, wie die Logik der Validierung von den einzelnen Klassen getrennt werden

kann. Im Anschluss daran wir anhand eines Beispiels eine solche Validierungsfunktion

näher erklärt.

Das in Abschnitt 7.2.4 gezeigte Listing 7.9 besitzt für jedes Attribut der Klasse

FreeInt-

Question

mindestens einen

Decorator

, der in Abschnitt 7.1.3 näher erläutert wurden.

Auf diese Weise ist es möglich die Validierungslogik von den Eigenschaften einer Klasse

7 Ausgewählte Implementierungsaspekte

zu trennen. Der

Decorator IsGreaterOrEqual

in Zeile 15 besitzt die Fähigkeit

das Attribut

max

in Zeile 17 einer Instanz der Klasse

FreeIntQuestion

zur Laufzeit

zu überprüfen. In diesem Fall ist es möglich zu validieren, ob das dekorierte Attribut

gleichgroß oder größer als das übergebene Attribut min in Zeile 13 ist.

In Listing 7.10 ist die Logik eines

Decorators

in Form einer Funktion abgebildet.

Die Validierungsfunktion befindet sich in Zeile 5 und ist als Funktion an das Attribut

validator

des

Decorators

gebunden. Über den Aufruf in Zeile 7 wird der Wert des

zu vergleichenden Attributs referenziert. Im Anschluss daran werden beide Werte des

Attributes auf Vergleichskompatibilität geprüft und bei einem Treffer verglichen. Sollte es

sich um einen

string

handeln, so werden beider Werte in Zeile 9 hinsichtlich auf die

Länge des

strings

geprüft. Handel es sich um eine Zahl oder ein Datum, lautet der

Vergleichsoperator >=.

1export function IsGreaterOrEqual(...) {

2return (...) => {

3registerDecorator({

4...

5validator: {

6validate(value: any, args: ValidationArguments) {

7const ref = args.object[args.constraints[0]];

8if (typeof value === 'string' && typeof ref === 'string') {

9return value.length >= ref.length;

10 }else if (typeof value === 'number' && typeof ref === 'number' || value

instanceof Date && ref instanceof Date) {

11 return value >= ref;

12 }else {

13 return false;

14 }

15 },

16 ...

17 }

18 });

19 };

20 }

Listing 7.10: Größer-gleich Validierungsfunktion

7.4 Anwendungslogik

Die Brauchbarkeit der entworfenen Datenstruktur zur Abbildung medizinischer Instru-

mente lässt sich messen durch die Benutzbarkeit des Konfigurators. Dieser baut auf der

entworfenen Datenstruktur auf und gibt dem Benutzer die Möglichkeit die definierten

Elemente aus Tabelle 2.1 nach vorgegebenen Regeln zu kombinieren.

Um die Erweiterbarkeit der Datenstruktur in Bezug auf die Anwendung zu gewährleisten

wurden Operations eingeführt.

Operations

Eine

Operation

definiert was bei einer bestimmten Aktion mit den Elementen passie-

ren soll. Es kann zwischen vier Aktionen unterschieden werden, die auf ein Element

angewandt werden können. Ein Element kann hinzugefügt werden (

add

), es kann kopiert

werden (

copy

), es kann ausgeschnitten werden (

cut

) oder es kann gelöscht werden

(del).

In Listing 7.11 wird gezeigt wie die

AddQuestion

Operation

für ein

Question-

Element

-Objekt angemeldet werden kann. Wenn ein Benutzer ein Element auf einen

Link

bewegt wird die statische Methode

AddOperation.apply(e, obj)

aufgerufen.

Die Variable

diagram

in Zeile 5 referenziert das GoJS-Diagram in dessen Kontext die

Aktion ausgeführt wird. In Zeile 6 wird das Objekt bestimmt, in diesem Fall der

Link

, auf

den das Element, das in Zeile 7 bestimmt wird, geworfen wird. Im Anschluss daran wird

anhand des Typs des Elementes entschieden welche Datentyp spezifische

Operation

ausgeführt werden soll.

7 Ausgewählte Implementierungsaspekte

1export class AddOperation {

3public static apply(e, obj): void {

5const diagram = e.diagram;

6const link = obj.part;

7const node = diagram.selection.first();

9switch (node.category) {

11 case NodeType.QUESTION:

12 if (AddQuestion.canPerform(link)) {

13 AddQuestion.perform(diagram, link, node);

14 }else {

15 OperationException.cantPerfom();

16 }

17 break;

18 ...

19 }

20 }

21 }

Listing 7.11: AddOperation-Klasse

Die

Operations

, welche im Kontext dieser Arbeit in einer Klasse abgebildet wurden,

besitzt zwei statische Methoden. Die

canPerform

-Methode und die

perform

-Methode.

In Listing 7.12 soll exemplarisch erklärt werden, wie eine solche

Operation

aufgebaut

ist.

Die statische

canPerform

-Methode der Klasse

AddQuestion

in Zeile 3 bekommt als

Übergabeparameter den

Link

gegeben, auf den die

QuestionNode

geworfen werden

soll. Zur Überprüfung ob eine Aktion ausgeführt werden kann oder nicht, wird mithilfe

eines Switch-Case-Anweisung die Kategorie des

Links

überprüft. Im Falle des Listings

7.12 kann eine Aktion nur ausgeführt werden, wenn die Kategorie des

Links

vom Typ

LinkType.DATA

ist. Diese Art von

Link

kann nur inerhalb einer

Page

vorkommen und

gewährleistet somit die Validität des medizinischen Instrumentes.

Nach der Kontrolle der

canPerfom

-Methode wird, bei eine erfolgreichen Prüfung, die

perform

-Methode aufgerufen. Diese Methode benötigt drei Übergabeparameter. Das

7.4 Anwendungslogik

Diagramm, auf dem die Aktion ausgeführt werden soll, den Link, auf den das neue Objekt

geworfen wird und die Node, welche das zu werfende Objekt enthält. Die Funktion die

ein Einfügen der Node in den Link ermöglicht wird von einer Transaktion in Zeile 13

und 15 des Diagramms umschlossen. Eine solche Transaktion kann diesen Vorgang,

durch die Speicherung des vorherigen Zustandes, wieder rückgängig zu machen. Mit

dem Aufruf

insertNodeIntoLink(diagram, link, node, DataLink)

wird die

Node als Endpunkt des Links auf den geworfen wird festgelegt. Der ehemalige Endpunkt

wird ausgehend von der neuen Node mit einem Link der Klasse

DataLink

verbunden,

welcher vom Typ LinkType.DATA ist.

1export class AddQuestion {

3static canPerform(link): boolean {

4switch (link.data.category) {

5case LinkType.DATA:

6return true;

7default:

8return false;

10 }

12 static perform(diagram, link, node): boolean {

13 diagram.startTransaction(this.name);

14 insertNodeIntoLink(diagram, link, node, DataLink);

15 diagram.commitTransaction(this.name);

16 return true;

17 }

18 }

Listing 7.12: AddQuestion-Klasse

Diskussion

In diesem Kapitel geht es darum die entwickelte Struktur auf ihre Benutzbarkeit und

ihre Erweiterbarkeit zu testen. Auf diese Weise werden Vor- und Nachteile bei einem

praktischen Einsatz der Struktur deutlich.

Einen Beweis für die Erweiterbarkeit der Struktur wird anhand einer Erweiterung um

das

FreeTextareaQuestion

-Element geführt, das sowohl in die Struktur, als auch

in den Konfigurator eingebunden wird. Das Listing 8.1 zeigt die Struktur des neuen

FreeTextareaQuestion

-Elementes. Da es sich bei diesem Element um eine konkre-

tisiertes

QuestionElement

handelt, muss die Klasse von

QuestionElement

erben.

Dies geschieht in Zeile 1 durch den Befehl

extends QuestionElement

. Es wird

außerdem ein neuer Typ erzeugt, der dieses Element eindeutig bestimmt. In Zeile 4

wird der Typ der Klasse und jeder daraus erzeugten Instanz zugewiesen. Alle weiteren

Attribute beziehen sich auf die Eigenschaften des neuen Elementes. Zeile 7 weist dem

FreeTextaraeQuestion

-Element einen Platzhalter zu und gibt dem Benutzer die

Möglichkeit die Länge des Textes mit

minLength

und

maxLenght

einzuschränken. In

Zeile 22 kann das Ergebnis des Patienten festgehalten werden. Weitere Schritte sind

bei der Erweiterung der Datenstruktur nicht notwendig.

8 Diskussion

1export class FreeTextareaQuestion extends QuestionElement {

3@IsEnum(QuestionType)

4type = QuestionType.FREE_TEXT_AREA;

6@IsI18n()

7placeholder: I18n = {};

9@IsPositive()

10 @IsNumber()

11 minLength: number;

13 @IsGreaterOrEqual('minLength')

14 @IsPositive()

15 @IsNumber()

16 maxLength: number;

18 @IsGreaterOrEqual('minLength')

19 @IsLessOrEqual('maxLength')

20 @IsString()

21 @IsResult()

22 result: string;

24 }

Listing 8.1: FreeTextareaQuestion-Klasse

Um die Auswirkungen einer Erweiterung des Struktur auf mögliche Anwendungssys-

teme zu untersuchen, wird der in dieser Arbeit entstandene Konfigurator ebenfalls um

das

FreeTextareaQuestion

-Element erweitert. Die Abbildung 8.1 zeigt, dass eine

Anpassung der Anzeige der erweiterten Struktur in der Leiste der möglichen Elemente

und in der Graphenübersicht nicht notwendig ist. Bei der

FreeTextareaQuestion

handelt es sich um eine Unterklasse der

QuestionElements

, somit ist die grafische

Repräsentation bereits gegeben. Für eine Anpassung der grafischen Darstellung bedarf

es lediglich der Angabe eines neuen Typs und die Zuweisung einer neuen Farbe für eine

bessere Differenzierung.

Abbildung 8.1: Grafische Darstellung einer FreeTextareaQuestion

Damit dem Benutzer die Bearbeitung des Elementes ermöglicht werden kann muss ein

neue Formularmaske erstellt werden. Diese kann aus einigen bereits vordefinierten Ele-

menten zusammengebaut werden, wie Schieberegler, Eingabefelder für Daten, Zahlen

und Wörter. Nach dem Erzeugen einer Formularmaske muss diese an der Anwendung

angemeldet werden. Dafür wird zuerst eine Zuweisung an das neu Datenerfassungs-

element

FreeTextareaQuestion

vorgenommen und anschließend wird eine Liste

für alle Auswahlmöglichkeiten um die neue Formularmaske erweitert. Über ein Drop-

Down-Menü kann im Konfigurator das neu erstelle Element ausgewählt werden, wie das

Schaubild 8.2 zeigt.

8 Diskussion

Abbildung 8.2: Einbindung der FreeTextareaQuestion

In Abbildung 8.3 ist die Formularmaske für die

FreeTextareaQuestion

zu sehen.

Die drei ersten Eigenschaften

Title

Required

und

Instruction

sind Basiseigen-

schaften eines jeden Elementes, das von der Klasse

QuestionElement

erbt. Die

Eigenschaften

Placeholder

Min Length

und

Max Length

konnten ebenfalls von

der schon bestehenden Klasse FreeTextQuestion übernommen werden.

Abbildung 8.3: FreeTextareaQuestion Formularmaske

Dieser Vorgang zur Erweiterung der Elemente eines medizinischen Instrumentes hat

durch seine Einfachheit gezeigt, dass die Erweiterbarkeit der Struktur gegeben ist.

Jedoch benötigt es einen Fachexperten oder einen sehr technisch affinen Benutzer um

eine solche Anpassung vorzunehmen.

Zusammenfassung und Ausblick

In diesem Kapitel wird die Arbeit zusammenfassend noch einmal aufgeführt. Es werden

die wesentlichen Erkenntnisse und die Zielsetzung dieser Arbeit aufgegriffenen, um

einen Ausblick auf zukünftige Verwendungsmöglichkeiten zu geben.

Diese Arbeit hat sich mit der Entwicklung einer Struktur zur Abbildung von medizini-

schen Instrumenten auseinandergesetzt. Dafür wurden zuerst die Probleme, die in

vielen anderen Arbeiten aufgetreten sind, analysiert und relevante verwandte Arbeiten

näher betrachtet. Ziel dieser Arbeit ist es gewesen aus den gesammelten Erkennt-

nissen eine Struktur abzuleiten, die es ermöglicht eine medizinisches Instrument in

seiner Gesamtheit zu erfassen. In Folge dessen wurden Anforderungen definiert und der

Aufbau eines medizinischen Instrumentes systematisch Kategorisiert, um eine digital

Abbildung möglich zu machen. Es wurden relevante Stellen des Entwicklungsprozes-

ses eines medizinischen Instrumentes betrachtet, um eine konkrete Vorstellung des

Entwicklungsprozesses zu erlangen. Das Resultat dieser Arbeit ist eine Struktur zur

Abbildung von medizinischen Instrumenten. Es entstand darüber hinaus eine Konfi-

gurator, welcher es einem Benutzer ermöglicht ein solches Instrument im Sinne der

Endbenutzer-Entwicklung zu programmieren.

9.1 Ausblick

Wie aus dem dem Kapitel 8 hervorgeht sind die meisten Anforderungen in der Umset-

zung vollständig abgebildet worden. Jedoch stellte sich heraus, dass die Validierung des

Datenobjekts in den Bereichen der Sensoren einen größeren Umfang hat, als ursprüng-

lich angenommen wurde. Es war daher nicht möglich eine Schnittstelle zu definieren, die

9 Zusammenfassung und Ausblick

generisch einen Sensor für eine Datenerfassung einbindet. Es muss außerdem geklärt

werden wie Brauchbar die entwickelte Struktur und der daraus resultierende Konfigurator

ist. Hierfür könnte eine Studie, wie sie in der Arbeit [

] durchgeführt worden ist, von

großem Nutzen sein.

Die Konzeption und Entwicklung einer solchen Struktur lässt sich weiter mit einer au-

tomatisierten Auswertung der erfassten Daten koppeln, die der nächste Schritt bei der

Weiterführung des Projektes ist. Für eine große Flexibilität muss das System, welches

nach Vorgaben des Anwenders die Resultate einer Umfrage selektiert und grafisch

darstellt, als unabhängige Erweiterung entwickelt werden. Diese Erweiterung stellt nur

eine Möglichkeit dar, wie auf die entwickelte Struktur aufgebaut werden könnte. Als

eine weiter Anpassung der Struktur, die im Rahmen dieser Arbeit entstanden ist, könnte

die Einbindung und Analyse von sprach basierten Daten folgen. Aufgrund der typsi-

cheren Serialisierung der Struktur und der einfach gehaltenen Architektur bietet die

entstandenen Implementierung eine solide Grundlage für weitere Projekte.

Literaturverzeichnis

[1]

CDA-Body – Hl7wiki.

http://wiki.hl7.de/index.php?title=CDA-Body

Abruf: 10.03.2020

[2]

CDA-Header – Hl7wiki.

http://wiki.hl7.de/index.php?title=

CDA-Header, Abruf: 10.03.2020

[3]

CDA-Level – Hl7wiki.

http://wiki.hl7.de/index.php?title=CDA-Level

Abruf: 10.03.2020

[4]

class-validator.

https://github.com/typestack/class-validator

, Ab-

ruf: 29.02.2020

[5]

Data Structures Information Model.

https://specifications.openehr.

org/releases/RM/latest/data_structures.html, Abruf: 09.03.2020

[6]

Datatypes-examples - FHIR v4.0.1.

http://hl7.org/fhir/

datatypes-examples.html#Attachment, Abruf: 09.03.2020

[7]

Decorators.

https://www.typescriptlang.org/docs/handbook/

decorators.html, Abruf: 09.01.2020

[8]

Good Health Clinic Consultation Note.

https://www.w3.org/TR/

grddl-primer/hl7-sample.xml, Abruf: 10.03.2020

[9]

Introduction to GoJS Diagramming Components.

https://gojs.net/latest/

intro/index.html, Abruf: 29.02.2020

[10] Ionic Framework 5.https://ionicframework.com/, Abruf: 10.02.2020

[11]

openEHR Architecture Overview.

https://specifications.openehr.org/

Abruf: 09.03.2020

[12]

Questionnaire - FHIR v4.0.1.

https://www.hl7.org/fhir/questionnaire.

html, Abruf: 01.05.2020

Literaturverzeichnis

[13]

QuestionSys - A Generic and Flexible Questionnaire System Enabling Process-

Driven Mobile Data Collection.

https://www.uni-ulm.de/in/iui-dbis/

forschung/laufende-projekte/questionsys/, Abruf: 02.03.2020

[14]

ANHØJ, J. ; MØLDRUP, C. : Feasibility of Collecting Diary Data From Asthma

Patients Through Mobile Phones and SMS (Short Message Service): Response

Rate Analysis and Focus Group Evaluation From a Pilot Study. In: J Med Internet

Res 6 (2004), Dec, Nr. 4, e42.

http://dx.doi.org/10.2196/jmir.6.4.e42

– DOI 10.2196/jmir.6.4.e42. – ISSN 1438–8871

[15]

BENDER, D. ; SARTIPI, K. : HL7 FHIR: An Agile and RESTful approach to healthcare

information exchange. In: Proceedings of the 26th IEEE International Symposium

on Computer-Based Medical Systems, 2013. – ISSN 1063–7125, S. 326–331

[16]

BORDIN, M. ; VARDANEGA, T. : Correctness by Construction for High-Integrity

Real-Time Systems: A Metamodel-Driven Approach. In: ABDENNADHER, N. (Hrsg.)

; KORDON, F. (Hrsg.): Reliable Software Technologies – Ada Europe 2007. Berlin,

Heidelberg : Springer Berlin Heidelberg, 2007. – ISBN 978–3–540–73230–3, S.

114–127

[17]

DOLIN, R. H. ; ALSCHULER, L. ; BOYER, S. ; BEEBE, C. ; BEHLEN, F. M. ;

BIRON, P. V.

; SHABO (SHVO), A. : HL7 Clinical Document Architecture, Release 2. In: Journal

of the American Medical Informatics Association 13 (2006), 01, Nr. 1, 30-39.

http:

//dx.doi.org/10.1197/jamia.M1888

. – DOI 10.1197/jamia.M1888. – ISSN

1067–5027

[18]

FISCHER, G. ; GIACCARDI, E. ; YE, Y. ; SUTCLIFFE, A. G. ; MEHANDJIEV, N. : Meta-

Design: A Manifesto for End-User Development. In: Commun. ACM 47 (2004),

Sept., Nr. 9, 33–37.

http://dx.doi.org/10.1145/1015864.1015884

. –

DOI 10.1145/1015864.1015884. – ISSN 0001–0782

[19]

FORSTER, D. ; BEHRENS, R. H. ; CAMPBELL, H. ; BYASS, P. : Evaluation of a

computerized field data collection system for health surveys. In: Bulletin of the

World Health Organization 69 (1991), Nr. 1, 107-111.

https://pubmed.ncbi.

nlm.nih.gov/2054915. – ISSN 0042–9686. – 2054915[pmid]

Literaturverzeichnis

[20]

In: FREEMAN, A. : JavaScript and TypeScript: Part 1. Apress. – ISBN 978–1–4842–

3649–9, 63–85

[21]

GAGGIOLI, A. ; PIOGGIA, G. ; TARTARISCO, G. ; BALDUS, G. ; CORDA, D. ;

CIPRESSO, P.

; RIVA, G. : A mobile data collection platform for mental health

research. In: Personal and Ubiquitous Computing 17 (2013), Nr. 2, 241-251.

http:

//dx.doi.org/10.1007/s00779-011-0465-2

. – DOI 10.1007/s00779–011–

0465–2. – ISSN 1617–4917

[22]

GUNDLACH, H. : What is a psychological instrument? In: Psychology’s

Territories

Historical and Contemporary Perspectives from Different Disciplines (2012),

01, S. 195–224.

http://dx.doi.org/10.4324/9780203936658

. – DOI

10.4324/9780203936658

[23]

ISHIDA, R. ; W3C ; MILLER, S. K. ; BOEING:Lokalisierung vs.

Internationalisierung

https://www.w3.org/International/questions/

qa-i18n.de.html, Abruf: 13.02.2020

[24]

KEEDLE, H. ; SCHMIED, V. ; BURNS, E. ; DAHLEN, H. : The Design, Development,

and Evaluation of a Qualitative Data Collection Application for Pregnant Women. In:

Journal of Nursing Scholarship 50 (2018), Nr. 1, 47-55.

http://dx.doi.org/

10.1111/jnu.12344. – DOI 10.1111/jnu.12344

[25]

KRAFT, R. ; SCHLEE, W. ; STACH, M. ; REICHERT, M. ; LANGGUTH, B. ; BAUMEISTER,

H. ; PROBST, T. ; HANNEMANN, R. ; PRYSS, R. : Combining Mobile Crowdsensing

and Ecological Momentary Assessments in the Healthcare Domain. In: Frontiers

in Neuroscience 14 (2020), February, 164.

http://dbis.eprints.uni-ulm.

de/1879/

[26]

LESLIE, H. : International Developments in OpenEHR Archetypes and Templates. In:

Health Information Management Journal 37 (2008), Nr. 1, 38-39.

http://dx.doi.

org/10.1177/183335830803700104

. – DOI 10.1177/183335830803700104. –

PMID: 18245863

Literaturverzeichnis

[27]

LI, Y. ; MANOHARAN, S. : A performance comparison of SQL and NoSQL databases.

In: 2013 IEEE Pacific Rim Conference on Communications, Computers and Signal

Processing (PACRIM), 2013. – ISSN 1555–5798, S. 15–19

[28]

MYERS, B. A. ; KO, A. J. ; BURNETT, M. M.: Invited Research Overview: End-User

Programming. In: CHI ’06 Extended Abstracts on Human Factors in Computing

Systems. Association for Computing Machinery (CHI EA ’06). – ISBN 1595932984,

75–80

[29]

NURSEITOV, N. ; PAULSON, M. ; REYNOLDS, R. ; IZURIETA, C. : Comparison of

JSON and XML Data Interchange Formats: A Case Study. In: Caine 9 (2009), S.

157–162

[30]

O’GRADY, S. : The RedMonk Programming Language Rankings:

January 2020.

https://redmonk.com/sogrady/2020/02/28/

language-rankings-1-20/?utm_source=rss&utm_medium=rss&utm_

campaign=language-rankings-1-20, Abruf: 09.02.2020

[31]

PAVLOVI ´

C, I. ; KERN, T. ; MIKLAV ˇ

CI ˇ

C, D. : Comparison of paper-based

and electronic data collection process in clinical trials: Costs simulation

study

In: Contemporary Clinical Trials 30 (2009), Nr. 4, 300 - 316.

http://dx.

doi.org/https://doi.org/10.1016/j.cct.2009.03.008

. – DOI htt-

ps://doi.org/10.1016/j.cct.2009.03.008. – ISSN 1551–7144

[32]

PROBST, T. ; PRYSS, R. ; LANGGUTH, B. ; SPILIOPOULOU, M. ;

LANDGREBE

, M. ;

VESALA, M. ; HARRISON, S. ; SCHOBEL, J. ; REICHERT, M. ; STACH, M. ; SCHLEE,

W. : Outpatient Tinnitus Clinic, Self-Help Web Platform, or

Mobile

Application to

Recruit Tinnitus Study Samples? In: Frontiers in Aging

Neuroscience

9 (2017),

April, S. 113–113

[33]

SCAFFIDI, C. ; SHAW, M. ; MYERS, B. : Estimating the Numbers of End Users and

End User Programmers. In: 2005 IEEE Symposium on Visual Languages and

Human-Centric Computing (VL/HCC’05), 2005, S. 207–214

Literaturverzeichnis

[34]

SCHICKLER, M. ; SCHOBEL, J. ; PRYSS, R. ; REICHERT, M. : Mobile Crowd Sensing

? A New way of collecting data from trauma samples? In: XIV Conference of

European Society for Traumatic Stress Studies (ESTSS) Conference, 244

[35]

SCHOBEL, J. ; PRYSS, R. ; REICHERT, M. : Using Smart Mobile Devices for

Collecting Structured Data in Clinical Trials: Results from a Large-Scale Case Study.

In: 2015 IEEE 28th International Symposium on Computer-Based Medical Systems,

2015. – ISSN 1063–7125, S. 13–18

[36]

SCHOBEL, J. ; PRYSS, R. ; SCHICKLER, M. ; RUF-LEUSCHNER, M. ;

ELBERT, T.

; REICHERT, M. : End-User Programming of Mobile Services: Empowering

Domain

Experts to Implement Mobile Data Collection Applications. In: 2016 IEEE

International Conference

on Mobile Services (MS), 2016. – ISSN 2329–6453, S.

1–8

[37]

SCHOBEL, J. ; REICHERT, M. (Hrsg.) ; SCHLEE, W. (Hrsg.) ; PRYSS, R.

(Hrsg.): A Model-Driven Framework for Enabling Flexible and Robust Mobile

Data Collection Applications.

http://dbis.eprints.uni-ulm.de/1695/

Version: September 2018

[38]

SCHOBEL, J. ; PRYSS, R. ; PROBST, T. ; SCHLEE, W. ; SCHICKLER, M. ; REICHERT,

M. : Learnability of a Configurator Empowering End Users to Create Mobile Data

Collection Instruments: Usability Study. In: JMIR Mhealth Uhealth 6 (2018), Jun, Nr.

6, e148.

http://dx.doi.org/10.2196/mhealth.9826

. – DOI 10.2196/mhe-

alth.9826. – ISSN 2291–5222

[39]

SCHOBEL, J. ; PRYSS, R. ; SCHICKLER, M. ; REICHERT, M. : A Configurator

Component for End-User Defined Mobile Data Collection Processes. In: DRIRA,

K. (Hrsg.) ; WANG, H. (Hrsg.) ; YU, Q. (Hrsg.) ; WANG, Y. (Hrsg.) ; YAN, Y. (Hrsg.)

; CHAROY, F. (Hrsg.) ; MENDLING, J. (Hrsg.) ; MOHAMED, M. (Hrsg.) ; WANG, Z.

(Hrsg.) ; BHIRI, S. (Hrsg.): Service-Oriented Computing – ICSOC 2016 Workshops.

Cham : Springer International Publishing, 2017. – ISBN 978–3–319–68136–8, S.

216–219

Literaturverzeichnis

[40]

SCHOBEL, J. ; PRYSS, R. ; SCHICKLER, M. ; REICHERT, M. : Process-Driven Mobile

Data Collection (Extended Abstract). In: 8th International Workshop on Enterprise

Modeling and Information Systems Architectures (EMISA 2017)

[41]

SCHOBEL, J. ; PRYSS, R. ; SCHLEE, W. ; PROBST, T. ; GEBHARDT, D. ; SCHICKLER,

M. ; REICHERT, M. : Development of Mobile Data Collection Applications by Domain

Experts: Experimental Results from a Usability Study. In: DUBOIS, E. (Hrsg.) ;

POHL, K. (Hrsg.): Advanced Information Systems Engineering. Cham : Springer

International Publishing, 2017. – ISBN 978–3–319–59536–8, S. 60–75

[42]

SCHOBEL, J. ; PRYSS, R. ; WIPP, W. ; SCHICKLER, M. ; REICHERT, M. : A Mobile

Service Engine Enabling Complex Data Collection Applications. In: SHENG, Q. Z.

(Hrsg.) ; STROULIA, E. (Hrsg.) ; TATA, S. (Hrsg.) ; BHIRI, S. (Hrsg.): Service-Oriented

Computing. Cham : Springer International Publishing, 2016. – ISBN 978–3–319–

46295–0, S. 626–633

[43]

SCHOBEL, J. ; SCHICKLER, M. ; PRYSS, R. ; MAIER, F. ; REICHERT, M. : Towards

Process-Driven Mobile Data Collection Applications: Requirements, Challenges,

Lessons Learned. In: 10th Int’l Conference on Web Information Systems and

Technologies (WEBIST 2014), Special Session on Business Apps, 371–382

[44]

SCHOBEL, J. ; SCHICKLER, M. ; PRYSS, R. ; NIENHAUS, H. ; REICHERT, M. : Using

Vital Sensors in Mobile Healthcare Business Applications: Challenges,

Examples

Lessons Learned. In: 9th Int’l Conference on Web Information Systems and

Technologies (WEBIST 2013), Special Session on Business Apps, 509–518

[45]

SCHOBEL, J. ; SCHICKLER, M. ; PRYSS, R. ; REICHERT, M. : Process-Driven Data

Collection with Smart Mobile Devices. In: MONFORT, V. (Hrsg.) ; KREMPELS, K.-H.

(Hrsg.): Web Information Systems and Technologies. Cham : Springer International

Publishing, 2015. – ISBN 978–3–319–27030–2, S. 347–362

[46]

SCHOBEL, J. ; SCHICKLER, M. ; PRYSS, R. ; REICHERT, M. ; ELBERT, T. : A Domain-

Specific Framework for Collecting Data in Trials with Smart Mobile Devices. In: XIV

Conference of European Society for Traumatic Stress Studies (ESTSS) Conference

Literaturverzeichnis

[47]

TAYLOR, K. ; SILVER, L. : Smartphone Ownership Is Growing Rapidly Around the

World, but Not Always Equally. In: Pew Research Center (2019)

[48] WATERS, K. : Prioritization using moscow. In: Agile Planning 12 (2009), S. 31

A Anhang

Anhang

1<component>

2<section>

3<code code="11384-5" codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC"/>

4<title>Physical Examination</title>

5<component>

6<section>

7<code code="8716-3" codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC"/>

8<title>Vital Signs</title>

9<text>

10 <table>

11 <tr>

12 <th>Date / Time</th>

13 <th>April 7, 2000 14:30</th>

14 <th>April 7, 2000 15:30</th>

15 </tr>

16 <tr>

17 <th>Height</th>

18 <td>177 cm (69.7 in)</td>

19 </table>

20 </text>

21 <entry>

22 <Observation>

23 <code code="50373000" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT" displayName="Body height

measure"/>

24 <effectiveTime value="200004071430"/>

25 <value xsi:type="PQ" value="1.77" unit="m">

26 <translation value="69.7" code="[in_I]" codeSystem="

2.16.840.1.113883.6.8" codeSystemName="UCUM"/>

27 </value>

28 </Observation>

29 </entry>

30 </section>

31 </component>

32 </section>

33 </component>

Listing A.1: Ausschnitt CDA Patientendaten [8]

NodeType

COMMENT

CUSTOM

EVENT

HEADLINE

MEDIA

QUESTION

RECEIVER

SENSOR

TEXT

TRANSMITTER

BaseNode

key : Identiﬁer

group : Identiﬁer

element : BaseElement

CommentNode

category : NodeType.COMMENT

text : string

CustomNode

category : NodeType.CUSTOM

element : CustomElement

EventNode

category : NodeType.EVENT

element : EventElement

HeadlineNode

category : NodeType.HEADLINE

element : HeadlineElement

MediaNode

category : NodeType.MEDIA

element : MediaElement

QuestionNode

category : NodeType.QUESTION

element : QuestionElement

ReceiverNode

category : NodeType.RECEIVER

type : GatewayType

SensorNode

category : NodeType.SENSOR

element : SensorElement

TextNode

category : NodeType.TEXT

element : TextElement

TransmitterNode

category : NodeType.TRANSMITTER

type : GatewayType

element : ConditionElement

Identiﬁer

BaseElement

CustomElement

EventElement

HeadlineElement

MediaElement

QuestionElement

GatewayType

SensorElement

TextElement

ConditionElement

Abbildung A.1: Nodes Pseudo-UML-Klassendiagramm

A Anhang

I18n

BaseElement

title : string

CaseElement

case : Case

ConditionElement

condition : Condition

reference : Reference

CustomElement

type : CustomType

conﬁguration : Conﬁg

content : string

EventElement

action : Action

GroupElement

HeadlineElement

headline : I18n

MediaElement

caption : I18n

instruction : I18n

mediaId : string

QuestionElement

type : QuestionType

required : boolean

instruction : I18n

result : any

SensorElement

sensor : Sensor

conﬁg : SensorConﬁg

label : string

TextElement

headline : I18n

text : I18n

Case

Condition

Reference

CustomType

Conﬁg

Action

QuestionType

Sensor

SensorConﬁg

Abbildung A.2: Elements Pseudo-UML-Klassendiagramm

QuestionType

FREE_DATE

FREE_FLOAT

FREE_INT

FREE_TEXT_AREA

FREE_TEXT

MATRIX

I18n

Item

key : Identiﬁer

value : I18n

FreeDateQuestion

type : QuestionType.FREE_DATE

placeholder : I18n

minDate : Date

maxDate : Date

result : Date

QuestionElement

FreeFloatQuestion

type : QuestionType.FREE_FLOAT

unit : I18n

placeholder : I18n

min : number

max : number

result : number

FreeIntQuestion

type : QuestionType.FREE_INT

unit : I18n

placeholder : I18n

min : number

max : number

result : number

FreeTextareaQuestion

type : QuestionType.FREE_TEXT_AREA

placeholder : I18n

minLength : number

maxLength : number

result : string

FreeTextQuestion

type : QuestionType.FREE_TEXT

placeholder : I18n

minLength : number

maxLength : number

result : string

ResultMatrixItem

columnKey : Identiﬁer

rowKey : Identiﬁer

value : I18n

MatrixQuestion

type : QuestionType.MATRIX

columns : Array<Item>

rows : Array<Item>

result : Array<ResultMatrixItem>

Identiﬁer

Date

Array

Abbildung A.3: Question-Elements Pseudo-UML-Klassendiagramm

A Anhang

QuestionType

BUTTON_GRID

DISTRIBUTION

DROP_DOWN

LIKE_RT_IMAGE

LIKE_RT

MULTIPLE_CHOICE

RANKING

SINGLE_CHOICE

YES_NO

I18n

Item

key : Identiﬁer

value : I18n

AbstractItem

items : Array<Item>

QuestionElement

ButtongridQuestion

type : QuestionType.BUTTON_GRID

result : Array<Item>

DistributionQuestion

type : QuestionType.DISTRIBUTION

points : number

result : Array<Item>

DropdownQuestion

type : QuestionType.DROP_DOWN

placeholder : I18n

result : Array<Item>

LikertImageQuestion

type : QuestionType.LIKE_RT_IMAGE

result : Array<Item>

LikertQuestion

type : QuestionType.LIKE_RT

result : Array<Item>

MultipleChoiceQuestion

type : QuestionType.MULTIPLE_CHOICE

result : Array<Item>

RankingQuestion

type : QuestionType.RANKING

result : Array<Item>

SingleChoiceQuestion

type : QuestionType.SINGLE_CHOICE

result : Identiﬁer

YesNoQuestion

type : QuestionType.YES_NO

result : Array<Item>

Identiﬁer

Array

Abbildung A.4: Item-Question-Elements Pseudo-UML-Klassendiagramm

Abbildungsverzeichnis

3.1 FHIR Datentypen [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 openEHR Überblick [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Beispiel Datenstruktur einer Gewichtsmessung [5] . . . . . . . . . . . . . 14

3.4 QuestionSys Projekt-Übersicht [13] . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Erstellungsvorgang eines medizinischen Instrumentes . . . . . . . . . . . 18

4.2

Schematische Darstellung des digitalen Fragebogens aus Sicht des Pati-

enten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 QuestionSys Server API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4 RedMonk Q120 Programming Language Rankings [30] . . . . . . . . . . 21

6.1 Formale Grammatik eines Questionnaires . . . . . . . . . . . . . . . . . . 32

6.2 Formale Grammatik der Groups . . . . . . . . . . . . . . . . . . . . . . . 32

6.3 Formale Grammatik der Nodes . . . . . . . . . . . . . . . . . . . . . . . . 33

6.4 Relationsschaubild der Strukturelemente [25] . . . . . . . . . . . . . . . . 34

6.5 Questionnaire Pseudo-UML-Klassendiagramm . . . . . . . . . . . . . . . 35

6.6 Links Pseudo-UML-Klassendiagramm . . . . . . . . . . . . . . . . . . . . 36

6.7 Fragebogenablauf bezüglich des Suchtverhaltens eines Probanden . . . 38

6.8 Groups Pseudo-UML-Klassendiagramm . . . . . . . . . . . . . . . . . . . 39

6.9 Slider-Question-Elements Pseudo-UML-Klassendiagramm . . . . . . . . 42

6.10 Image-Question-Elements Pseudo-UML-Klassendiagramm . . . . . . . . 43

6.11 Grafische Oberfläche des Konfigurators . . . . . . . . . . . . . . . . . . . 44

7.1 Projektstruktur bei einem komponentenbasierten Ansatz . . . . . . . . . . 48

8.1 Grafische Darstellung einer FreeTextareaQuestion . . . . . . . . . . 65

8.2 Einbindung der FreeTextareaQuestion . . . . . . . . . . . . . . . . . 66

8.3 FreeTextareaQuestion Formularmaske . . . . . . . . . . . . . . . . . 67

A.1 Nodes Pseudo-UML-Klassendiagramm . . . . . . . . . . . . . . . . . . . 81

A.2 Elements Pseudo-UML-Klassendiagramm . . . . . . . . . . . . . . . . . . 82

Abbildungsverzeichnis

A.3 Question-Elements Pseudo-UML-Klassendiagramm . . . . . . . . . . . . 83

A.4 Item-Question-Elements Pseudo-UML-Klassendiagramm . . . . . . . . . 84

Tabellenverzeichnis

2.1

Gliederung der Struktur-, Ereignis-, Beschreibungs- und Datenerfassungs-

elementen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 CDA-Struktur [1, 2, 3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.1 Allgemeine funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . 27

5.2 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.3 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 30

Name: Maximilian Scheurich Matrikelnummer: 857517

Erklärung

Ich erkläre, dass ich die Arbeit selbstständig verfasst und keine anderen als die angege-

benen Quellen und Hilfsmittel verwendet habe.

Ulm, den ...... .. ..... .. ..... .. ....... .. ..... .. ....... .. ..... .. ..... .. ....... .. ..... ..

Maximilian Scheurich