Patientennahe Herzschrittmacher-Nachsorge

ALEXANDER KOLLMANN
Patientennahe
Herzschrittmacher-Nachsorge
DIPLOMARBEIT
TECHNISCHE UNIVERSITÄT GRAZ
Institut für Elektro- und Biomedizinische Technik
Infeldgasse 16a, A-8010 Graz
Vorstand: Univ.-Prof. DI. Dr. techn. Gert Pfurtscheller
Betreuer: DI Peter Kastner, ARC Seibersdorf resarch GmbH
Begutachter: Ao. Univ.-Prof. DI. Dr. techn. Zlatko Trajanoski
Graz, Dezember 2002
Diese Arbeit wurde bei der
ARC Seibersdorf research GmbH - Standort Graz
Biosignalverarbeitung und Telemonitoring
durchgeführt.
Für meine Eltern
Danksagung
An dieser Stelle möchte ich mich bei allen recht herzlich bedanken, die mir bei der
Entwicklung dieser Diplomarbeit mit Rat und Tat zur Seite gestanden sind.
Danken möchte ich allen Ärzten der klinischen Abteilung für Kardiologie, Medizinische Universitätsklinik Graz, besonders OA Dr. Brigitte Rotman und dem gesamten
Betreuerteam“ der ARC Seibersdorf research GmbH - Standort Graz für die her”
vorragende Zusammenarbeit und Unterstützung.
Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Graz, Dezember 2002
Kurzfassung
Die Einbindung des Internets als Kommunikationsmedium wird in Zukunft einen
immer größeren Stellenwert in der medizinischen Versorgung der Bevölkerung einnehmen.
In dieser Diplomarbeit wird ein prototypisches System zur Patientennahen Herz”
schrittmacher (HSM) Nachsorge“ vorgestellt, das als Web-Service realisiert wurde.
Das Internet stellt in diesem Fall die Kommunikationsplattform zwischen Niedergelassenen Arzt, der HSM-Ambulanz und der Monitoring-Zentrale her. Durch automatische Analyse einer EKG-Sequenz mit temporären Magneteﬀekt ist es möglich,
die bis zu vier mal jährlich vorgeschriebene Basisnachsorge von HSM-Patienten vom
Niedergelassenem Arzt durchführen zu lassen. Daraus folgt eine wesentliche Entlastung der HSM-Ambulanzen und der mehrheitlich älteren Patienten, die sich den
Transport in die Klinik ersparen.
Die Diplomarbeit stellt den strukturellen Aufbau des Systems, des Web-Servers, der
Datenbank und der Signalanalyseeinheit vor.
Eine erste klinische Vergleichsstudie an 36 Patienten hat das erwartete Potential
der Patientennahen HSM-Nachsorge bestätigt. Es konnte gezeigt werden, dass in
rund 80 % der Fälle eine Basisnachsorgeuntersuchung beim Niedergelassenen Arzt
ausreichend wäre, um die Bertriebssicherheit und volle Funktionalität des HSM zu
garantieren.
Schlüsselwörter: Herzschrittmacher, Nachsorgeuntersuchung, Telemedizin, EKG
Abstract
The use of the Web for medical application areas seems to be an attractive solution
for many problems. Nowadays the Web becomes a standardized infrastructure for
giving access to advanced telemedicine applications. Such web services provide accessibility and usability advantages for patients and physician.
This diploma theses presents a prototype for a basic pacemaker follow-up system
as a collaborative telemedicine application between the primary care physician, the
cardiologist at the hospital and the remote follow-up centre. It presents the general
architectural and technical issues of the web server, the database and the signal
processing unit.
A ﬁrst clinical pilot trial has been performed which conﬁrms the expected potential
of the system. The evaluation of 36 examinations indicates that in approximately
80 % of cases a hospital visit of the patients would not have been necessary. The
basic follow-up could have been performed by the primary care physician to assure
the functionality and reliability of the pacemaker.
Keywords: Pacemaker, Follow-up, Telemedicine, ECG
5
Inhaltsverzeichnis
1 Einleitung
1.1
1.2
1
Allgemeines zum Herzschrittmacher . . . . . . . . . . . . . . . . . . .
1
1.1.1
2
Herzschrittmacher und Zubehör . . . . . . . . . . . . . . . . .
Herzschrittmacher Nachsorge
. . . . . . . . . . . . . . . . . . . . . .
3
Herzschrittmacher Basisnachsorge . . . . . . . . . . . . . . . .
3
1.3
Telemedizin als Chance . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4
Gesundheitspolitische Aspekte . . . . . . . . . . . . . . . . . . . . . .
6
1.5
Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.6
Recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.6.1
PC-EKG Systeme . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.6.2
Bestehende HSM-Nachsorge Systeme . . . . . . . . . . . . . .
9
1.2.1
2 Methoden
12
2.1
Klinisches Umfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2
Ablauf der HSM-Nachsorge . . . . . . . . . . . . . . . . . . . . . . . 13
2.3
2.4
2.2.1
Ambulante HSM-Nachsorge . . . . . . . . . . . . . . . . . . . 14
2.2.2
Patientennahe HSM-Nachsorge . . . . . . . . . . . . . . . . . 15
Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Relationale Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.1
SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
i
INHALTSVERZEICHNIS
2.4.2
INHALTSVERZEICHNIS
Datenbankentwurf . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5
Web-Server / Web-Design . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6
Signalanalyseeinheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 Ergebnisse
37
3.1
Workﬂow-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2
Datenbankdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3
3.2.1
Datenbankdesignaspekte . . . . . . . . . . . . . . . . . . . . . 39
3.2.2
Persons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.3
Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.4
Pacemaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.5
Datenbankzusatzfunktionen . . . . . . . . . . . . . . . . . . . 47
Klinische Studien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1
Klinische Vorstudie - Mai 2002 . . . . . . . . . . . . . . . . . 50
3.3.2
Klinische Vergleichsstudie - November 2002
3.3.3
Statistische Auswertung . . . . . . . . . . . . . . . . . . . . . 51
. . . . . . . . . . 50
4 Diskussion
53
5 Ausblick
55
Literatur
56
Index
59
ii
Abbildungsverzeichnis
1.1
HSM und Elektroden der Firma Medtronic . . . . . . . . . . . . . . .
3
1.2
EKG mit Magnet-Eﬀekt: S. . . Spontane Stimulation, P. . . Magnetfrequenz
A. . . Beginn der Magnetauﬂage, B. . . Beginn der Magnetfrequenz . . . 5
1.3
Anfahrtswege der Patienten zur HSM-Ambulanz . . . . . . . . . . . .
1.4
EKG Übertragung mittels Telefonadapter
2.1
HSM-Programmer der Firma Medtronic . . . . . . . . . . . . . . . . 12
2.2
Ablauf der ambulanten HSM-Nachsorgeuntersuchung . . . . . . . . . 14
2.3
Patientennahe HSM-Nachsorgeuntersuchung . . . . . . . . . . . . . . 16
2.4
Benutzeroberﬂäche Cardio Control Workstation . . . . . . . . . . . . 19
2.5
EasySoft ODBC-Interbase DriverIB6 . . . . . . . . . . . . . . . . . . 22
2.6
Konzeptioneller Datenbank-Entwurf . . . . . . . . . . . . . . . . . . . 26
2.7
Skizziertes ER-Modell der PERSONS Datenbank . . . . . . . . . . . 31
2.8
Benutzeroberﬂäche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.9
Flussdiagramm der Signalanalyseeinheit . . . . . . . . . . . . . . . . 34
7
. . . . . . . . . . . . . . . 10
2.10 Verlauf der Magnetfrequenz - Medtronic Kappa D700 . . . . . . . . . 35
2.11 Verlauf der Magnetfrequenz - St. Jude Medical Integrity DR 5346 . . 35
3.1
Ergebnis der Workﬂow-Analyse der Patientennahen HSM-Nachsorge . 38
3.2
Datenbanksystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3
Personenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4
Kombination aus Web-Server-Security und Datenbank-Security . . . . 41
3.5
Struktur der Signal-Datenbank . . . . . . . . . . . . . . . . . . . . . 43
iii
ABBILDUNGSVERZEICHNIS
ABBILDUNGSVERZEICHNIS
3.6
Organisation der Daten im Dateisystem des Servers . . . . . . . . . . 44
3.7
Blockdiagramm: Report . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8
Analysiertes EKG mit Kennzeichnung der maximalen Korrelation . . 46
3.9
Auszug aus der HSM-Datenbank . . . . . . . . . . . . . . . . . . . . 47
3.10 Log-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.11 Log-Tabelle der aufgerufenen Seiten . . . . . . . . . . . . . . . . . . . 49
3.12 Papierkorbfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
iv
Tabellenverzeichnis
1.1
HSM-Statistik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
HSM Erstimplantationen in der Steiermark . . . . . . . . . . . . . . .
2
2.1
Lösch-, Einfüge- und Änderungsanomalien . . . . . . . . . . . . . . . 27
2.2
Auszug aus der Persons-Datenbank . . . . . . . . . . . . . . . . . . . 28
2.3
Auszug aus der Tabelle Patient . . . . . . . . . . . . . . . . . . . . . 28
2.4
Auszug aus der Tabelle APP . . . . . . . . . . . . . . . . . . . . . . . 28
2.5
Zuordnungstabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6
Mustertabelle zur Veranschaulichung der Notwendigkeit des dritten
Normalisierungsschrittes . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.7
Normalisierte Tabelle PAT HSM . . . . . . . . . . . . . . . . . . . . . 29
2.8
Abgespaltete Tabelle HSM . . . . . . . . . . . . . . . . . . . . . . . . 30
2.9
Kardinalitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.10 Magnetstring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1
Anfallende Dateitypen . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2
Regeln zur Beurteilung des Ladezustandes der Batterie anhand der
berechneten Korrelationskoeﬃzienten . . . . . . . . . . . . . . . . . . 50
3.3
Untersuchte HSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4
Vergleich der Ergebnisse zwischen HSM-Programmiergerät und Patientennaher HSM-Nachsorge . . . . . . . . . . . . . . . . . . . . . . . 51
3.5
Vierfeldertafel zum diagnostischen Test der Vergleichsstudie . . . . . 51
v
Kapitel 1
Einleitung
Die Diplomarbeit Patientennahe Herzschrittmacher-Nachsorge“ wurde in Zusam”
menarbeit mit der klinischen Abteilung für Kardiologie, Medizinische Universitätsklinik Graz (Herzschrittmacher Ambulanz) und der Firma ARC Seibersdorf research
GmbH durchgeführt. Das prototypisch neu entwickelte System ist Teil des CardioMemory-Systems, das zur Zeit drei telemedizinische Anwendungen vereint.
• Patientennahe Herzschrittmacher-Nachsorge
• Paroxysmales atriales Flimmern (PAF) Risiko-Management
• Pilotprojekt zur Heimüberwachung wichtiger Herz - Kreislauf Parameter
Durch die modulare Gestaltung soll es in Zukunft möglich sein, weitere Anwendungen in dieses System zu integrieren.
1.1
Allgemeines zum Herzschrittmacher
Die normale mechanische Kontraktion des Herzmuskels wird durch die autonome
und regelmäßig wiederkehrende elektrische Stimulation der Muskelzellen initiiert.
Ist das Reizleitungssystem intakt, wird der elektrische Impuls ausgehend vom Sinusknoten über die Vorhöfe zum AV-Knoten und weiter über das His’sche Bündel
und die Tawara-Schenkel sowie die Purkinjefasern bis in die Herzmuskelzellen der
Herzkammern geleitet. Abweichungen von dieser Erregungsausbreitung lassen sich
in Störungen der Reizbildung und der Reizleitung unterteilen. Bei einer Reihe von
kardialen Erkrankungen ist die Therapie mit einem temporären oder permanenten
Herzschrittmacher (HSM) erforderlich [19]. Welche große Bedeutung HSM in der
Therapie bestimmter Herzerkrankungen besitzen, zeigt sich nicht zuletzt in der Tatsache, dass allein in Österreich pro Jahr rund 4500 HSM implantiert werden. Durch
1
1.1. ALLGEMEINES ZUM HERZSCHRITTMACHER
1. Einleitung
die rasche Weiterentwicklung der HSM-Technologie und der daraus folgenden erweiterten Einsetzbarkeit, sowie durch die zunehmende Veralterung der Bevölkerung
und dem damit verbundenen Anstieg von Herz-Kreislauferkrankungen, ist eine stark
steigende Anzahl von Implantationen zu erwarten [2], [47], [48]. Die Tabellen 1.2 und
1.1 zeigen einen Überblick über die Anzahl der Erstimplantationen im deutschsprachigen Raum.
Neuimplantationen / Jahr
Austausch
HSM-Patienten
Österreich
4500
900
30000
Deutschland
27000
7500
210000
Schweiz
3000
700
21000
Tabelle 1.1: HSM-Statistik
Jahr
Implantationen
1994
662
1995
547
1996
529
1997
589
1998
666
1999
658
2000
707
Tabelle 1.2: HSM Erstimplantationen in der Steiermark
1.1.1
Herzschrittmacher und Zubehör
Die modernen HSM-Typen sind, im Verhältnis zu früheren Geräten, sehr klein und
langlebig (Abbildung 1.1). Ihre Länge und Breite betragen ca. 4-5 cm bei einer Dicke
von ungefähr 7 mm. Das Gewicht eines Schrittmachers beträgt zwischen 20 und 27
Gramm.
Die wichtigsten Bestandteile eines HSM sind neben der Steuerelektronik, die Telemetrieeinrichtung und die Batterie. Nach außen ist nur die Anschlussvorrichtung für
die Elektroden sichtbar. Das Gehäuse besteht aus Titan um Abstoßungsreaktionen
zu vermeiden. Ein besonderes Augenmerk ist auf die Batterie zu legen. Sie bestimmt
nicht nur die Größe des HSM (ca. 60 %) sondern legt auch im Wesentlichen die
Lebensdauer des HSM fest.
Elektroden gibt es entsprechend der medizinischen Indikationen in vielfältigen Ausführungen. Sie besitzen einen Durchmesser von rund 2 mm. Eine Schicht aus nicht
leitendem Silikon sorgt nicht nur für die wichtige Isolation, sondern erleichtert auch
das Einführen der Elektroden durch die Vene bei der Implantation.
Die elektrisch leitfähigen Elektrodenspitzen bestehen meist aus Platin. Die Verankerung erfolgt aktiv durch Schraubelektroden oder passiv durch Ankerelektroden.
Schraubelektroden, deren Spitze einem Korkenzieher ähnelt, werden in den Herzmuskel gedreht. Ankerelektroden verhaken sich im Endokard und werden durch Widerhaken festgehalten.
2
1.2. HERZSCHRITTMACHER NACHSORGE
1. Einleitung
Abbildung 1.1: HSM und Elektroden der Firma Medtronic
1.2
Herzschrittmacher Nachsorge
Regelmäßige Nachsorgeuntersuchungen [16],[28],[1] sind bei jedem HSM-System notwendig. Dabei wird neben der funktionellen Kontrolle des HSM insbesondere der
Ladezustand der Batterie überprüft. Als Energiequelle kommen in den implantierten HSM-Typen modernste Litium-Ionen-Batterien zum Einsatz. Durch die Weiterentwicklung der Batterietechnologie wird von den Herstellern je nach Modell eine
Betriebsdauer von 5 - 10 Jahren prognostiziert. Da die Erschöpfung der Batterie
von der tatsächlichen Aktivität des HSM abhängig ist, ist eine regelmäßige Kontrolle des Batteriezustandes unerlässlich. Das Kontrollintervall sinkt mit zunehmender
Implantationsdauer von anfangs zwölf Monaten auf sechs und schließlich auf ein bis
drei Monate.
Moderne HSM können via Telemetrie wichtige Stimulationsparameter wie Elektrodenimpedanz, Reizschwelle und den Ladezustand der Batterie übertragen, wodurch
eine Prognose über die verbleibende Lebensdauer des HSM erstellt werden kann.
Falls notwendig kann der HSM umprogrammiert werden, um den speziellen Bedürfnissen jedes Patienten noch besser entsprechen zu können. Diese Programmierung
wird nicht invasiv mit einem speziellen, herstellerspeziﬁschen HSM-Programmiergerät
ohne eine erneute Operation durchgeführt.
1.2.1
Herzschrittmacher Basisnachsorge
Ab dem zweiten Implantationsjahr ist in den meisten Fällen keine Umprogrammierung des HSM notwendig, sondern nur die Überprüfung des Ladezustandes der Batterie. Diese HSM-Basisnachsorge“ besteht im Wesentlichen aus der Interpretation
”
einer kurzen EKG Sequenz, die während des so genannten Magnettest“ [32],[7],[45]
”
aufgezeichnet wird.
Durch die Auﬂage eines Dauermagneten schaltet sich der HSM in den Magnet-Mode.
3
1.2. HERZSCHRITTMACHER NACHSORGE
1. Einleitung
Dieser wird durch eine Magnetstimulationsfrequenz , die sog. Magnetfrequenz charakterisiert. Diese Frequenz kann aus dem EKG abgelesen und ausgewertet werden.
Jeder HSM hat eine besondere Magnet Charakteristik“ , das heißt: Abhängig von
”
der abgelesenen Magnetfrequenz kann auf den Batteriezustand geschlossen werden.
Folgende Ladezustände der Batterie werden unterschieden:
• BOL (Begin of Life):
Nach der Implantation ist noch die volle Batteriekapazität vorhanden. Abhängig von den programmierten Parametern und der Aktivität des Herzschrittmachers wird sich die Batteriekapazität im Laufe der Implantationsdauer verringern.
• ERI (Elective Replacement Indication):
Nach Erreichen dieser Schwelle garantiert der Hersteller noch volle Funktionsfähigkeit für ein gewisses Zeitintervall [32]. Aus Energiespargründen werden
Sonderfunktionen, wie Statistikfunktionen deaktiviert. Diese stehen aber in
keinem direkten Zusammenhang mit der Funktionalität des HSM. Ab diesem
Zeitpunkt entscheidet der zuständige Kardiologe, ob der HSM auszutauschen
ist, oder das Nachsorgeintervall zu verkürzen ist. Üblicherweise wird der HSM
bei Erreichen dieser Schwelle ausgetauscht um maximale Sicherheit für den
Patienten zu garantieren.
• EOL (End of Life):
Spätestens nach Erreichen dieser Schwelle muss der HSM ausgetauscht werden, da die volle Funktionsfähigkeit nicht mehr garantiert werden kann. Es
werden vom Hersteller die Hauptfunktionen für eine deﬁnierte Zeit gewährleistet, indem der HSM in einem sicheren, energiesparenden Mode betrieben wird.
Spezielle Sonder- bzw. Zusatzfunktionen werden aber aus Energiespargründen
automatisch deaktiviert.
Abbildung 1.2 zeigt eine EKG Sequenz während des Magnettests. In diesem Fall handelt es sich um einen HSM der Firma Medtronic (Modell Kappa“). Die Wirkung des
”
Magneten auf den HSM, und somit die Umschaltung in den Magnet Mode beginnt
im Punkt A. Es erfolgen nun drei Stimulationen mit einer Frequenz von 100 min−1 ,
als Indikator für den Beginn der Magnetauﬂage, gefolgt von Stimulationen mit der
Magnetfrequenz (Punkt B; 85 min−1 ). Diese Frequenz ist direkt vom Ladezustand
der Batterie abhängig und repräsentiert in diesem Beispiel den Batteriestatus BOL.
In dieser Diplomarbeit soll eine neue Methode für die HSM-Basisnachsorge“ ent”
wickelt werden, die eine Arbeitsteilung zwischen Niedergelassenem Arzt, der das
4
1.2. HERZSCHRITTMACHER NACHSORGE
A
1. Einleitung
MAGNETEFFEKT
B
Abbildung 1.2: EKG mit Magnet-Eﬀekt: S. . . Spontane Stimulation,
P. . . Magnetfrequenz A. . . Beginn der Magnetauﬂage, B. . . Beginn der Magnetfrequenz
EKG aufzeichnet und dem Kardiologen (Befundung) zum Ziel hat. Die Aufnahme
des EKG’s kann bzw. soll im Rahmen einer Kontrolluntersuchung erfolgen. Diese
Kooperation zwischen Niedergelassenem Arzt und HSM-Ambulanz führt zu einer
erheblichen Entlastung des Patienten und der HSM-Ambulanz. Um den Wert dieser
Untersuchung steigern zu können, ist es denkbar, noch Zusatzdaten mit zu erheben.
5
1.3. TELEMEDIZIN ALS CHANCE
1.3
1. Einleitung
Telemedizin als Chance
Die sehr schnelle Weiterentwicklung und Verbreitung des Internets sowie die damit
verbundenen neuen Technologien zur Datenerfassung und Datenübertragung haben
in letzter Zeit auch im medizinischen Bereich Einzug genommen. Das Stichwort heißt
Telemedizin.
Das Internet stellt in diesem Fall die Kommunikationsplattform zwischen Arzt und
Patient bzw. zwischen den Ärzten her [5]. Vernetzte Computer sind vom alltäglichen Krankenhausalltag nicht mehr wegzudenken. Sei es um Informationen auszutauschen, Daten zu versenden oder in näherer Zukunft Teleoperationen auszuführen.
Neue Medien wie E-Mail, Web-Meeting, usw. erfreuen sich bei den Ärzten hoher Akzeptanz.
Telemedizin und Telemonitoring bauen weitgehend auf IT Technologien auf. Neben
Kommunikationsmöglichkeiten werden dem Arzt Zusatzfunktionen wie Informationsund Personendatenbanken, Befunderstellung und vieles mehr geboten. Der Arzt ist
durch die Einbindung des Internets nicht mehr an einen Arbeitsplatz gebunden,
wodurch eine noch intensivere Betreuung seiner Patienten möglich ist. Patienten
können so aktiv in ihre Behandlung eingebunden werden, indem sie durch regelmäßiges Feedback den Kontakt zum Arzt aufrecht erhalten und somit die Therapie
positiv beeinﬂussen können.
Eine medizinische Dienstleistung übers Internet bietet sehr viele Vorteile: einerseits
ermöglicht es den Informationsaustausch zwischen Benutzern, wie z.B. eine online
Zusammenarbeit zwischen Ärzten oder Patienten, und andererseits bietet es dem
Provider leichte Wartung und rasche Fehlerbehebung durch zentrale Serversysteme.
Das Internet stellt die nötige Infrastruktur zur Verfügung um Daten auszutauschen,
zu vergleichen und zu publizieren. Die große Anzahl von verschiedensten Daten bildet die Grundlage für ein ausgedehntes Informationsnetzwerk.
Diese Gründe waren dafür ausschlaggebend, die Applikation Patientennahe HSM”
Nachsorge“ als Web-Service zu realisieren. So ist in den letzten Entwicklungsmonaten ein Prototyp eines Softwareprojekts entstanden, der zukunftsorientiert den
Wünschen der Ärzte und der Patienten gerecht wird.
1.4
Gesundheitspolitische Aspekte
In der Zeit vom 23.01.2002 bis zum 10.04.2002 wurde in der HSM-Ambulanz eine
Statistik geführt, die als Grundlage für eine gesundheitspolitische Betrachtung des
Projekts Patientennahe HSM-Nachsorge“ diente. Es wurde ermittelt, in welchem
”
6
1.4. GESUNDHEITSPOLITISCHE ASPEKTE
1. Einleitung
Rahmen es möglich ist, den Patienten und die HSM-Ambulanz, durch eine Auslagerung der HSM-Nachsorge zum Niedergelassenen Arzt, zu entlasten.
Abbildung 1.3: Anfahrtswege der Patienten zur HSM-Ambulanz
Im angegebenen Zeitraum (50 Werktage) wurde bei 585 Patienten eine HSM-Nachsorgeuntersuchung durchgeführt. Aus Abbildung 1.3 ist ersichtlich, dass einige Patienten mehr als 100 km (Hin- und Rückfahrt) zurücklegen mussten um in die HSMAmbulanz zu gelangen. Das entspricht einer Fahrzeit von ca. 90 Minuten. Darüber
hinaus wurde ermittelt, dass jeder vierte Patient für die Fahrt zur bzw. von der
HSM-Ambulanz die Rettung in Anspruch nahm.
Hochgerechnet auf ein Jahr werden an der Klinischen Abteilung für Kardiologie etwa 2900 Nachsorgeuntersuchungen durchgeführt. Bei rund 80 % der Untersuchungen
werden keine HSM-Einstellungen vorgenommen, d.h.: eine Beurteilung des Batteriestatus würde genügen um maximale Betriebssicherheit des HSM zu garantieren.
Eine einfache und sichere Screening-Methode, die es erlaubt, diese wenigen, besonderen Fälle von der Summe aller Untersuchungen zu erkennen, würde zu einer
deutlichen Entlastung der HSM-Ambulanz führen. Es liegt nun nahe, diese HSM”
Basisnachsorge“ vom Niedergelassenen Arzt durchführen zu lassen. Patienten mit
ERI- oder EOL-Indikation sollen herausgeﬁltert und an die HSM-Ambulanz überwiesen werden. Überdies können durch diese Arbeitsteilung den mehrheitlich älteren
und zum Teil gebrechlichen Patienten Strapazen durch lange Transport- und Wartezeiten erspart werden.
7
1.5. ZIEL DER ARBEIT
1.5
1. Einleitung
Ziel der Arbeit
Das Ziel der Arbeit war die Entwicklung eines Web-Service mit dem Schwerpunkt
Patientennahe HSM-Nachsorge“. Nach einer eingehenden Produktrecherche auf na”
tionaler und internationaler Ebene wurden bestehende Systeme analysiert und insbesondere auf Herstellerunabhängigkeit und Benutzerfreundlichkeit geprüft. Durch
eine Workﬂow-Analyse des bisherigen Ablaufes einer HSM-Nachsorgeuntersuchung
an der HSM-Ambulanz wurde untersucht, welche Arbeitsschritte optimiert bzw. ausgegliedert werden können.
Die modulare Gestaltung der zu entwickelnden Software sollte es ermöglichen, in Zukunft neue Applikationen hinzuzufügen bzw. bestehende Komponenten, wie die in
einer parallelen Diplomarbeit [37] entwickelte Anwendung PAF-Risikoanalyse“ zu
”
integrieren. Darauf war im Besonderen bei der Entwicklung der Datenbank zu achten. Diese Datenbank sollte alle Parameter aus den Applikationen Patientenna”
he HSM-Nachsorge“ und PAF-Risikoanalyse“ in einer Anwendung integrieren und
”
leicht erweiterbar sein.
In dieser Arbeit wurde das Hauptaugenmerk auf die Entwicklung der Datenbank
gelegt. Für Informationen zur Realisierung des Web-Servers und der Benutzeroberﬂäche sei schon an dieser Stelle auf die Diplomarbeit Ein System zur automatischen
”
Langzeit EKG Fernanalyse“[37] verwiesen.
1.6
Recherche
Telematikdienste für die häusliche und mobile Betreuung von Älteren, Pﬂegebedürftigen und Kranken werden unter dem Überbegriﬀ Home Care“ zusammengefasst.
”
Diese können in den verschiedensten Formen ausgeführt sein - wie z.B.: Videoüberwachung, Baby - Phone, Alarmsysteme, usw.
Unter Telemonitoring im medizintechnischen Bereich versteht man die mobile Überwachung verschiedener physiologischer Parameter, wie Blutdruck, Gewicht, Blutzucker oder allgemeine Krankheitssymtome. Die Aufnahme bzw. die Übertragung
der Daten zur Monitoringzentrale erfolgt z.B. über Medien wie Internet, Festnetztelefon oder Mobilfunktechnologien.
Als Ergebnis steht dem Patienten bzw. dem behandelnden Arzt ein Befund bzw. eine
Trendkurve zu Verfügung, die zur besseren Diagnose und zur Unterstützung beim
Therapiemanagement beitragen soll.
Der Sammelbegriﬀ dieser Anwendungsgebiete ist Telemedizin“. Durch die rasche
”
technische Weiterentwicklung können immer mehr Sparten in den Bereich Telemedizin aufgenommen werden, wie z.B. die Telechirurgie.
8
1.6. RECHERCHE
1. Einleitung
Im Folgenden wird auf schon bestehende Systeme im Telemedizinbereich hingewiesen. Der Schwerpunkt liegt dabei auf PC basierenden EKG-Systemen und Systemen zur Durchführung einer HSM-Nachsorge ohne herstellerspeziﬁschens HSMProgrammiersystem.
1.6.1
PC-EKG Systeme
Cardio Control Workstation
Dieses Software Paket von der Firma Cardio Control NV, 2624 BC Delft, Niederlande
[36] erlaubt es dem Benutzter auf externe (Mess)Geräte mittels USB - Schnittstelle
zuzugreifen. Die aufgezeichneten Messdaten werden von der Software verwaltet und
es lassen sich Auswertungen bzw. Trendkurven darstellen. Neben einer Personenverwaltung (Patienten sowie Ärzte) ist auch ein Modul zur online Zusammenarbeit mit
mehreren Ärzten integriert.
Ähnliche Produkte werden von den Firmen Getemed Medizin- und Informationstechnik AG, 14513 Teltow, Deutschland [18] und Dr.Vetter Gesellschaft für Medizinische
Datentechnik mbH, 76530 Baden-Baden, Deutschland [15] angeboten.
PDA-EKG
Auch PDA’s (Personal Digital Assistant) haben in den letzten Jahren Einzug in
die Medizin genommen. Vorteile bringen die kleine Bauweise und die Unabhängigkeit von ﬁx installierten Computerarbeitsplätzen. Nachteilig zu vermerken war
bis jetzt der Mangel an Schnittstellen zu externen Geräten und der begrenzte Speicherplatz. Neue standardisierte, drahtlose Übertragungstechnologien, wie BlueTooth
bzw. WLAN [46] eröﬀnen viele zusätzliche Einsatzgebiete in der Medizintechnik, da
Mobilität und Erreichbarkeit zunehmend wichtig werden. Folgende Firmen bieten
PDA-EKG Rekorder an: Brentwood by Midmark, Torrance, CA 90505, USA; Active
Corporation,Maine 04421,USA. [8],[11]
1.6.2
Bestehende HSM-Nachsorge Systeme
Viele HSM-Hersteller bieten Nachsorgesysteme für den Heimgebrauch an [33], [4].
Als Beispiel sei das Nachsorgesystem der Firma Medtronic angeführt. Die Datenübertragung erfolgt über das Festnetztelefon. Für dieses System ist ein spezieller
Telefonadapter erforderlich, der die Verbindung zu einer Empfangs-Zentrale aufbaut
und das aufgenommene EKG für die Übertragung frequenzmoduliert. In der Zentrale
9
1.6. RECHERCHE
1. Einleitung
Abbildung 1.4: EKG Übertragung mittels Telefonadapter
wird das EKG demoduliert und via Fax oder E-Mail an den zuständigen Kardiologen weiterleitet, der dann in weiterer Folge den Befund an den Patienten sendet.
(Abbildung 1.4).
Nachteile dieser Systeme sind einerseits die hohen Anschaﬀungskosten für den Transmitter und andererseits die Tatsache, dass der Patient bei der HSM-Nachsorge auf
sich alleine gestellt ist. Zur Zeit ist auch noch keine automatische Befundung und
Befunderstellung integriert und die aufgenommenen Daten werden nicht in elektronischer Form gespeichert.
Einen Ausblick auf zukünftige Entwicklungen zeigt das HSM-Modell Philos DR”
T“ der Firma Biotronik [33], welches sich derzeit in der klinischen Erprobungsphase
beﬁndet. Ein kleiner Sender im Implantat schickt die aufgezeichneten Daten an ein
mobiles Patientengerät“ mit integriertem Mobilfunkgerät. Dieses Gerät überträgt
”
die Nachrichten an eine Servicezentrale, in der die Implantatnachrichten bearbeitet und in einem Bericht zusammengestellt werden. Der behandelnde Arzt erhält
diesen Bericht per Fax in vereinbarten Zeitabständen oder, wenn vordeﬁnierte Abweichungen auftreten. Er entscheidet daraufhin, ob der Therapieplan geändert und
die Einstellungen des Implantats optimiert werden müssen. Gegebenenfalls vereinbart er einen Nachsorgetermin.
Auch bei diesem System fallen hohe Anschaﬀungskosten sowie Übertragungsgebühren an. Da die Ergebnisse via FAX an die behandelnde Klink übermittelt werden,
müssen weitere Schritte zur Integration in ein allgemeines Nachsorgesystem angestrebt werden. Der Vorteil dieses Systems liegt darin, dass mehrere relevante Parameter, wie die Reizschwelle oder der Übergangswiderstand und zukünftig auch
Ausschnitte von intramyokardialen Elektrogrammen online übertragen werden können und damit eine kardiale Diagnose sowie Therapieführung möglich sein wird.
10
1.6. RECHERCHE
1. Einleitung
Generell bieten alle HSM-Hersteller für ihre Implantate speziﬁsche Nachsorgedienste an. Die Datenübertragung erfolgt in allen Fällen über das Telefon und somit
ist eine digitale Speicherung der Daten nur begrenzt möglich. Für die Kliniken entsteht durch die verschiedenen Systeme ein erheblicher Mehraufwand, der nur durch
Integration in ein allgemeines herstellerunabhängiges Nachsorgesystem vermieden
werden kann.
11
Kapitel 2
Methoden
2.1
Klinisches Umfeld
Im Mittelpunkt der HSM-Nachsorge steht ein herstellerspeziﬁsches HSM-Program”
miersystem“ (Abbildung 2.1). Dieses Gerät ist in der Lage ein EKG aufzuzeichnen
und kann mittels integrierter Telemetriefunktion Kontakt zum HSM aufnehmen. Mit
der Auslesespule, die direkt über dem HSM platziert wird, können Daten aus dem
HSM gelesen und HSM-Parameter eingestellt werden. Somit kann der behandelnde
Arzt die Stimulationsparameter optimal den Bedürfnissen des Patienten anpassen.
Eine Optimierung der HSM-Parameter ist auch im energetischen Sinn sehr wichtig.
Abbildung 2.1: HSM-Programmer der Firma Medtronic
12
2.2. ABLAUF DER HSM-NACHSORGE
2. Methoden
Folgende Überprüfungen sind daher in regelmäßigen Abständen entsprechend den
Richtlinien [16],[28],[1] durchzuführen:
• Basisnachsorge (alle 6 - 12 Monate)
– Prüfung von Reizbeantwortung
– Wahrnehmungsfunktion (Sensing)
– Beurteilung des Batteriezustandes
– Beurteilung, ob die gewählte Systemeinstellung noch den Erfordernissen
des Patienten genügt
Die Basisnachsorge kann durch die Aufzeichnung einer EKG-Sequenz bei temporärer Magnetauﬂage und entsprechender Interpretation eines Spezialisten
(Kardiologe) ausgeführt werden.
• Erweiterte Nachsorgen (alle 12 - 18 Monate) In Abhängigkeit vom Ergebnis der Basisnachsorge und vom HSM-Typ müssen weitere Untersuchungen
durchgeführt werden, wie z.B.:
– Reizschwelle von Vorhof und Kammer
– Elektrodenimpedanz
– Wahrnehmungsschwelle
– Diagnostische Funktionen (soweit vom HSM-Type unterstützt)
Für die erweiterte HSM-Nachsorgeuntersuchung ist ein herstellerspeziﬁsches HSMProgrammiergerät erforderlich. Durch die hohen Anschaﬀungskosten verfügen nur
wenige Kliniken, sog. HSM-Ambulanzen“, über solche Geräte. Die Klinische Abtei”
lung für Kardiologie am LKH-Universtitäsklinikum Graz verfügt über Geräte folgender HSM-Hersteller: Biotronik, Medtronic, St. Jude Medical, Vitatron, ELA und
Intermedics.
2.2
Ablauf der HSM-Nachsorge
Der Vergleich zwischen dem bisherigen Arbeitsablauf und dem der Patientennahen
”
HSM-Nachsorge“ soll die Vorteile, die diese neue Methode bietet, verdeutlichen. Die
Workﬂow-Analyse dient als Anhaltspunkt für die Entwicklung der Datenbank und
der Benutzeroberﬂäche.
13
2.2. ABLAUF DER HSM-NACHSORGE
2.2.1
2. Methoden
Ambulante HSM-Nachsorge
In Abbildung 2.2 ist der bisherige Arbeitsablauf dargestellt, wie er derzeit an der
HSM-Ambulanz durchgeführt wird und im Wesentlichen einer erweiterten Nachsorge entspricht. Nach der Implantation, werden bei der Entlassungsuntersuchung der
Sitz der Elektroden kontrolliert und die HSM-Parameter bei Bedarf optimiert. Eine
Implantation
Kontrolle und HSM-Einstellung vor der Entlassung
HSM
Nachsorge
Anamnese
EKG aufzeichnen
Signal auswerten
Kontrolle der
Parameter
Befund
Niedergelassener Arzt
HSM-Ambulanz
JA
Nächster Termin
OK
NEIN
Revision
Abbildung 2.2: Ablauf der ambulanten HSM-Nachsorgeuntersuchung
weitere Kontrolle erfolgt etwa vier bis fünf Monate nach der Implantation. Zu diesem Zeitpunkt kann davon ausgegangen werden, dass die Elektroden eingewachsen
sind. Dies führt in den meisten Fällen zu einer Veränderung der Reizschwelle. Um
optimale Stimulation und minimalen Energieverbrauch zu erreichen, müssen die Stimulationsparameter (Impulsdauer und -amplitude) an die Reizschwelle angepasst
14
2.2. ABLAUF DER HSM-NACHSORGE
2. Methoden
werden (Reizschwellentest). Ab diesem Zeitpunkt kann davon ausgegangen werden,
dass der HSM optimal an die Bedürfnisse des Patienten angepaßt ist. Unter normalen Umständen sind ab nun nur mehr Kontrollen in regelmäßigen Abständen nötig,
bis der Ladezustand der Batterie seinen kritischen Wert erreicht hat. Die Kontrollintervalle sind vom Ladezustand der Batterie bei der letzten Kontrolluntersuchung,
von der Aktivität des HSM und den eingestellten Parametern abhängig. Nach der
Implantation kann von einem 100%igem Ladezustand der Batterie ausgegangen werden, und damit wird das erste Nachsorgeintervall meist auf ein Jahr1 festgelegt.
Ablauf der ambulanten HSM-Nachsorge:
Die Anamnese hilft dem Arzt die Bedürfnisse des Patienten zu erheben und den
HSM optimal einzustellen. Die einzustellende Stimulationsfrequenz richtet sich im
Wesentlichen nach der Aktivität des Patienten. Eine zu nieder eingestellte Frequenz
führt zu Schwindel und eine zu hohe Frequenz ruft ein allgemeines Unbehagen beim
Patienten hervor.
Die Funktionalität und Aktivität des HSM kann der Arzt aus einer aufgezeichneten
EKG-Sequenz entnehmen. Nach ca. zehn Sekunden Ruhe-EKG erfolgt die Kontrolle
des Batteriezustandes. Dazu wird die Auslesespule, in der auch der Permanetmagnet integriert ist, aufgelegt, wodurch der HSM in den Magnet-Mode umschaltet.
Durch die Wirkung des Magneten wird die Telemetriefunktion des HSM aktiviert.
Die gespeicherten Parameter werden von der Auslesespule empfangen und an das
HSM-Programmiersystem weiterleitet. Der Arzt kann mit dem Programmiergerät
ein Testprotokoll erstellen, das Telemetriedaten, HSM-Einstellungen und eine EKGSequenz enthält.
2.2.2
Patientennahe HSM-Nachsorge
Die entwickelte Patientennahe HSM-Nachsorge“ ermöglichrt eine Aufgabenteilung
”
und Kollaboration zwischen HSM-Ambulanz, Niedergelassenen Ärzten und Monitoring-Zentrale (Abbildung2.3). Damit ist es möglich die Basisnachsorge beim Niedergelassenen Arzt durchzuführen.
Nach der Implantation wird der Patient zusätzlich in das Nachsorgesystem aufgenommen d.h. Abspeichern aller Daten laut HSM-Ausweis [21]. Der auf das System
eingeschulte Arzt, bzw. das medizintechnische Fachpersonal zeichnet ein EKG mit
temporärer Magnetauﬂage auf und sendet die Messdaten, so wie die Ergebnisse
der Anamnese an die Monitoring-Zentrale. Das Analysesystem in der MonitoringZentrale wertet die übertragenen Daten automatisch aus und berechnet daraus eine
1
Für Patienten, die HSM-Abhängigkeit aufweisen, d.h. keinen Eigenrhytmus besitzen, wird ein
kürzeres Nachsorgeintervalle gewählt.
15
2.2. ABLAUF DER HSM-NACHSORGE
2. Methoden
Abschätzung über den aktuellen Ladezustand der Batterie (BOL/ERI/EOL). Abhängig von der Implantationsdauer und dem Batteriestatus wird ein Vorschlag für
den nächsten Nachsorgetermin berechnet. Diese Aufgabe hat bei der üblichen ambu-
Niedergelassener
Arzt
HSM-Ambulanz
Monitoring-Zentrale
Abbildung 2.3: Patientennahe HSM-Nachsorgeuntersuchung
lanten HSM-Nachsorge das herstellerspeziﬁsche HSM-Programmiersystem erledigt.
Das Ergebnis der automatischen Analyse wird dem zuständigen Kardiologen an der
HSM-Ambulanz in Form eines Berichts bereitgestellt. Die gesammelten Berichte zur
Begutachtung werden im Posteingang“ abgelegt. Der Kardiologe kann in kurzer Zeit
”
die vorbefundeten Berichte kontrollieren und wenn nötig überarbeiten. Für unklare
Fälle kann er zusätzlich das aufgezeichnete EKG am Bildschirm darstellen oder ausdrucken.
Nach Bestätigung durch den Kardiologen wird der fertige Befund als PDF-Datei im
Dateisystem des Servers gespeichert und kann als E-Mail oder Fax an den entsprechenden Niedergelassenen Arzt weitergeleitet werden. Dieser informiert den Patienten über das Ergebnis der Befundung und ﬁxiert den nächsten Nachsorgetermin.
Bei schlechtem Ladezustand der Batterie oder in unklaren Fällen beordert der Kardiologe den Patienten unmittelbar zu einer erweiterten Nachsorge in die HSMAmbulanz.
Damit können alle notwendigen Untersuchungen für eine Basisnachsorge direkt beim
Niedergelassenen Arzt durchgeführt werden.
16
2.3. ENTWICKLUNGSUMGEBUNG
2.3
2. Methoden
Entwicklungsumgebung
Für die Realisierung dieses Projekts wurde bei den benötigten Soft- und HardwareKomponenten besonders auf eine hohe Benutzerfreundlichkeit, Erweiterbarkeit und
Betriebssystemunabhängigkeit geachtet. Durch Verwendung von Open Source Produkten ist es gelungen, die notwendigen Investitionen gering zu halten.
2.3.1
Hardware
PC-EKG
Nach eingehender Marktanalyse (Kapitel 1.6) ﬁel die Entscheidung auf das PC-EKG
System der Firma Cardio Control (Cardio Control NV, 2624 BC Delft, Niederlande),
welches die auferlegten Kriterien erfüllte:
• Mobiles EKG-Aufzeichnungsgerät
• EKG-Daten auf PC übertragbar und von anderen Anwendungen zugänglich
• Mind. 1000 Hz Abtastrate
• Verfügbarkeit
Der PC-EKG Rekorder (Cardio Perfect MD 1200Hz) und die Anwendersoftware
(Cardio Control Workstation), wurde uns für Testmessungen freundlicher Weise von
der Firma Technomed, Graz, Österreich unentgeltlich zur Verfügung gestellt.
Der batteriebetriebene EKG Rekorder ist für 12 Ableitungen ausgelegt und verfügt
über eine Abtastrate von 1200 Hz. Die Verbindung zum Patienten wird über das
Patientenkabel“ hergestellt. Um eine vorgeschriebene galvanische Trennung zwi”
schen dem Patienten und dem Computer zu erreichen, erfolgt die Datenübertragung
vom Aufnahmesystem zum PC über einen Lichtwellenleiter.
Server in der Monitoring-Zentrale
Moderne Web-Applikation sind so ausgelegt, dass die verschiedenen Komponenten
wie Web-Server, Datenbank und die Signalanalyseeinheit auf mehrere Rechner verteilt werden können, um eine bessere Performance und eine Geschwindigkeitssteigerung zu erreichen. Das Rechnersystem für die Applikation Cardio-Memory“ wurde
”
aus drei Server zusammengestellt:
• Datenbank-Server: Intel Pentium III, 650 MHz, 128 RAM
• Server für Signalanalyseeinheit: AMD Athlon, 1100 MHz, 512 RAM
• Applikations-Server: Intel Pentium II, 500 MHz, 64 RAM
17
2.3. ENTWICKLUNGSUMGEBUNG
2.3.2
2. Methoden
Software
Bei der Auswahl der Software konnte auf ein bei ARC Seibersdorf research GmbH
bestehendes Softwarekonzept zurückgegriﬀen werden, das mit den noch zusätzlich
benötigten Komponenten erweitert wurde. Folgende Softwarekomponenten wurden
benötigt:
• EKG Aufzeichnung (Cardio Control Workstation)
• Web-Server
– Modul zur EKG Übertragung
– Modul zu Kommunikation mit der Datenbank
• Datenbank
• Signalanalyseeinheit (bereits vorhanden)
• Modul zur PDF-Befunderstellung
Cardio Control Workstation
Die Software verfügt über zahlreiche Funktionen zur Signalanalyse und der EKGDarstellung. Die aufgenommenen Daten (Patienten, sowie Messdaten) werden in
einer Datenbank (Microsoft SQL Server 7.0) abgelegt.
Das Zusatztool Cardio Control Dump“ ermöglicht einen Zugriﬀ auf die EKGs, die
”
in der Datenbank abgelegt sind, und exportiert die als BLOB (Binary Large Object)
gespeicherten Datensätze als ASCII-Datei. Diese Datei wird im lokalen Dateisystem
abgelegt.
Dateiformat:
Dateiname:
MM
DD
YYYY
HH
NN
LASTNAME
ECG MMDDYYYY-HHNN LASTNAME.TXT
Monat
Tag
Jahr
Stunde
Minute
Nachname
18
2.3. ENTWICKLUNGSUMGEBUNG
2. Methoden
Der Dateiinhalt besteht aus einem Header, gefolgt von den Samplewerten für die
jeweiligen Ableitungen I und II.
Header:
001 Name des Patienten
002 Nummer des Patienten
003 EKG Aufzeichnungsdatum
004 Abtastfrequenz
005 Nanovolt per LSB 2 eines Samplewertes
006 Länge des EKG’s in ms
007 Name der Elektrode, 1 Sample pro Zeile
Zur Beschleunigung der Datenübertragung, kann das aufgezeichnete EKG mit einer
Komprimierungsraten von etwa 70 % komprimiert werden.
Abbildung 2.4: Benutzeroberﬂäche Cardio Control Workstation
2
Least Significant Bit
19
2.3. ENTWICKLUNGSUMGEBUNG
2. Methoden
Web-Server
Ein besonderes Augenmerk bei der Auswahl der Komponenten wurde auf den WebServer gelegt werden, da dieser die zentrale Komponente eines Webservices darstellt.
Die Anforderungen an den Web-Server sind: Modularität bzw. Erweiterbarkeit, leichte Wartung und eﬃziente Benutzerverwaltung. Diese Anforderungen werden vom
ZOPE-Web-Server (Version 2.4.2, Zope Corporation, Fredericksburg, Virginia, USA)
erfüllt.
Zope stellt ein durch den Software-Entwickler anpassbares und erweiterbares Entwicklungssystem für Web- und Serverapplikationen dar, das seit 1998 als Open Source Projekt weltweit eingesetzt wird. Vor einigen Jahren noch als Außenseiterlösung
gehandelt, hat sich Zope in permanenter, globaler Entwicklungsarbeit zu einem ausgereiften Produkt entwickelt, das bei namhaften Firmen und Institution (Bank of
America, Franklin University, University of Pittsburgh Medical Center, NATO, NASA, usw.) eingesetzt wird [12].
Zope besitzt eine konsequent objektorientierte Struktur. Mit den Objekten (Module)
geht auch eine sehr ausgereifte Benutzerverwaltung einher. Die Objekte können einzelnen Benutzern zugewiesen, und den Benutzern wiederum entsprechende Rechte
zugesprochen werden.
Die Implementierung der Applikation erfolgt in sogenannten DTML-Skripts3 , die
stark an die Programmiersprache HTML angelehnt sind. Neben DTML-Skripts können auch Python-Skripts implementiert werden. Diese ermöglichen eine eﬃziente
Handhabung dynamischer Web-Seiten und serverseitig Berechnungen; Zugriﬀ auf
die Betriebssystemebene bzw. das Dateisystem des Servers ermöglichen sogenannte
externe“ Python-Skripts.
”
Der ZOPE Applikationsserver wurde mit folgenden Produkten erweitert:
• Datenbank Adapter
Auf externe Datenbanken kann mit sogenannten Datenbank-Adaptern zugegriﬀen werden. Die Datenbankabfragen, sowie die Datenbankobjekte, werden
innerhalb des Systems als eigenständige Objekte verwaltet. Der Web-Server
kommuniziert mit der Interbase Datenbank über das Modul gvibDB (Going
Virtual Zope Interbase Database Adapter), Version 0.9.6.
• LocalFS
Das Zope Produkt LocalFS (Local File System) in der Version 0.2.1 steuert
den Zugriﬀ auf das Dateisystem des Web-Servers. Es ist damit möglich, Dateien bzw. Verzeichnisse zu erstellen, auf sie zuzugreifen und über dieses Modul
3
Document Template Markup Language
20
2.3. ENTWICKLUNGSUMGEBUNG
2. Methoden
Dateien von einem Client an den Server zu übertragen. Durch das Benutzerverwaltungssystem des Web-Servers ist die Sicherheit gewährleistet, dass nur
autorisierte Benutzter Zugriﬀsrechte (Lesen oder Schreiben) erhalten.
• Python Image Library (PIL)
Alle graphischen Operation steuert das Modul PIL. Es ermöglicht die Handhabung und Bearbeitung aller Arten von Graphiken.
• ReportLab
Ein sehr mächtiges Tool zum Erstellen eines PDF-Reports stellt das Open
Source Produkt ReportLab“ dar. Es ist möglich, das Modul ReportLab direkt
”
in den Zope Server zu integrieren und mittels Python Skripts zu steuern. Die
Bearbeitung der eingefügten Graphiken übernimmt das Modul PIL.
Datenbank
InterBase (IB) Version 6.0, Borland Software Corporation, USA ist eine relationale
Datenbank, in der viele Anforderungen aus dem ANSI-SQL-92 Standard [13] implementiert sind. Interbase enthält erhebliche Erweiterungen, die derzeit noch nicht im
SQL Standard deﬁniert sind, z. B. Generatoren, Trigger und Stored Procedures.
Eigenschaften von Interbase:
• Interbase ist Plattform unabhängig. Aus der Produktbeschreibung geht hervor,
dass 18 verschiedene Betriebssysteme unterstützt werden.
• Konﬂiktfreier Zugriﬀ: Eine spezielle Architektur verhindert, dass lesende Zugriﬀe von schreibenden blockiert werden und umgekehrt. Jedes Mal, wenn ein
Datensatz verändert wird, und diese Änderung an die Datenbank übergeben
wird, erzeugt Interbase eine neue Version dieses Datensatzes. Alle anderen
Transaktionen sehen solange weiterhin die alte Version. Auf diese Weise wird
erreicht, dass ein Benutzer, der eine Tabelle untersucht, die jeweils neueste
freigegebene Version jedes Datensatzes sieht.
• Trigger: Interbase erlaubt mehrere Trigger pro Operation auf der selben Tabelle. Die Reihenfolge des Aufrufs kann durch Prioritäten gesteuert werden.
Zur Steigerung der Modularität können mehrere Teiltrigger eingesetzt werden.
• Stored Procedures: Das Ziel einer Server/Client Anwendung besteht darin, aufwendige Berechnungen den Server durchführen zu lassen und den Datenﬂuss
21
2.3. ENTWICKLUNGSUMGEBUNG
2. Methoden
innerhalb eines Netzwerks auf ein Minimum zu begrenzen. Ein Vorteil von Stored Procedures (SP) und Triggern ist, dass sie als Teil der Datenbank implementiert und verwaltet werden und direkt auf dem Server ausgeführt werden.
Auf diese Weise haben sie direkten Zugriﬀ auf die Daten.
Spezielle Selektierbare Prozeduren“ können in einer Select-Anweisung verwen”
det werden. Sie können mit Tabellen, Views und anderen Stored Procedures
verknüpft werden und werden mittels Eingabeargumenten parametrisiert. Ein
spezielles Konstrukt, FOR / INTO / SUSPEND“, erzeugt den Rahmen einer
”
selektierbaren Prozedur.
• Exceptions: Exceptions sind Warnhinweise, die von Triggern und SP aufgerufen werden, wenn z.B. ein SQL-ERROR auftritt. Die Exception wird mit
ihrem Namen angesprochen, liefert als Ergebnis einen Warnhinweis und bricht
die Operation ab, von der sie aufgerufen wurde. Die Veränderungen, die diese
Operation womöglich an der Datenbank durchgeführt hat, werden zurückgesetzt.
Signalanalyseeinheit
Die Signalanalyse ist in MatLab Version 6.1 (The MathWorks Inc., USA) implementiert. Für die Kommunikation mit Datenbank-Systemen auf Betriebssystemebene
ODBC Driver Manager
Easysoft
ODBC - InterBase Driver
InterBase Client
InterBase
Database Server
Abbildung 2.5: EasySoft ODBC-Interbase DriverIB6
22
2.3. ENTWICKLUNGSUMGEBUNG
2. Methoden
werden ODBC4 Schnittstellen benutzt. Mit der ODBC-Schnittstelle können Zugriﬀe
auf die Datenbank und Zugriﬀe des Datenbank-Clients auf externe Datenbanken realisiert werden. Anfragen werden an den ODBC-Treibermanager geschickt und dort
an den entsprechenden ODBC-Treiber weitergeleitet. Der ODBC-Treiber leitet die
Anfrage an das Zieldatenbanksystem weiter und nimmt auch die Antwort auf die
Anfrage entgegen. Die Antwort wird zum ODBC-Treibermanager weitergeleitet und
gelangt dann zu der Applikation, welche die Anfrage gestellt hat (Abbildung 2.5).
In dieser Applikation wird durch den Einsatz des EasySoft ODBC-Interbase DriverIB6 (Easysoft Limited, Wetherby, Großbritannien) die Kommunikation zwischen der
INTERBASE Datenbank und des MATLAB Signalanalyseeinheit realisiert.
4
Open Data Base Connectivity
23
2.4. RELATIONALE DATENBANK
2.4
2. Methoden
Relationale Datenbank
Das bekannteste Modell zur Datenspeicherung ist die relationale Datenbank, die auf
das Modell von Dr. E. F. Codd aus dem Jahr 1970 zurückgeht [10]. Codd stützt sich
in seinem Modell auf die mathematischen Konzepte der relationalen Algebra, um
Daten in Mengen und miteinander in Beziehung stehende Untermengen aufzuteilen.
Da sich Informationen von Natur aus in unterscheidbaren Mengen gruppieren lassen, baute Dr. Codd sein Datenbanksystem auf diesem Konzept auf. Das relationale
Modell gliedert die Daten in Sätze (Entität) und stellt sie in Form einer Tabellenstruktur dar. Diese Tabellenstruktur besteht aus einzelnen Datenelementen - den
sogenannten Spalten oder Feldern. Als Datensatz oder Zeile bezeichnet man einen
einzelnen Satz, der eine Gruppe von Feldern zusammenfasst.
2.4.1
SQL
Um auf Daten in Datenbanksystemen zugreifen zu können wurde Ende der 70er
Jahre die Sprache SQL (Sequence Quere Language)[14] deﬁniert - zu deutsch etwa:
strukturierte Abfragesprache. Es handelt sich dabei um eine nichtprozedurale5 Sprache. SQL ist somit die De-facto-Standardsprache, mit der sich Daten aus relationalen
Datenbanken abrufen und manipulieren lassen. Mit SQL kann der Programmierer
folgende Aufgaben ausführen:
• die Struktur einer Datenbank modiﬁzieren
• die Einstellungen der Systemsicherheit ändern
• Benutzerberechtigungen für Datenbanken oder Tabellen einrichten
• eine Datenbank nach Informationen abfragen
• den Inhalt einer Datenbank aktualisieren
Die in SQL angebotenen Anweisungen lassen sich zu den folgenden wenigen Befehlsgruppen zusammenfassen:
Data Deﬁnition Language (DDL) - Deﬁnition von Daten: Im einzelnen kann man mit
der DDL neue leere Datenbankstrukturen wie Tabellen, Indizes, Views und weitere
5
Nichtprozedural bedeutet was“ statt wie“. SQL beschreibt, welche Daten abzurufen, zu lö”
”
schen oder einzufügen sind und nicht, wie das zu geschehen hat.
24
2.4. RELATIONALE DATENBANK
2. Methoden
Objekte einrichten, die Strukturdeﬁnition existierender Datenbank-Objekte verändern und Objekte löschen.
Data Manipulation Language (DML) - Manipulation von Daten: Die DML dient zur
Manipulation von Daten und zu deren Auswertung. Man kennt zunächst die UpdateAnweisungen. Hierzu gehören die Einfüge-, die Änderungs- und die Löschoperation.
Die SELECT - Anweisung ermöglicht Auswertungen in fast jeder Komplexität.
Data Control Language (DCL) - Steuerung der Vergabe von Zugriﬀsrechten: Im
Einzelnen kann man mit der DCL Systemprivilegien und Rechte von Benutzern auf
Datenbank-Objekte vergeben und verwalten.
2.4.2
Datenbankentwurf
Der Entwurf einer Datenbank soll in diesem Kapitel anhand des Beispieles der
PERSONS“- Datenbank erläutert werden.
”
Konzeptioneller Datenbankentwurf
Dieser Entwurf beschreibt die Datenbank, und dient als Überblick für das zu lösende
Problem. Als Designhilfe für die zu konstruierende Datenbank-Struktur wird die im
Kapitel 2.2.1 beschriebene Workﬂow-Analyse herangezogen. Aus der strukturierten
Gliederung der Aufgabenstellung ist - im Hinblick auf das Datenbank-Design - abzusehen wo und wann welche Art von Daten anfallen.
Abbildung 2.6 gibt einen Überblick über die zu erwartenden Tabellen und Abhängigkeiten. Im Zentrum steht der Patient dem verschiedene Objekte“, wie Herzschritt”
macher, Elektroden, der behandelnde Arzt oder eine Untersuchung zugeordnet werden. Der konzeptionelle Datenbankentwurf ist die formale Beschreibung der zu lösenden Designaufgabe.
Relationaler Datenbankentwurf - Normalformlehre
Aus dem konzeptionellen Datenbank Entwurf kann abgeschätzt werden, mit welchen
Daten und vor allem in welchem Ausmaß zu rechnen ist. Diese Daten werden in der
Universaltabelle“ aufgelistet, die den ersten Schritt zum erfolgreichen Design einer
”
Datenbank darstellt. Die weitere Vorgangsweise wird in der von Codd entwickelten
Normalformlehre beschrieben [10].
Der gedankliche Ansatz der Normalformlehre beginnt mit einer einzigen, umfassenden Tabelle, der Universal Relation“. Diese Tabelle wird schrittweise in Teiltabellen
”
25
2.4. RELATIONALE DATENBANK
2. Methoden
Leads
Physician
PK ID
PK ID
Manufacture
Model
Patients
Name
Adress
Institution
PK ID
Pacemaker
Name
Adress
PK ID
Examination
PK ID
Manufacture
Model
Magnet Mode
Date
ECG - File
Result
Abbildung 2.6: Konzeptioneller Datenbank-Entwurf
zerlegt wobei die Datenabhängigkeit bestehen bleibt und Anomalien (DatenbankStruktur bedingte Fehler) vermieden werden.
In der Universaltabelle müssen alle Datenelemente vorhanden sein, die in die Datenbank aufgenommen werden sollen. Diese Datenelemente nennt man Attribute einer Relation, die durch eine Deﬁnition und durch die Angabe des Datentyps bzw.
des Wertebereiches beschrieben werden. Hauptsächlich verwendete Datentypen sind
Strings (VARCHAR), Fest- oder Gleitkommazahlen (INTEGER, FLOAT) oder Datumsangaben (DATE, TIME, TIMESTAMP).
Erste Normalform:
Die Universal Tabelle wird in der ersten Normalform vorausgesetzt, d.h. alle Attribute haben atomaren Charakter“, lassen sich also aus Sicht der Datenbank nicht
”
mehr aufspalten.
Eine Tabelle beﬁndet sich in der ersten Normalform, wenn jedes Element elementar
ist, und kein Element weggelassen werden kann, ohne dass ein Datenverlust auftritt.
Durch den unstrukturierten Aufbau der Universaltabelle sind Anomalien unvermeidbar. Eine Anomalie in der Datenbank kann zu Datenverlust oder groben Fehlern
führen. Man unterscheidet Lösch-, Einfüge- und Änderungsanomalien die im Folgenden anhand eines Beispieles erläutert werden (Tabelle 2.1):
26
2.4. RELATIONALE DATENBANK
BEZ
HSM
PAF
PAF
HSM
NAME
Max Mustermann
Karin Musterfrau
Max Mustermann
Tom Testperson
2. Methoden
PAT
ADR
Klinikweg 3
Spitalgasse1
Klinikweg 3
Ambulanzweg 45
ORT
8010 Graz
9020 Klagenfurt
8010 Graz
9300 St. Veit
Tabelle 2.1: Lösch-, Einfüge- und Änderungsanomalien
Einfüge-Anomalie:
Ein Patient kann nicht hinzugefügt werden, solange ihm keine Applikation zugeordnet werden kann. Der Ausweg über eine unvollständige Tabellenzeile ist nicht
möglich, da die Datenbank die Zelle BEZ ohne Schlüssel nicht akzeptiert.
Änderungs-Anomalie:
Das Ändern der Adresse kann zu Inkonsistenzen führen, da nach der Änderung
dieselbe Person mit unterschiedlichen Adressen in der Datenbank steht. Bei einer
Änderung der Adresse des Patienten Max Mustermann“ müssen in diesem Fall zwei
”
Datensätze geändert bzw. aktualisiert werden. Das kann bei umfangreichen Datenbanken zu einem erheblichen Mehraufwand führen.
Lösch-Anomalie:
Sollte ein Patient nur einer Applikation zugeordnet sein, so geht nach dem Löschen
des Datenfeldes BEZ auch die gesamte Information über den Patienten verloren. Die
Löschanomalie bildet das Gegenstück zur Einfügeanomalie.
Zweite Normalform:
Die Anomalien der ersten Normalform treten hauptsächlich deshalb auf, weil in einer
Relation mehrere Entitäten (Zusammenhängende Datenfelder) gespeichert werden
können (Tabelle 2.2). In der zweiten Normalform werden solche Anomalien vermieden, indem jede Entität separat in einer eigenen Tabelle gespeichert wird. In dieser
neu entstandenen Relation beﬁnden sich dann nur Attribute, die direkt vom Schlüssel abhängen. Diese Abhängigkeit nennt man volle funktionale Abhängigkeit.
Eine Relation beﬁndet sich in der zweiten Normalform, wenn sie in der ersten Normalform dargestellt ist und jedes Attribut (außer dem Schlüsselattribut) voll funktional vom Schlüssel abhängt.
Alle Attribute der Entität NAME hängen voll funktional von der Patienten-ID
(PAT ID) (die auch der Primärschlüssel ist) ab. Die Applikationsnummer (APP ID)
ist nicht voll funktional vom Primärschlüssel abhängig, da obwohl die Attributwerte
27
2.4. RELATIONALE DATENBANK
PAT ID
1
2
1
3
APP ID
1
2
2
1
BEZ
HSM
PAF
PAF
HSM
2. Methoden
PAT
NAME
Max Mustermann
Karin Musterfrau
Max Mustermann
Tom Testperson
ADR
Klinikweg 3
Spitalgasse1
Klinikweg 3
Ambulanzweg 45
ORT
8010 Graz
1020 Wien
8010 Graz
9300 St. Veit
Tabelle 2.2: Auszug aus der Persons-Datenbank
des Primärschlüssels mehrmals übereinstimmen, man nicht den selben Attributwert
für die Bezeichnung vorﬁndet.
Dieses Problem wird in unserem Fall dadurch gelöst, dass die Tabelle in Teiltabellen
mit voller funktionaler Abhängigkeit aufgespalten wird (Tabelle 2.3, 2.4, 2.5):
PAT
PAT ID
1
2
3
NAME
Max Mustermann
Karin Musterfrau
Tom Testperson
ADR
Klinikweg 3
Spitalgasse1
Ambulanzweg 45
ORT
8010 Graz
1020 Wien
9300 St. Veit
Tabelle 2.3: Auszug aus der Tabelle Patient
APP ID
1
2
APP
Bezeichnung
HSM
PAF
Tabelle 2.4: Auszug aus der Tabelle APP
Die neu entstandenen Tabellen besitzen Relationen, die nichts miteinander zu tun
haben und so nicht mehr dem Zustand der ersten Normalform entsprechen. Die Relationen werden in einer zusätzlichen Zuordnungstabelle geschaﬀen. Redundanzen,
können dadurch weitgehend vermieden werden.
In dieser Zuordnungstabelle ist es auch möglich Informationen, die Relation betreffend, abzuspeichern. (z.B. Datum der Erstellung, erstellender Anwender,. . . )
Dritte Normalform:
Obwohl alle Nicht-Schlüssel-Attribute funktional von ihrem Primärschlüssel abhängig sind, können noch immer Anomalien auftreten, da zum Beispiel der Name des
Herzschrittmacher Biotronik Philos SR 100“ mehrmals auftritt und, sollte er (z.B.
”
in Biotronik Philos SR 101“) geändert werden, so müsste er in mehreren Datensät”
zen geändert werden (Tabelle 2.6).
28
2.4. RELATIONALE DATENBANK
ID
1
2
3
4
2. Methoden
PAT APP
APP ID PAT ID
1
1
2
2
1
3
2
1
Tabelle 2.5: Zuordnungstabelle
PAT HSM
PAT ID
101
102
103
104
NAME
Max Mustermann
Karin Musterfrau
Tom Testperson
Karl Testmann
HSM
Biotronik Philos SR 100
Medtronic Kappa
Biotronik Philos SR 100
Biotronik Philos SR 100
HSM ID
1
2
1
1
Tabelle 2.6: Mustertabelle zur Veranschaulichung der Notwendigkeit des dritten Normalisierungsschrittes
Eine Relation beﬁndet sich in der dritten Normalform, wenn sie in der zweiten Normalform dargestellt ist und kein Attribut (außer dem Schlüsselattribut) transitiv vom
Schlüssel abhängt.
Was bedeutet transitive Abhängigkeit?
In der dargestellten Relation ist PAT ID der Primärschlüssel und alle Attribute hängen voll funktional von ihm ab. Das Attribut HSM ist unabhängig von NAME, das
heißt, ist ein HSM vorgegeben, muss man dadurch nicht automatisch auch den NAME wissen, da es mehrere Patienten gibt, denen das gleiche HSM-Modell implantiert
wurde. In der Tabelle PAT HSM ist jedoch der HSM abhängig von der HSM ID, da
jedem HSM immer nur eine bestimmte Nummer zugewiesen wird, es besteht also
eine transitive Abhängigkeit zwischen den beiden Attributen.
Um diese Relation in die dritte Normalform umzuwandeln, muss diese transitive
Abhängigkeit beseitigt werden. Das geschieht ebenfalls durch eine Auslagerung der
Attribute HSM ID und HSM in eine eigene Relation. Die HSM ID würde allerdings
noch als verweisender Fremdschlüssel in der Relation PAT HSM bleiben (Tabelle
2.7, 2.8):
PAT ID
101
102
103
104
PAT HSM
Name
Max Mustermann
Karin Musterfrau
Tom Testperson
Karl Testmann
HSM ID
1
2
1
1
Tabelle 2.7: Normalisierte Tabelle PAT HSM
29
2.4. RELATIONALE DATENBANK
2. Methoden
HSM
HSM ID
1
2
HSM
Biotronik Philos SR 100
Medtronic Kappa
Tabelle 2.8: Abgespaltete Tabelle HSM
Entity-Relationship Modell (ER-Modell)
Der Entwurf einer relationalen Datenbank beinhaltet auch die übersichtliche Darstellung der durch den Normalisierungsvorgang gefundenen Tabellen. Das Ziel dieser Darstellungsmethode ist es, permanent gespeicherte Daten und ihre Beziehungen
zueinander zu beschreiben. Den Vorschlag einer solchen Betrachtungsweise brachte
erstmals 1976 der Informatiker Peter Chen [9]. Das von ihm entworfene EntityRelationship Modell (ER-Modell) beruht darauf, dass es für den Menschen natürlicher ist, die Welt als etwas wahrzunehmen in der Dinge (Objekte, Entitäten) existieren, zwischen denen Beziehungen (Relationship) bestehen.
Ein ER-Modell hat demnach drei Aufgaben zu erfüllen:
• Das Modell muss dem Datenbank-Entwickler ermöglichen, seine Überlegungen
zu formulieren und zu präsentieren.
• Es dient zur Verständigung zwischen den Entwicklern und dem Anwender zur
Veriﬁzierung des Entwurfes.
• Es soll Ausgangspunkt für die Festlegung des Datenbankschemas und der einzelnen Tabellen sein.
In Abbildung 2.7 ist ein vereinfachter bzw. zusammengefasster Ausschnitt des Datenbankentwurfes der PATIENTS-Datenbank dargestellt. Details werden im Kapitel
3.2 behandelt.
In dieser Darstellung sind neben den Tabellen die Beziehungen der Tabellen zueinander eingezeichnet. Charakterisiert werden diese Beziehungen durch die sogenannte
Kardinalität. Die Kardinalität gibt an, mit wie vielen anderen Entitäten eine Entität eines bestimmten Entitätstyps in Beziehung stehen muss bzw. stehen kann. Die
Angabe erfolgt durch eine Zahl bzw. Buchstaben an den Enden der Linien, mit denen die Entitätstypen verbunden werden. Man unterscheidet vier Grundtypen von
Assoziationen:
• 1:1 Assoziation:
Bsp.: Einem Patienten kann nur ein Schrittmacher implantiert werden.
30
2.4. RELATIONALE DATENBANK
2. Methoden
• 1:N Assoziation:
Bsp.: Ein Patient kann zu mehren Applikationen zugeordnet werden.
• N:1 Assoziation:
Bsp.: Einer Studie können mehrere Patienten angehören.
• M:N Assoziation:
Bsp.: Ein Patient kann mehreren Studien angehören und in einer Studie können
auch mehrere Patienten sein.
Kardiologe
PK
ID
Vorname
Nachname
Adresse
Tel.Nummer
1
C
Niedergelassener Arzt
PK
ID
Vorname
Nachname
Adresse
Tel.Nummer
Patient
1
C
PK
ID
FK1
Vorname
Nachname
Adresse
Geb.Datum
SVNr.
Tel.Nummer
FK_NG_ARZT
1
Herzschrittmacher
Implantation
PK
1
ID
C
Datum
Grund
FK_KARDIOLOGE
FK_PAT_ID
FK_PM_ID
FK_EXPL_ID
Mode
PR
HSM_SN
LEAD_SN
Polarität
Implantationsort
FK_LEAD_ID
1
FK3
FK1
FK2
FK4
1
FK5
1
PK
ID
Hersteller
Modell
Magnet String
Elektroden
C
1
PK
ID
Hersteller
Type
Connector
1
N
1
Untersuchung
PK
ID
FK1
Datum
EKG
FK_NG_ARZT
FK_SIGNAL
FK_PAT_ID
C
FK2
Explantation
PK
ID
Datum
Grund
Kardiologe
Abbildung 2.7: Skizziertes ER-Modell der PERSONS Datenbank
Zusätzlich zu diesen Grundbeziehungstypen können noch spezielle Beziehungsformen
deﬁniert werden. In der Tabelle 2.9 sind mögliche Kardinalitäten dargestellt.
ASSOZIATIONEN
MUSS
MUSS
KANN
KANN
1
M
C
MC
(Min / Max)
(1/1)
(1/n)
(0/1)
(0/n)
Tabelle 2.9: Kardinalitäten
• C:1 Assoziation:
Bsp.: Jedem Patient ist ein HSM zugeordnet. Es gibt aber auch HSM, die
keinem Patienten zugeordnet sind.
31
2.4. RELATIONALE DATENBANK
2. Methoden
• M:CN Assoziation:
Bsp.: Ein Patient kann einer oder mehreren Studien angehören. Es gibt aber
Patienten, die keiner Studie zuzuordnen sind.
• Attribute von Beziehungstypen:
Bsp.: Der Relation Patient - Herzschrittmacher können Attribute, wie Implantationsdatum, behandelnder Arzt,. . . zur Deﬁnition hinzugefügt werden.
• Schwache bzw. existenzabhängigen Entitätstypen:
Bsp.: Diese können nur im Zusammenhang mit Entitäten eines anderen Typs
identiﬁziert werden.Einem Patienten sind N EKGs zugeordnet. Ein EKG kann
aber ohne Patient nicht existieren.
Vom Modell zur Datenbank
Nach der Modellierungsphase wird die Datenbank implementiert. Mittels SQL-Skripts
werden die Tabellen und die dazugehörigen Relationen erzeugt, und DatenbankSkripts (Stored Procedures) für die wichtigsten Datenoperationen wie INSERT, UPDATE und DELETE generiert. Auf alle weiteren Ergebnisse des Datenbankentwurfes
wird im Kapitel 3.2 näher eingegangen.
32
2.5. WEB-SERVER / WEB-DESIGN
2.5
2. Methoden
Web-Server / Web-Design
Die Schnittstelle zwischen Benutzer und System ist die Benutzeroberﬂäche. Der WebServer generiert dynamisch aus den abgerufenen Daten der Datenbank die Webseite.
Die Kommunikation zwischen Web-Server und Datenbank wird über das Servermodul gvibDB (Going Virtual Zope Interbase Database Adapter) sichergestellt (Kapitel 2.3.2). Dieses Modul leitet die SQL Anweisungen des Servers an die Datenbank
weiter und retourniert die Ergebnisse dieser Datenbank-Abfrage an den aufrufenden
Prozess des Servers.
Der Aufbau der Benutzeroberﬂäche wird durch DTML- und Python Skripts gesteuert, die es erlauben, HTML Strukturen, wie Frames und Tables zu integrieren. Um
eine übersichtliche Gestaltung der Benutzeroberﬂäche zu realisieren, werden die Daten in einer tabellarischen Form (Abbildung 2.8) dargestellt, die es auch erlaubt
Sortier- und Suchfunktionen auszuführen.
Abbildung 2.8: Benutzeroberﬂäche
33
2.6. SIGNALANALYSEEINHEIT
2.6
2. Methoden
Signalanalyseeinheit
Die Signalanalyseeinheit ist eine Entwicklung der ARC Seibersdorf research GmbH
und wurde bereits in verschiedenen Projekten evaluiert und eingesetzt (z.B. PAFRisikoanalyse [43]). Für das vorliegende Projekt wurde ein Korrelationsmodul zur
Auswertung der Magneteﬀektes entwickelt. Dies war aber nicht Teil dieser Diplomarbeit. Der Analyseablauf ist in Abbildung 2.9 dargestellt. Nach der Signalaufbereitung
INPUT:
EKG - Signal, Parameter
Signal aufbereitung
Klassifizierung
QRS - Detektion
Analysealgorithmus
(Korrelation mit
Magnetstring)
Signalanalyse
OUTPUT:
Figures, Parameter
Filesystem
Datenbank
Abbildung 2.9: Flussdiagramm der Signalanalyseeinheit
(Filterung) werden die R-Zacken im EKG detektiert und die QRS Komplexe klassiﬁziert. Durch diese Klassiﬁzierung ist es möglich spontane und stimulierte Aktivität
des Herzens zu unterscheiden. Der Vergleich der stimulierten Frequenz mit der in
der Datenbank gespeicherten HSM-speziﬁschen BOL, ERI und EOL Magnetfrequenz
gibt Aufschluss über den Ladezustand der Batterie. Dafür ist es notwendig den sog.
Magnetstring“ zu deﬁnieren.
”
Der Magnetstring gibt vor, wie der HSM, Abhängig vom Ladezustand der Batterie,
auf die Magnetauﬂage reagiert. Da jeder HSM-Hersteller auf gewisse Sequenzen zurückgreift, können diese Strings zusammengefasst und klassiﬁziert werden (Tabelle
2.10).
Neuere HSM-Modelle der Firma Medtronic, wie etwa die Typen der Reihe Kappa“,
”
initialisieren den Beginn der Magnetauﬂage mit 3 Stimulationen der Frequenz 100
min−1 . Danach erfolgt die Stimulation mit der vom Batteriestatus abhängigen Ma-
34
2.6. SIGNALANALYSEEINHEIT
Klasse
BOL
ERI
EOL
Verlauf
Bsp.
2. Methoden
Medtronic 1
|100|100|85|85|85|85|85
|100|100|65|65|65|65|65
diskret
Kappa
Medtronic 2
|PR|PR|PR|PR|PR|PR|PR
|PR-10%|PR-10%|PR-10%
|PR-20%|PR-20%|PR-20%
diskret
Premier
Tabelle 2.10: Magnetstring
gnetfrequenz. (BOL: 85 min−1 , ERI/EOL 65 min−1 ).
Ältere Modelle, sowie vorwiegend Modelle der Firma Biotronik machen die Magnetfrequenz von der eingestellten Grundfrequenz abhängig. Der Batteriestatus BOL
wird durch asynchrone Stimulation mit der programmierten Grundfrequenz (PR)
charakterisiert. Eine Verringerung der Stimulationsfrequenz um 10 % bzw. 20 %
charakterisiert die Ladezustände ERI bzw. EOL. Die Verläufe der Magnetfrequenz
Frequenzänderung
[bpm]
0
Magnetfrequenz
(85 bpm)
-20
3,5
U_SM
[Volt]
3,5
Abbildung 2.10: Verlauf der Magnetfrequenz - Medtronic Kappa D700
Frequenzänderung
[bpm]
0
Magnetfrequenz (98,6 bpm)
-12
-30
4,0
2,0
U_SM
[Volt]
Abbildung 2.11: Verlauf der Magnetfrequenz - St. Jude Medical Integrity DR 5346
im obigen Beispiel sind diskret (Abbildung 2.10), d.h. es ist nur mit den im Magnetstring angegebenen Frequenzen zu rechnen.
Lineare Verläufe, wie sie häuﬁg HSM der Firma Pacesetter bzw. St. Jude Medical
aufweisen stellen eine große Herausforderung für die Signalanalyse dar. Gegeben ist
35
2.6. SIGNALANALYSEEINHEIT
2. Methoden
in diesem Fall die Frequenz für BOL die mit zunehmender Entladung der Batterie
linear abnimmt und dabei charakteristische Werte für ERI (86,3 min−1 ) und EOL
(68 min−1 ) durchläuft. Der Vorteil dieser Methode ist, dass in vielen Fällen von der
gemessen Magnetfrequenz direkt auf die Batteriespannung geschlossen werden kann
(Abbildung 2.11).
Die Signalanalyse, greift auf die richtigen Magnetstrings aus der Datenbank zurück
und untersucht das EKG auf Korrelation mit den jeweiligen String für BOL, ERI
und EOL. Die Korrelationskoeﬃzienten geben somit Aufschluss über den Ladezustand der Batterie.
Diese Korrelation liefert in erster Näherung sehr gute Ergebnisse. Da aber mit Toleranzen der Magnetfrequenz im Rahmen +/- 3 min−1 zu rechnen ist und in vielen
Fällen abgebrochenen Sequenzen “6 auftreten, müssen diese Strings in Zukunft dy”
namisch generiert werden, um eine höhere Fehlertoleranz zu erreichen. Ein Lösungsansatz, der im Rahmen dieser Diplomarbeit noch nicht realisiert worden ist, wird im
Kapitel 4 vorgestellt.
Die Realisierung als MatLab Applikation bietet viele Möglichkeiten der digitalen
Verarbeitung der zu analysierenden Signale. Weitere erforderliche Rechenparameter
(z.B. PR) die zur Auswertung des Signals benötigt werden, sind in der Datenbank
abgelegt und werden von der Signalanalyseeinheit automatisch geladen, wenn es der
Prozess erfordert.
6
Durch Verrutschen des Magneten wird die Stimulation mit der Magnetfrequenz unterbrochen.
36
Kapitel 3
Ergebnisse
3.1
Workflow-Analyse
In Abbildung 3.1 ist der Datenﬂuss zwischen den verschiedenen Systemkomponenten
schematisch dargestellt: Der Niedergelassene Arzt zeichnet während der Magnetauflage ein EKG auf, das online über das Webinterface an die Monitoring-Zentrale
geschickt wird. Die EKGs werden auf das Auftreten von HSM-speziﬁschen Magnetstrings untersucht, und der jeweilige Korrelationskoeﬃzient für BOL/ERI/EOL als
Ergebnis in die Datenbank eingetragen. Aus diesen Ergebnissen wird automatisch
ein Vorbefund generiert, der den aktuellen Batteriestatus und den nächsten Nachsorgetermin enthält.
Der Kardiologe begutachtet online den von der Monitoring-Zentrale vorgeschlagen
Befund, hat die Möglichkeit ihn zu editieren und sendet das Endergebnis an den
Niedergelassenen Arzt, der den Patienten kontaktiert, und mit ihm die weitere Vorgehensweise bespricht.
37
3.1. WORKFLOW-ANALYSE
3. Ergebnisse
Implantation
Aufnahme in das HSM-Nachsorgesystem
Kontrolle und HSM-Einstellung vor der Entlassung
Patientennahe
HSMNachsorge
EKG aufzeichnen
EKG speichern
EKG Übertragung
EKG Voranalyse
Benachrichtigung
Posteingang
Ja
Signalanalyse
Vorbefundung
(rr_BOL, rr_ERI, rr_EOL)
Nein
Befund
OK
Monitoring-Zentrale
Vorbefund bestätigen,
nächster Termin
Vorbefund
korrigieren,
nächster
Ternin
Einweisung in
HSM-Ambulanz
HSM-Ambulanz
Verständigung des Niedergelassenen Arztes
Verständigung des Patienten
Niedergelassener Arzt
Abbildung 3.1: Ergebnis der Workﬂow-Analyse der Patientennahen HSM-Nachsorge
38
3.2. DATENBANKDESIGN
3.2
3. Ergebnisse
Datenbankdesign
In Hinblick auf das Datenbankdesign, ergeben sich aus der Workﬂow-Analyse folgende Teilaufgaben:
• Personenverwaltung
– Patienten
– Ärzte
– Benutzerrechteverwaltung
• Signal
– Archivierung und Verwaltung der übertragenen EKGs
– Archivierung und Verwaltung der erstellten Befunde
• Pacemaker
– Umfangreichende Herzschrittmacher- und Elektrodendatenbank
– Interpretation des Magneteﬀekts in einer für die Signalanalyseeinheit verwertbaren Form
3.2.1
Datenbankdesignaspekte
Aus der Aufgabenstellung selbst und den Ergebnissen der Workﬂow-Analyse wurde
das Konzept des Datenbankdesigns abgeleitet. Es wurde auf eine relationale Datenbank zurückgegriﬀen, da sie die optimale Speicherungsmethoden für strukturierte
Datenbestände darstellt. Um das Gesamt-Datenbanksystem modular und erweiterbar zu gestallten wird es in drei Teildatenbanken aufgespaltet: PERSONS, SIGNALS
und PACEMAKER (Abbildung 3.2). Dieses modular gestaltete Konzept erlaubt die
Integration mehrerer Anwendungen, die auf ein Datenbanksystem zugreifen.
3.2.2
Persons
Der Entwurf dieser Datenbank wurde schon im Kapitel 2.4.2 ausführlich beschrieben. Da es sich um eine sehr umfangreiche Datenbankstruktur handelt, wird nur auf
die wichtigsten und für die Applikation Patientennahe HSM-Nachsorge“ relevanten
”
Teile bzw. Strukturelemente eingegangen.
39
3.2. DATENBANKDESIGN
3. Ergebnisse
SIGNALS
&
RESULTS
FILE SYSTEM
(ECG's, Figures, Reports)
PATIENTS
DEVICES
&
LEADS
Abbildung 3.2: Datenbanksystem
Personenverwaltung
Grundsätzlich wird kein Unterschied gemacht, ob eine Person ein Arzt oder ein Patient ist. Alle Personalien werden in den Tabellen PERSONS bzw. CONTACTS
festgehalten. Die Zuordnung der Person zu einem Arzt oder Patienten erfolgt in den
Tabellen PATIENTS bzw. PHYSICIAN (Abbildung 3.3). In der Tabelle ORGANISATION wird der Status des Arztes festgelegt (Niedergelassener Arzt, Kardiologe,. . . )
PERSONS
1
PK ID
PATIENTS
PK ID
PHYSICIAN
1
FK_ORG_ID
FK_PERSON_ID
C
NAME_TITLE
NAME_FIRST
NAME_LAST
BIRTH_DATE
FK_CONTACT_ID
SOCIAL_SEC_NUMBER
1
1
PK ID
C
1
1
CONTACTS
ORGANISATION
PK ID
ORG_NAME
ORG_TYPE
FK_CONTACT_ID
C
1 PK ID
ADDRESS
CITY
POSTCODE
PHONE
MOBILE
SMS
FAX
EMAIL
URL
Abbildung 3.3: Personenverwaltung
40
PAT_GENDER
PAT_IDENTIFIKATION
FK_PERSON_ID
3.2. DATENBANKDESIGN
3. Ergebnisse
Login / Benutzerrechte
In der Medizintechnik spielt der Datensicherheitsaspekt eine bedeutende Rolle. Darum ist es wichtig, auf ein sehr gut strukturiertes Benutzerverwaltungs- bzw. Aktionsrechtesystem zurückgreifen zu können. Hierzu kann das Benutzterverwaltungssystem
des Web-Servers in Betracht gezogen werden. Eine Kombination aus Server-Security
und Datenbank-Security bringt best möglichen Schutz mit sich. In Abbildung 3.4 ist
WEBSERVER
LOGIN / PASSWORT
ACCOUNTROLES
ACCOUNTS
PK
ID
REVOKED
FK_ROLES_ID
FK_ACC_ID
ACC_ACTIVE
PW_INTERVAL
SEC_LOGIN
SEC_PW
ACC_INFO
1
ROLES
1
1
C
N PK ID
ROLE_NAME
ROLE_INFO
1
N
MENUE_DOC
PK
ID
MENUE_ITEM
1
N
PK
FK_ACC_ID
FK_MENUE_ITEM_ID
ACTIVE
ACTION_DOC
N
ID
NAME
OUTORDER
MENUELEVEL
ACTIONS
1
N PK ID
ID
FK_ACC_ID
FK_ACTION_ID
ACTIVE
ACTION_NAME
APP
Abbildung 3.4: Kombination aus Web-Server-Security und Datenbank-Security
der strukturelle Zusammenhang zwischen Web-Server-Security und Datenbank dargestellt. Jedem Benutzer wird ein Account zugewiesen, der wiederum an deﬁnierte
Rollen gebunden ist (Arzt, Patient, Datenbank-Manager,. . . ). Parallel zur Datenbank wird dieser Benutzer auch direkt im Benutzerverwaltungssystem des WebServers mit Login und Passwort angelegt.
Beim Login wird der Benutzer aufgefordert seinen Loginnamen und sein Passwort
einzugeben. Erst nach dem Vergleich der Logininformationen im Web-Server- sowie
Datenbank-Benutzerverwaltungssystem wird eine Session gestartet oder der Zugang
verweigert.
Nach erfolgreichem Login wird die Oberﬂäche den Benutzerrechten entsprechend
aufgebaut. Die Information, welche Komponenten die vom Web-Server dynamisch
aufgebaute Seite enthalten darf, werden aus der Datenbank (Tabelle MENUE DOC)
gelesen. Die Ordnung der entsprechenden Menüelemente kann in der Spalte OUTORDER festgelegt werden. Jedem Menüeintrag ist eine Zahl zugeordnet, nach der beim
41
3.2. DATENBANKDESIGN
3. Ergebnisse
Abrufen der Information sortiert werden kann.
Um Aktionen durchführen zu können, wie z.B. einen Befund zu generieren, ist ebenfalls eine Berechtigung erforderlich. In der vom Web-Server dynamisch generierten
Webseite werden weiterführende Verknüpfungen nur dann dargestellt, wenn die entsprechenden Rechte vorhanden sind. Diese Rechte werden in der Tabelle ACTION DOC dem jeweilig eingeloggten Benutzer zugewiesen.
Die Zugriﬀsrechte werden nach erfolgreichem Login einmalig von der Datenbank geladen und in Sessionvariablen [27] abgespeichert.
Durch dieses Benutzerverwaltungskonzept ist eine individuelle Gestaltung der Benutzeroberﬂäche, entsprechend den Benutzterrechten und der ausgewählten Applikation
möglich.
3.2.3
Signals
Die Aufgabe der Signaldatenbank ist die Verwaltung bzw. die Bereitstellung der
aufgenommenen EKGs. In der zentralen Tabelle SIGNALS (Abbildung 3.5) werden
neben den Signalparametern ( Aufnahmedatum, Dateigröße,. . . ) noch wichtige Informationen bezüglich Speicherort und Datenübertragung (Übertragungszeit, Dauer,. . . ) abgelegt.
Die Art der Speicherung der Signale hat wesentliche Auswirkungen auf die Struktur
der Datenbank und deren Performance. Hauptanforderungen die Datenbankstruktur ist die Kaskadierbarkeit, da davon ausgegangen werden muss, dass in weiterer Folge mit größeren Datenmengen zu rechnen ist. Fallen etwa bei einer HSMNachsorgeuntersuchung Signaldaten im 1 MB Bereich an, so muss man bei einem 24
h EKG, wie es bei der PAF-Analyse verwendet wird, mit Datenmengen von 70 MB
und mehr rechnen.
Blob vs. Dateisystem
In der Literatur ﬁndet man mehrere Lösungsansätze für die Speicherung großer
Dateien [39]. Für den Fall, dass die Rohdaten in ASCII Format vorliegen scheint
es naheliegend, diese Daten direkt in die Datenbank zu schreiben, bzw. einen Datenstring zu generieren und diesen zu speichern. Dies würde aber einen enormen
Zuwachs der Datenbankgröße nach sich ziehen. Gleiches gilt für die Umwandlung
des ASCII Formates in ein Binärdatei und dessen Speicherung als Datentyp BLOB
(Binary Large Objekt).
Aus diesem Grund wurde die Speicherung in einem externen Dateisystem als Lösung
42
3.2. DATENBANKDESIGN
3. Ergebnisse
SIG_PM
Signals
PK
ID
1
1
REPORT
PK ID
PK ID
PM_ID
PR
PM_MODE
SIG_NAME
SIG_EXT
SIG_ROOT
SIG_PATH
PP_STUDY
RESULTS
PRIORITY
COMPRESSED
FK1 FK_SIG_PM_ID
FK2 FK_SIG_DAQ
AVAILABLE
DONE
DATUM
STATUS
NEXT_EXAM
HR
COMMENT
1
1
RES_HSM
C
1
1
DAQ
PK ID
Name
Type
1 PK
ID
FK1 FK_REPORT_ID
FK2 FK_SIG_ID
HSM_PR
HSM_BOL_CCMAX
HSM_ERI_CCMAX
HSM_EOL_CCMAX
HSM_FIG
Abbildung 3.5: Struktur der Signal-Datenbank
realisiert. Die Daten werden von der Datenbank entkoppelt, es wird nur der Pfad zu
den Daten in der Datenbank abgelegt. Dies bedeutet folgende Vorteile:
• Überschaubare Größe der Datenbank
• Entkopplung, damit können auch andere Anwendungen direkt auf die Daten
zugreifen
• Daten können ohne vorherige Bearbeitung direkt abgespeichert werden
• Daten können separat gesichert werden
Von der EKG-Übertragung bis zum fertigen Befund
Die EKG Übertragung wird vom Web-Server gestartet. Der Patient wird über die
HSM-Seriennummer identiﬁziert und das entsprechende EKG mit einer Dialogbox
zur Übertragung an die Monitoring-Zentrale ausgewählt. Nach Bestätigung der EKGÜbertragung wird ein Automatisierungsprozess gestartet, der die EKG-Übertragung
kontrolliert, Datenbankeinträge veranlasst und die Signalanalyse startet.
Uploadverzeichnis:
Bevor die EKG-Übertragung gestartet werden kann, muss vom Web-Server ein Verzeichnis im Dateisystem des Servers generiert werden. Diese Aufgabe übernimmt
43
3.2. DATENBANKDESIGN
Erweiterung
EMF
GIF
PDF
PS
SIG
TXT
ZIP
3. Ergebnisse
Inhalt
EKG-Graﬁk
EKG-Graﬁk
REPORT
EKG-Graﬁk
Ergebnisdatei
EKG-Rohdaten
Komprimiertes EKG
Prozess
Signalanalyse
Signalanalyse
Report Generator
Signalanalyse
Signalanalyse
EKG-Übertragung
EKG-Übertragung
Tabelle 3.1: Anfallende Dateitypen
ein Modul (Python Skript) des Web-Servers, das einen direkten Zugriﬀ auf das Dateisystem des Servers erlaubt. In diesem Ordner werden alle zum EKG anfallenden
Daten wie Bilder, PDF-Reports und Reportdateien der Signalanalyse abgelegt. Die
anfallenden Ergebnisdateien übernehmen den Dateinamen des EKG’s, es ändert sich
nur die Datei-Erweiterung (Tabelle 3.1).
Die Organisation der anfallenden Dateien ist in Abbildung 3.6 dargestellt: Die Daten-
Abbildung 3.6: Organisation der Daten im Dateisystem des Servers
bankeinträge SIG NAME, SIG ROOT und SIG PATH werden nach erfolgreichem
Erstellen des Verzeichnisses angelegt. Über diese Informationen kann in weiterer
Folge die Signalanalyseeinheit, auf das jeweilige EKG zugreifen.
Komprimierung:
Um eine wesentliche Geschwindigkeitssteigerung der EKG-Übertragung zu erreichen,
ist es möglich eine komprimierte Datei (ZIP) an den Web-Server zu senden. Ein
Modul des Web-Servers erkennt ankommende komprimierte Dateien als solche und
44
3.2. DATENBANKDESIGN
3. Ergebnisse
startet den Dekomprimierungsprozess. Die dekomprimierte Datei wird im Dateisystem gespeichert und die notwendigen Datenbankeinträge werden getätigt.
Start der Signalanalyse:
Nach erfolgreicher EKG-Übertragung, wird das Flag AVAILABLE auf 1 gesetzt,
und damit der Signalanalyseeinheit signalisiert, dass das EKG zur Bearbeitung bereit liegt. Die Signalanalyseeinheit kann auf die Datei im Dateisystem zugreifen und
diese bearbeiten, wobei die Pfadinformationen aus der Datenbank gelesen wird. Die
Information mit welchem MatLab Modul die Datei zu analysieren ist, ist in der Tabelle SIGNALS / PP STUDY gespeichert.
Nach erfolgreicher Bearbeitung und Analyse des EKG’s wird das Flag DONE auf 1
gesetzt, die Ergebnisse und Parameter der Analyse (Korrelationskoeﬃzienten, Analysedauer,. . . ) in den Tabellen SIGNALS bzw. RES HSM eingetragen und anfallende
Ergebnisdateien im Dateisystem abgelegt.
Die zur Signalanalyse zusätzlich erforderlichen Parameter werden aus der Tabelle
SIG PM geladen. Im Fall der Patientennahen HSM-Nachsorge handelt es sich dabei
um HSM-Daten (Pacing Rate,. . . ).
Report:
Von der Signalanalyse fertig bearbeitete Dateien werden im Posteingang “ (Abbil”
dung 3.1) dem Spezialisten in der HSM-Ambulanz zur Begutachtung vorgelegt. Die
HTML Report
ReportLab
Datenbank
PDF - File
Abbildung 3.7: Blockdiagramm: Report
Daten können online abgerufen werden. Neben den Analyseergebnissen werden alle
zum EKG gehörigen Daten, wie Patientendaten, HSM-Daten und Ergebnisse dargestellt. Es ist auch möglich, in das aufgezeichnete EKG einzusehen (Abbildung 3.8).
Zur Evaluierung werden die Ergebnisse der Signalanalyse getrennt von dem Befund
des Kardiologen gespeichert. Die Erzeugung eines schreibgeschützten PDF-Befunds
45
3.2. DATENBANKDESIGN
3. Ergebnisse
Abbildung 3.8: Analysiertes EKG mit Kennzeichnung der maximalen Korrelation
übernimmt die Web-Serverkomponente - ReportLab. Diesem Modul werden die ID’s
der im Befund abzubildenden Datensätze der Datenbank übergeben. Ein PythonSkript veranlasst die benötigten Datenbank-Zugriﬀe und stellt die abgerufenen Daten, sowie den abzubildenden EKG-Ausschnitt bereit. Der generierte Befund, der
alle wichtigen Parameter und das aufgezeichnete EKG enthält, wird im Dateisystem
abgespeichert und kann in weiterer Folge von autorisierten Benutzern über die Benutzeroberﬂäche eingesehen werden. Es ist auch möglich den Befund direkt an den
Niedergelassenen Arzt als E-Mail oder Fax zu versenden.
46
3.2. DATENBANKDESIGN
3.2.4
3. Ergebnisse
Pacemaker
In diesem Teil des Datenbank-Systems sind alle technischen Daten der verschiedenen
HSM-Modelle und Elektrodentypen gespeichert. Die Aufnahme der Daten von mehr
als 1000 HSM von über 20 Herstellern erfolgte aus der online abrufbaren Datenbank
von Heartweb [17].
Die Speziﬁkation eines HSM umfasst, je nach Modell, zwischen 100 und 150 Parameter, die größtenteils mittels HSM-Programmiergerät einstellbar sind. Von besonderem Interesse sind die Werte BOL, ERI und EOL im Magnetmode. Diese Werte
sind in der Tabelle PACEMAKER abgelegt. Die genauere Speziﬁkation des Magneteﬀekts erfolgt in der Tabelle MAGNET MODES über den sogenannten Magnet”
string“ (Kapitel 2.6).
PACEMAKER
PK
MAGNET_MODES
ID
PK ID
FK1 FK_MAN_ID
PM_MODELL
PM_NAME
FK2 FK_MAGNET_MODES
BOL_MAGNET
ERI_MAGNET
EOL_MAGNET
ID
N
1
MAGNET_NAME
MAGNET_STRING_BOL
MAGNET_STRING_ERI
MAGNET_STRING_EOL
VERLAUF
C
LEADS
PK
1
MANUFACTURES
PK ID
1
C
MAN_NAME
MAN_CONTACT
ID
FK1 FK_MAN_ID
LEAD_MODEL
LEAD_TYPE
FIXATION
POLARITY
PLACEMENT
CONNECTOR
Abbildung 3.9: Auszug aus der HSM-Datenbank
3.2.5
Datenbankzusatzfunktionen
Schon in der ersten Designphase wurde darauf geachtet, wichtige Zusatzfunktionen,
die nicht im direkten Zusammenhang mit der Applikation stehen, in das Konzept
einzubinden. Diese Funktionen dienen größtenteils der Benutzerverwaltung bzw. der
statistischen Auswertung der Ergebnisse.
47
3.2. DATENBANKDESIGN
3. Ergebnisse
Log-Einträge
In Datenbankanwendungen ist es notwendig, jeden die Datenbank verändernden Zugriﬀ (INSERT, UPDATE, DELETE) zu protokollieren um eventuelle Fehleingaben
rückgängig machen zu können. Dieses Protokollierungs- und Wiederherstellungskonzept ist in Abblidung 3.10 dargestellt. Bei jedem neuen Eintrag (INSERT) wird die
PACEMAKER_LOG
PK ID
PM_ID
FK_MAN_ID
PM_MODELL
PM_NAME
FK_MAGNET_ID
BOL_MAGNET
ERI_MAGNET
EOL_MAGNET
STATUS
FK_CREATE_USER
CREATE_HOST
CREATE_DATI
FK_MODIFY_USER
MODIFY_HOST
MODIFY_DATI
PACEMAKER
PK ID
FK_MAN_ID
PM_MODELL
PM_NAME
FK_MAGNET_ID
BOL_MAGNET
ERI_MAGNET
EOL_MAGNET
FK_CREATE_USER
CREATE_HOST
CREATE_DATI
FK_MODIFY_USER
MODIFY_HOST
MODIFY_DATI
ACCOUNTS
PK ID
ACC_ACTIVE
PW_INTERVAL
SEC_LOGIN
SEC_PW
ACC_INFO
Abbildung 3.10: Log-Tabelle
ACCOUNT-ID, die als Sessionvariable vom Webserver mitgeführt wird, an die Datenbank übergeben und im Datensatz gespeichert (FK CREATE USER). Über die
ACCOUNT-ID ist sichergestellt, dass jede Änderung einem Benutzer zuzuordnen
ist. Zusätzlich wird noch ein Timestamp“, der das Erstellungsdatum und Uhrzeit
”
enthält, erstellt.
UPDATE und DELETE Anweisungen werden gleich behandelt. Zusätzlich wird,
bevor die Anweisung ausgeführt wird, eine exakte Kopie des nicht mehr aktuellen
Datensatzes in einer Log-Tabelle“ gespeichert. Die Log Tabelle“ ist eine Duplikat
”
”
der Haupttabelle“, erweitert um das STATUS Feld, in dem festgehalten wird, ob
”
es sich bei der Modiﬁkation um eine DELETE oder UPDATE Aktion gehandelt
hat. Durch dieses Konzept werden ausreichend Informationen gespeichert um jede
Datenbank-Modiﬁkation nachzuvollziehen und ggf. rückgängig zu machen.
48
3.2. DATENBANKDESIGN
3. Ergebnisse
Web-Log
Um Benutzteraktionen, die nicht mit Datenbankeinträgen verbunden sind, sichtbar
zu machen, wurde eine Webserverkomponente entwickelt, die in jede Webseite integrierbar ist. Diese Komponente sendet bei jedem Seitenaufruf die ACCOUNT ID
des eingeloggten Benutzers, sowie den Namen der aufgerufenen Seite an die Datenbank. Diese Informationen werden in der Tabelle USER LOG gespeichert. Dadurch
ist es möglich, jede Aktion des Benutzers nachzuvollziehen. Diese aufgenommenen
Daten können dazu verwendet werden, um das System bzw. die Benutzeroberﬂäche
optimal den Benutzerbedürfnissen anzupassen.
USER_LOG
PK ID
ACC_ID
DATE
LOGTIME
AKTION
Abbildung 3.11: Log-Tabelle der aufgerufenen Seiten
Papierkorbfunktion
Der Benutzer kann für ihn nicht mehr relevante Daten ausblenden ohne sie aus der
Datenbank zu löschen. Dabei wird im jeweiligen Datensatz das VISIBLE Flag auf 0
gesetzt (Abbildung 3.12).
Patient
PK
ID
Vorname
Nachname
Geb.Dat.
SVNr.
VISIBLE
Abbildung 3.12: Papierkorbfunktion
49
3.3. KLINISCHE STUDIEN
3.3
3. Ergebnisse
Klinische Studien
Die Aufnahme des Zweikanal-Oberﬂächen EKG’s erfolgte mit dem PC-EKG System
Cardio Perfect MD 1200 Hz (Kapitel 2.3.1). Die besten Ergebnisse wurden erzielt,
indem die Elektroden in der Nähe des Schlüsselbeines bzw. an der Hüfte des Patienten 1 platziert wurden.
Die EKG-Messung wurde parallel zu der des Kardiologen mittels Programmiergrät
durchgeführt. Somit kann sichergestellt werden, dass die Ergebnisse der Untersuchung genau mit dem aufgenommenen EKG übereinstimmen.
Der Befund des Kardiologen wurde mittels Programmerausdruck dokumentiert.
3.3.1
Klinische Vorstudie - Mai 2002
Die ersten klinischen Probemessungen wurden im Mai 2002 an 27 Patienten durchgeführt. Dabei wurden 45 Magnet EKGs von verschiedenen HSM-Modellen aufgenommen. Aus den Ergebnissen konnten einerseits der Algorithmus zur Signalanalyse optimiert werden und andererseits wichtige Parameter, die EKG-Übertragung
und den Magnetstring betreﬀend, erarbeitet werden. Aus den erhobenen Testdaten
wurden folgende Regeln für die Deﬁnition des Ladezustandes der Batterie aus den
berechneten Korrelationskoeﬃzienten(rr BOL, rr ERI, rr EOL) ermittelt:
BOL:
ERI/EOL:
kein Ergebnis:
rr BOL
>0.67
<0.67
<0.67
rr ERI
<0.67
>0.67
<0.67
rr EOL
<0.67
>0.67
<0.67
Tabelle 3.2: Regeln zur Beurteilung des Ladezustandes der Batterie anhand der
berechneten Korrelationskoeﬃzienten
3.3.2
Klinische Vergleichsstudie - November 2002
Nach erfolgreicher Implementierung der Web-Server und Datenbankkomponenten
wurden im November 2002 weitere klinische Vergleichsuntersuchungen durchgeführt,
um das System Patientennahe HSM-Nachsorge“ im Parallelbetrieb mit den in der
”
Klinik verfügbaren Systemen evaluieren zu können. Die aufgenommenen Signale wurden online an die Monitoring-Zentrale gesendet und automatisch ausgewertet dh. es
wurden die Korrelationskoeﬃzienten für BOL, ERI und EOL der Magnetstrings mit
dem Signal ermittelt.
Bei dieser prospektiven Studie wurden an vier aufeinanderfolgenden Tagen 76 EKG’s
1
Patient aufrecht sitzend, Füße am Boden
50
3.3. KLINISCHE STUDIEN
3. Ergebnisse
von 36 Patienten aufgenommen. Sind einem Patienten mehrere EKG’s zuzuordnen,
wurde das Signal mit dem höchsten Korrelationskoeﬃzienten für die Auswertung
herangezogen.
Die Untersuchung umfasste 19 verschiedene HSM-Modelle von 6 verschiedenen Herstellern (Tabelle 3.3), wobei die mittlere Implantationsdauer 43 +/- 33 Monate betrug.
Anzahl
9
5
4
8
6
4
HSM-Hersteller
Biotronik
ELA
Intermedics
Medtronic
St. Jude
Vitatron
Type
Actros, Nanos, Philos
Talent
Dash, Unity, Strite, Relay
Kappa, Legend, Thera, Minix, Sigma
Integrity, Identity, Aﬃnity
Clarity, Diamond, Selection
Tabelle 3.3: Untersuchte HSM
Ein Patient konnte nicht berücksichtigt werden, da es Probleme mit der Telemetrieeinrichtung gab. Bei zwei Patienten wurde die Kontrolluntersuchung vor der Entlassung durchgeführt und die HSM-Parameter eingestellt.
Der Vergleich der Ergebnisse HSM-Programmiergerät/Patientennahe HSM-Nachsorge
ist in Tabelle 3.4 dargestellt.
EOL/ERI
1
2
HSM-Programmiergerät
Patientennahe HSM-Nachsorge
BOL
34
29
kein Ergebnis
0
3
Tabelle 3.4: Vergleich der Ergebnisse zwischen HSM-Programmiergerät und Patientennaher HSM-Nachsorge
3.3.3
Statistische Auswertung
Die Ergebnisse der statistischen Auswertung des Systems sind in den Tabellen 3.5
dargestellt.
HSM-Programmiergerät
EOL/ERI
BOL
Patinennahes HSM-Nachsorgesystem
EOL/ERI
BOL
1
0
5
29
Tabelle 3.5: Vierfeldertafel zum diagnostischen Test der Vergleichsstudie
51
3.3. KLINISCHE STUDIEN
3. Ergebnisse
Aus den Werten der Tabelle 3.5 können folgende statistische Parameter [41] berechnet werden:
• Prävalenz: 0,03
In 0,03 % der Fälle wurde vom HSM-Programmiergerät EOL/ERI erkannt.
• Positiver Vorhersagewert: 0.167
• Negativer Vorhersagewert: 1
Das Ergebnis zeigt, dass das Patientennahe HSM-Nachsorge System einen Negativen
Vorhersagewert (NPV) von 100 % und einen Positiven Vorhersagewert (PPV) von
16,7 % für die Erkennung von ERI bzw. BOL aufweißt.
Das heißt, dass das System alle Patienten erkannt hat, deren HSM ERI bzw. EOL
Indikation zeigten und dass all jene Patienten, bei denen das System eine normale
Funktion ergeben hat, auch tatsächlich eine normale Funktion aufgewiesen haben.
Das ist besonders wichtig, da das Verfahren als Screening-Methode eingesetzt werden soll.
Die Ergebnisse der vorliegenden Vergleichsstudie zeigen, dass mit Unterstützung des
Patientennahen HSM-Nachsorgesystems etwa 80 % der Nachsorgeuntersuchungen im
Rahmen einer Basisuntersuchung vom Niedergelassenem Arzt durchgeführt werden
hätten können.
52
Kapitel 4
Diskussion
In der Diplomarbeit wurde ein herstellerunabhängiges HSM-Nachsorgesystem prototypisch entwickelt, das die Vorteile, die die neue Internettechnologie bietet in sich vereint. Durch die Kollaboration zwischen Niedergelassenem Arzt und HSM-Ambulanz
ist der Patient nicht mehr gezwungen, die HSM-Nachsorge in der Klinik durchführen
zu lassen. Dies führt zu einer erheblichen Entlastung des Patienten und der HSMAmbulanz. Es gibt jedoch Parameter, die erfüllt sein müssen um das System in der
bisherigen Form anwenden zu können:
• Der Magneteﬀekt des HSM muss auf asynchron programmiert sein. D.h.: Bei
Magnetauﬂage stimuliert der HSM mit der Magnetfrequenz unabhängig von
der eingestellten Grundfrequenz.
• Der Patient, der HSM, sowie der Magnetstring des entsprechenden HSM müssen im System aufgenommen sein. Die Aufnahme der HSM-speziﬁschen Parameter erfolgt zur Zeit per Hand. In Zukunft sollte eine Kooperation mit den
HSM-Herstellern angestrebt werden, die durch ein standatisiertes Eingabesystem, die HSM-Datenbank auf dem neuesten Stand halten können.
• Obwohl der entwickelte Prototyp sehr gute Testergebnisse liefert sind noch
Verbesserungen bei der Deﬁnition des Magneteﬀekts als Magnetstring“ not”
wendig, um das System fehlertoleranter“ zu gestalten.
”
In Zukunft gilt es einen Magnetstring zu deﬁnieren, der in seiner Länge variieren kann. Dies ist notwendig, da man mit EKG-Sequenzen, unterschiedlicher
Länge rechnen muss. Ein Magnetstring ﬁxer Länge, würde bei unterschiedlicher
Länge der EKG-Sequenz1 , zu verschiedenen Korrelationskoeﬃtienten führen.
Um ein aussagekräftiges Ergebnis der Signalanalyse zu berechnen muss der
Algorithmus in der Lage sein, den Magnetstring dynamisch an die Länge der
1
Relevant ist nur der Teil des EKG’s, in dem der HSM mit der Magnetfrequenz stimuliert
53
4. Diskussion
EKG-Sequenz anzupassen. Weiters müssen auch die Toleranzen der Magnetfrequenz im Magnetstring enthalten sein. Ein Magnetstring der allen Anforderungen gerecht wird, könnte aus folgenden Parametern generiert werden:
– Magnetfrequenz für BOL, ERI und EOL
– Toleranzen der Magnetfrequenz
– Charakteristische Frequenzmuster z.B. Medtronic, Kappa: Initialisierung
des Beginns der Magnetauﬂage durch drei Stimulationen mit einer Frequenz von 100 min−1 .
– AV-Zeiten
– Stimulationsamplitude
• Der Patient wird direkt nach der HSM-Implantation im System aufgenommen. Da im ersten Jahr nach der Implantation mit Veränderungen der HSMParameter zu rechnen ist, ist es wichtig, diese Veränderungen auch im HSMNachsorgesystem aufzunehmen. Falsche bzw. nicht aktualisierte HSM-Parameter
führen zu einer nicht korrekten Auswertung des EKG’s.
• Die EKG-Aufzeichnung erfolgt mit einem ausgewählten, handelsüblichen PCEKG-System. Die Abtastrate des EKG Aufnahmesystems muss mindestens
1000 Hz betragen, um eine richtige Detektion und Klassiﬁkation der stimulierten QRS Komplexe zu garantieren. Es ist zu prüfen, in wieweit PC-EKGSysteme anderer Hersteller mit eventuell geringerer Abtastrate eingesetzt werden können, ohne das Ergebnis der Signalanalyseeinheit negativ zu beeinﬂussen.
Um die Mobilität Niedergelassener Ärzte insbesondere bei der Durchführung der
Nachsorge in Pﬂege- und Seniorenheimen zu unterstützten, ist die Entwicklung eines speziellen, mobilen EKG-Systems zur Durchführung der Patientennahen HSMNachsorge geplant.
Die Einführung der Patientennahen HSM-Nachsorge ist, nach erfolgreicher Evaluierung an mehreren Kliniken, vor allem im ländlichen Bereichen geplant, da die dort
betroﬀenen Patienten derzeit für die regelmäßige Nachsorgeuntersuchung besonders
weite Anfahrtswege in Kauf nehmen müssen.
54
Kapitel 5
Ausblick
Die viel versprechenden Ergebnisse der ersten Pilotstudie zeigen das enorme Potential, dass das neue System zur Basisnachsorge in sich verbirgt. Bevor das System
routinemäßig eingesetzt werden kann, müssen folgende weiterführenden Arbeiten
durchgeführt werden:
• Zur klinischen Evaluierung des Systems ist eine erweiterte Vergleichsstudie mit
der derzeitigen Standardmethode an einer repräsentativen Patientengruppe
notwendig.
• Da es sich bei medizinischen Daten um sensible Daten handelt, müssen besondere Vorkehrungen hinsichtlich Datenschutz getroﬀen werden.
• Durch den Einsatz der Patientennahen HSM-Nachsorge“ an verschiedenen
”
Kliniken, müssen weitere Testdaten gesammelt werden, um den Workﬂow sowie
die Signalanalyse zu verbessern.
55
Literaturverzeichnis
[1] Berliner Ärztekammer. Herzschrittmacher Nachsorge Richtlinien. WWW, Dezember 2002. http://www.kvberlin.de.
[2] Statistik Austria. Jahrbuch der Gesundheitsstatistik. Bundeszentralamt Statistik Austria, Vienna, 2000.
[3] M.A. Azim, F.E.Z. Abou-Chadi, H.M. Bakr, and H.H. Soliman. Design and
Development of an annotated ECG Database. 18th National Radio Science
Conference, pages 661–667, 2001.
[4] V. Barbaro, P. Bartolini, and R. Bernarducci. A portable unit for remote monitoring of pacemaker patinets. Journal of Telemedicine and Telecare, 3:96–102,
1997.
[5] R. Bellazzi, S. Montani, A. Riva, and M. Stefanelli. Web-based telemedicine
systems for home-care: technical issues and experiences. Computer Methods and
Programs in Biomedicine, 64:175–187, 2001.
[6] A.D. Bernstein. Pacemaker pulse generators: Some technical fundamentals.
Cardiac Electrophysiology Review, 3:15–19, 1999.
[7] Biotronik. Philos, Produktbeschreibung. Biotronik GmbH, 2000.
[8] Brentwood by Midmark. PDA-ECG Produktbeschreibung. WWW, Dezember
2002. http://www.brentwoodmed.com/noﬂash/pda.html.
[9] P. Chen. The Entity-Relationship Model: Towards a uniﬁed view of data. ACM
Transactions on Database Systems, 1:9–36, 1976.
[10] E. F. Codd. A relational model of data for large shared data banks. CACM,
13(6):377–387, 1970.
[11] Active Corporation. ActiveECG Produktinformation. WWW, Dezember 2002.
http://www.activecenter.com/products.html.
56
[12] Zope Corporation.
Zope customer list.
www.zope.com/ZopeClientList/index html.
WWW, Dezember 2002.
[13] D. Deutsch. The big deal about standards. Oracle Magazine, 2002.
[14] A. Din. Structured Query Language (SQL). Blackwell Publishers, 1994.
[15] Dr. Vetter Distribution. EKG Light Produktinformation. WWW, Dezember
2002. http://www.pc-ekg.info/menue.htm.
[16] JD Fraser, AM Gillis, ME Irvine, S Nishimura, GFO Tyers, and F Philippon.
Guidlines for pacemaker follow-up in Canada: A consensus statement of the
canadian working group on cardiac pacing. Can J Cardiol, 16(3):355–363, March
2000.
[17] S. Furman and A.Mercando. Heartweb Pacemaker Database. WWW, Dezember
2002. http://www.heartweb.org/heartweb/pulsegen.htm.
[18] getemed Medizin-und Informationstechnik AG. Cardiomem Produktbeschreibung. WWW, Dezember 2002. http://www.getemed.net.
[19] G.Fröhlig, B.Lemke, and W.Koglek. Herzschrittmacher- und Deﬁbrillatortherapie. Thieme, 2002.
[20] Biotronik GmbH. Philos DR-T Produktinformation. WWW, Dezember 2002.
http://www.biotronik.com/content/detail.php?id=1777.
[21] CAM Hooijschuur, WA Dijk, and WRM Dassen. Pacemaker registration by
E-Mail. Computers in Cardiology, 24(0276-6547/97):581–584, 1997.
[22] Inc. Integrated Medical Devices. The IMD PSD 410 Pacemaker Transmitter.
WWW, Dezember 2002. http://www.integrated-medical.com/imdpsd.htm.
[23] W. Kainz. Richtlinien zur Nachsorge antibradykarder Schrittmachersysteme. J
Kardiol, pages 15–18, 1999.
[24] K.Palme. Aufbau einer Datenbank. R. Oldenbourg Verlag.
[25] F.M. Kusumoto and N. Goldschlager. Cost-eﬀective follow-up of the patient
with a permanent pacemaker. Cardiac Electrophysiology Review, 3:60–65, 1999.
[26] M.S. Lampadius. Herzschrittmacher-Typenkartei. FGS-Forschungsgesellschaft
Elektrostimulation m.b.H., 2002.
[27] A. Latteier and M. Pelletier. The ZOPE Book - Covers Zope 2.5. New Riders
Publishing, 2000.
57
[28] B. Lemke, W. Fischer, and H. Schulten. Richtlinien zur Herzschrittmachertherapie; Indikationen, Systemwahl, Nachsorge. Z. Kardiol, (85):611–628, 1996.
[29] H. Lovell, F. Magrabi, B.G. Celler, K. Huynh, and H. Garsden. Web-Based
Acquisition, Storage, and Retrieval of Biomedical Signals. IEEE Engineering
in Medicine and Biology, (0739-5175):38–44, May/June 2001.
[30] M. Lutz. Programming Python. OReilly Associates, Cambridge, 2 edition, 2001.
[31] F. Magrabi, N.H. Lovell, and B.G. Celler. A web-based approach for electrocardiogram monitoring in the home. International Journal of Medical Informatics,
(54):145–153, 1999.
[32] St. Jude Medical. Frequenzadaptive Zweikammer-Herzschrittmacher, Produktbeschreibung. St. Jude Medical, Inc, 2000.
[33] Inc. Medtronic. Follow-up: Telephone Monitoring. WWW, Dezember 2002.
http://www.medtronic.com/brady/patient/follow up phone.html.
[34] O. Merl, R. Peschorn, M. Nürnberg, and K. Steinbach. Austrian Pacemaker
Registry: improving reporting compliance in 60 center national registry. Computers in Cardiology, 26(0276-6547):317–318, 1999.
[35] B. Nowak. Trends in der Schrittmachertherapie. J Kardiol, 8:379–383, 2001.
[36] Cardio Control NV. Cardio Perfekt Resting ECG Produktbeschreibung.
WWW, Dezember 2002. http://www.cardiocontrol.com.
[37] C. Peer. Ein System zur automatischen Langzeit EKG Fernanalyse. 2003.
[38] A. Pepino, M. Bracale, and L. Argenziano. A pilot experience in south of Italy
for the remote follow-up of patients with implanted pacemaker. Proceedings of
the 22nd Annual EMBS International Conference, pages 2286–2287, 2000.
[39] I. Prenosil. Whether to store string in BLOB, or CHAR, or VARCHAR. WWW,
Dezember 2002. http://www.volny.cz/iprenosil/interbase/ip ib strings.htm.
[40] G. Saake and K. Sattler. Datenbanken und JAVA. dpunkt.verlag.
[41] Sachs. Angewandte Statistik - Auswertung Statistischer Methoden. SpringerVerlag, 1990.
[42] G. Schlageter and W. Stucky.
B.G.Teubner Stuttgart.
Datenbanksysteme: Konzepte und Modelle.
58
[43] G. Schreier, P. Kastner and W. Marko. An Automatic ECG Processing Algorithm to Identify Prone to Paroxysmal Aterial Fibriallation. Computers in
Cardiology, 8:379–383, 2001.
[44] H. Schwinn. Relationale Datenbanken. Hanser Studienbücher der Informatik.
[45] Vitatron. Clarity, Produktbeschreibung. Vitatron GmbH, 2000.
[46] J. Wollert. Das Bluetooth-Handbuch. Franzis, 2002.
[47] Herz Zentrum Hirslanden Zürich. HERZSCHRITTMACHER - STATISTIK
2000. HerzZentrum Hirslanden Zürich, 2000.
[48] Deutsches Zentralregister Herzschrittmacher GmbH. Jahresbericht 1999. Deutsches Zentralregister Herzschrittmacher GmbH.
59
Index
Klinische Studien, 50
Komprimierung, 44
Korrelationskoeﬃzienten, 36
Änderungs-Anomalie, 27
Ankerelektroden, 2
Assoziationen, 30
Litium-Ionen-Batterien, 3
LocalFS, 20
Log-Einträge, 48
Lösch-Anomalie, 27
Benutzterrechten, 42
Benutzterverwaltungssystem, 41
BlueTooth, 9
BOL, 4
Magnet Charakteristik, 4
Magnet-Mode, 3
Magnetstimulationsfrequenz, 4
Magnetstring, 34
Menüelemente, 41
Cardio Control Workstation, 17
Data Control Language, 25
Data Deﬁnition Language, 24
Data Manipulation Language, 25
Dateisystem, 42
Datenbankdesign, 39
Datenbankentwurf, 25
Dritte Normalform, 28
DTML-Skripts, 20
Negativer Vorhersagewert, 52
Normalformlehre, 25
ODBC, 23
Papierkorbfunktion, 49
PDF-Befunds, 45
PIL, 21
Positiver Vorhersagewert, 52
Primärschlüssel, 27
Produktrecherche, 8
Prävalenz, 52
Python-Skripts, 20
Einfüge-Anomalie, 27
EOL, 4
ER-Modell, 30
ERI, 4
Erste Normalform, 26
Exceptions, 22
Fremdschlüssel, 29
Report, 45
ReportLab, 21
gvibDB, 20
Home Care, 8
HSM-Programmiergerät, 13
Schraubelektroden, 2
Signalanalyse, 22
SQL, 24
Statistische Auswertung, 51
Stored Procedures, 21
InterBase, 21
Kardinalität, 30
60
Telefonadapter, 9
Telemedizin, 6
Trigger, 21
Uploadverzeichnis, 43
Vergleichsstudie, 50
Vorgegebene HSM-Parameter, 53
Vorstudie, 50
Weiterführende Arbeiten, 55
WLAN, 9
Workﬂow-Analyse, 13
ZOPE-Web-Server, 20
Zweite Normalform, 27
61