Patientenreminder

Preprint 02 – 06
Patientenreminder
Bernd Dusemund
Thomas Engel
Christoph Meinel
ISSN 1433-8106
Institut für Telematik e.V., Bahnhofstr. 30-32, D-54292 Trier, Telefon +49 (0)651-97551 0.
Die Verarbeitung oder Vervielfältigung der Inhalte/Daten in jedweder Form ist ausschließlich mit schriftlicher Zustimmung des Instituts für Telematik
gestattet. Die Wiedergabe von Inhalten ist nur bei Nennung der Quelle erlaubt.  2002 Institut für Telematik e.V.
Preprint Patientenreminder
Author
Bernd Dusemund
Dr. rer. nat.
Thomas Engel
Prof. Dr. rer. nat.
Christoph Meinel
Univ. –Prof. Dr. sc.
Copyright
© 2002
Institut für Telematik e.V., Trier
Trademarks
All terms that are mentioned in this paper
that are known to be trademarks or service
marks have been appropriately capitalised.
Use of a term in this paper should not be
regarded as affecting the validity of any
trademark and service mark. The product
or brand names are trademarks of their
respective owners.
Printing
Document status
10/2002
Version 1.0 (10.2002)
Printed in Germany
All rights reserved
The
documentation
was
accomplished
through the Institut für Telematik.
The information contained in this document represents the current view of the
authors on the issues discussed as of the
date of publication. Because the present
methodology must respond to changing
research conditions, the results of this
paper should not be interpreted to be a
commitment on the part of the authors.
Any information presented after the date
of publication are subject to change.
The right to copy this documentation is
limited by copyright law. Making unauthorised copies, adaptations or compilation
works without permission of the authors or
institutions mentioned above is prohibited
and constitutes a punishable violation of
the law.
2
Preprint Patientenreminder
3
Inhaltsverzeichnis
1. Abstract ................................................................................................ 4
2. Einleitung ............................................................................................. 4
3. Soft- und Hardwarebausteine ............................................................ 5
3.1 Betriebssystem ............................................................................................................5
3.2 Grafik-Bibliothek .........................................................................................................5
3.3 Kartenleser..................................................................................................................6
3.4 Krankenkassenkarte ....................................................................................................6
3.5 Einwahlprogramm.......................................................................................................7
4. Hauptfenster – Funktionen ................................................................. 8
5. Interne Datenspeicherung................................................................... 9
6. Zusammenfassung und Ausblick ...................................................... 11
Referenzen ............................................................................................... 12
Preprint Patientenreminder
4
1. Abstract
Ein automatisches Patientenerinnerungssystem ist mit dem Software Projekt Patientenreminder verwirklicht. Es ist für Arztpraxen konzipiert, um Patienten über SMS Nachrichten auf ihr Handy an Impf- und
Untersuchungstermine zu erinnern. Die Patienten werden mit Hilfe ihren Krankenkassenkarte registriert.
Das Programm, geschrieben mit Hilfe von Open Source Software gliedert sich in drei Hauptschwerpunkte.
Ein Teil beschäftigt sich mit der Handhabung und Ansteuerung eines Kartenlesers, der Versichertenkarten
ausliest, und die Daten abspeichert. Ein weiterer Teil sorgt für das Einwählen in das Netz, jeweils abhängig
vom verwendeten Telefonanschluss (analog, digital), und das Versenden der Nachrichten mit Hilfe eines
integrierten e-mail Clients. Ein dritter Teil ist für das Verwalten der Daten in einer geeigneten Datenbank
verantwortlich und das Ermitteln der anstehenden Benachrichtigung abhängig vom Alter, Geschlecht,
vorher bereits durchgeführten Untersuchungen und versendeter Benachrichtigungen. Alle Laufzeitanforderungen sind unter einer grafischen Benutzeroberfläche integriert, die prinzipiell geeignet ist, auch auf
Systemen mit beschränkten Ressourcen zu funktionieren.
2. Einleitung
Um die verwendete Technik und das Aussehen des Programms Patientenreminder zu verstehen ist es hilfreich sich die Entwicklungsgeschichte zu betrachten. Im Herbst 2001 wurde die Idee geboren ein automatisches Patienteninformationssystem zu entwickeln. Viele miniaturisierte Computer kamen neu auf den
Markt, Handhelds und Palms waren und sind bis heute in Mode. Hier versprach ein kleines, preiswertes
System geeignet zu sein, um als Träger obiger Produktidee in Arztpraxen Einzug zu halten. Enge preisliche
Vorgaben machten es nötig nach wirklich innovativen neuen Hard- und Softwarebausteinen zu suchen.
Als zur damaligen Zeit einziges Gerät erfüllte der Handheld-Computer "agenda"1 diese Bedingungen. Mit
seinem Touchscreen und seiner vorbereiteten e-mail Funktionalität schien er technisch geeignet, und
durch die Verwendung von open-source Software erfüllte es die finanziellen Rahmenbedingungen. Als
erstes sollte die Ansteuerung eines Kartenlesers verwirklicht werden. Das Überspielen und Compilieren der
Treiber-Sourcen gelang, nur beim praktischen Ansteuern des Kartenlesers hat sich auch nach vielen Versuchen ein Hindernis bei der seriellen Schnittstelle ergeben, sodass Daten gesendet, aber nicht Empfangen
werden konnten. Die Entwicklung und das Testen des Programms wurde dann auf einen PC verlagert mit
der Hoffnung in einer späteren Version des Kleingerätes das Programm darauf zu installieren. Vorteilhaft
war, dass hier eine grafische Bibliothek (FLTK) 2 verwendet wurde, die von ihrer Größe und Ausführungsgeschwindigkeit prädestiniert war auf Handhelds zum Einsatz zu kommen. Später zeigte es sich, dass die
Bibliothek auch unter dem Windows Betriebssystem eingesetzt werden kann.
"FLTK is designed to be small and modular enough to be statically linked - the "hello" program is only
97k when compiled on an x86 Linux system!"[3]
Unter Linux gibt es das Programm "wvdial", welches das Einwählen an einen Internet-Provider und den
Aufbau einer ppp-Verbindung ermöglicht. Unter Einsatz des Quellcodes von "wvdial" ist intern eine Einwahlprozedur erzeugt worden, mit deren Hilfe fast jedes externe Modem angesteuert werden kann. Später wurde das optionale Einwählen mit einer ISDN Karte integriert. Das Versenden der SMS ist direkt nicht
möglich, da Provider über eine Seite normalerweise Username und Passwort abfragen, was einer Automatisierung im Wege stand. Hier war von Anfang an vorgesehen, alle SMS in eine e-mail zu packen und erst
bei einer speziell ausgesuchten Partnerfirma, sie zu entpacken und von dort zu versenden. Jetzt konnte
das Programm sich bei einem beliebigen Provider einwählen und die Nachrichten versenden. Da aber die
Provider nur e-mails weitersenden von Nutzern, die bei Ihnen auch einen e-mail Account besitzen, musste
die Lösung auf die Verwendung eines "sendmail" Programms verzichten, das die mails automatisch an die
richtige Stelle weiterleitet.
Das machte die Erstellung eines eigenen e-mail SMPT Clients erforderlich. Hier wäre es für die Zukunft
denkbar den notwendigen Verbindungsaufbau mit eine verschlüsselten Variante zu ersetzen.
1
http://www.agendacomputing.de/home/index-d.htm
2
http://www.fltk.org/
Preprint Patientenreminder
5
Für verschiedene Ärzte gibt es unterschiedliche Anforderungen an den Versenderythmus und den Versendetext der Patienten. Das Programm liest aus einer Datei, die Versenderythmen, Arztdaten und weitergehende Informationen aus, um die Patienten geeignet zu informieren. Bereits vorbereitet ist das Erinnern
an Impfterminen, das durch die relativen Zeiten zu etwaigen früheren Impfungen umfangreicher in der
Programmausführung war. Das Speichern der Patienten erfolgt in einer API- angesteuerten Datenbank.3
"Berkeley DB is a programmatic toolkit that provides fast, reliable, scalable, and mission-critical database
support to software developers."[4]
In Hinblick auf den Einsatz des Programms auf einem Handheld kam eine Datenbank Server basierte Lösung nicht in Frage. Die direkte Ansteuerung, komplexer in der Programmierung, ist im Betrieb einfacher
zu handhaben und reduziert die Möglichkeit von Fehlerquellen, wie Schwierigkeiten des Startes oder des
Ausfalles eines Servers.
3. Soft- und Hardwarebausteine
3.1 Betriebssystem
Entwickelt wurde der Patientenreminder auf einem Pentium PC mit Suse Linux 7.0. Es konnte bislang auf
Suse Linux 7.3 und RedHat 7.0 portiert werden. Bei Verwendung einer ISDN Karte muss zusätzlich ein
Software Paket von AVM FritzCard PCI 2.0 oder je nach Fall AVM FritzCard PCMCIA 2.0 installiert werden.
Bei der Installation der Software muss darauf geachtet werden, dass die C und C++ Entwicklungsumgebung mit installiert wird.
3.2 Grafik-Bibliothek
Zur Erstellung einer grafischen Benutzeroberfläche kam die "Fast Light Toolkit (FLTK) -Bibliothek" zum
Einsatz. Die zuletzt verwendete Version war FLTK 1.1.0rc6. Nach dem Laden auf den Rechner, muss das
Paket entpackt und als root mit "make install" installiert werden. Näheres findet sich in der beigefügten
"README" Datei.
Die FLTK Bibliothek hat den rechtlichen Status von Library General Public License (LPGL) mit Ausnahmen.
Hierzu finden sich nähere Informationen unter http://www.fltk.org /COPYING.php. Meiner Auffassung ist
die Anbindung der Bibliothek und die Verwendung im Projekt Patientenreminder zulässig auch für eine
kommerzielle Verwendung. Während der Installation der Bibliothek wird zusätzlich eine grafische Benutzerumgebung "fluid" auf den Rechner kopiert. Mit ihrer Hilfe lässt sich die Oberfläche intuitiv erstellen
und das Ergebnis als C++ Code ausgeben.
Wie in der Einleitung bereits erwähnt, besitzt diese grafische Bibliothek den Vorteil, dass sie trotz Bereitstellung vieler „Widgets“ minimalistische Ziele verfolgt. So ist der letztlich erzeugte Code so klein, dass er
in aller Regel statisch an ein Programm angebunden kann. Eine einfache event-Behandlung reduziert viel
prgrammtechnischen Overhead und schafft eine enorme Stabilität während der Ausführung. Aufgrund
der Kompaktheit ist FLTK schnell in der Ausführungsgeschwindigkeit und deshalb auf Systemen mit eingeschränkter Leistung (wie PDA) ideal einsetzbar.
Über das Projekt Patientenreminder hinausgehend sei hier erwähnt, dass FLTK 3D-Grafik mit OpenGL Software unterstützt. Es ist konzipiert für X (UNIX®), MacOS® und Microsoft® Windows®.
3
http://www.sleepycat.com/
Preprint Patientenreminder
6
3.3 Kartenleser
Als Kartenleser kam der serielle Towitoko CHIPDRIVE extern4[5] zum Einsatz. Der Kartenleser war aus anderen Projekten bekannt und besitzt eine Unterstützung für Linux/Unix basierte Systeme. Um den Kartenleser anzusprechen, muss eine Treibersoftware verwendet werden. Zum Einsatz kam das Paket towitoko2.0.4. Es beinhaltet den Quellcode für den Treiber, make- Dateien und ein Beispielprogramm. Um die
Funktionalität des Paketes zu verstehen, werden hier Auszüge der beigefügten README - Datei wiedergegeben:
An application can access the reader via several standard smartcard interfaces, such as CT-API/CT-BCS and
PC/SC IFD-handler. CT-API/CT-BCS is intended to be used by applications running on the machine to
which the smartcard reader is attached and the PC/SC IFD-handler feet into the MUSCLE PC/SC Lite resource manager, which provides distributed management of several smartcard readers of distinct manufacturers.
WHICH READERS WORKS WITH THIS DRIVER?
The driver understands the protocol for communicating to any Towitoko reader labelled as "Chipdrive".
This includes Chipdrive Micro, Chipdrive Extern, Chipdrive Extern II, Chipdrive Intern, and Chipdrive Twin.
WHICH SMARTCARDS CAN I USE WITH THIS DRIVER?
The driver works with processor cards with direct or inverse convention, and with memory cards that uses
the I2C bus protocol, 2 wire protocol or 3 wire protocol. Access to memory cards is provided via the Interindustry Commands described in the MCT v09 part 7 spec. APPLICATIONS A sample tester application is
distributed within this package that uses the CT-API/CT-BCS interface to issue some commands to a
memory or processor card. This program is for testing purposes only and wont help you much in most
cases. If you are looking for real world applications visit the M.U.S.C.L.E (Movement For The Move Of
Smart Cards In A Linux Environment) web site5.
Die Version 2.0.4 des Treibers hat keine USB - Unterstützung. In der zur Zeit aktuellsten Version 2.0.6 wird
auch die USB Variante des Kartenlesers unterstützt. Um eine einfache Portierung auf PDA's zu Gewährleistung wurden im Projekt Patientenreminder die benötigten Source-Routinen mit eingebunden und somit
fest in das Programm integriert.
3.4 Krankenkassenkarte
Zum Auswerten der ausgelesenen Daten aus dem Kartenleser ist frei zugängliche Software aus dem Internet als Basis verwendet worden. David van Gorkom [9] hat auf seiner Internetseite geradezu lehrbuchhaft
den Aufbau von verschiedenen Speicherkarten beschrieben. Teile seines Sotwarepaketes wurden verwendet. um in neuer Form im Projekt Patientenreminder die Informationen auszuwerten. Um ein Verständnis
für die Krankenkassenkarte zu bekommen wird hier ein Auszug aus seiner Seite gegeben [9].
Chip: Bei der KV-Karte handelt es sich um eine synchrone 256-Byte Speicherkarte. Die verwendeten Protokolle können unterschiedlich sein. Besonders oft in diese Chipkarten eingesetzt werden gewöhnliche
I2C-EEPROM ICs - fast jeder Hersteller hat solche schon seit langem in seinem Sortiment und kann sie so
in grossen Mengen und als konsequenz davon, vor allem billig abgeben. Die Standardbezeichnung für
den (CMOS-) Typ lautet "24C02". Im weiteren werden auch 2-wire Karten verwendet (ISO Protokoll
S=10, nicht zu verwechseln mit dem oben genannten "Standard I2C 2-wire Protokoll"). Zu nennen wären
hier beispielsweise der Typ PCB 2032 von Philips Semiconductors und der baugleiche Typ SLE 4432 von
Siemens Semiconductors. Für die Verwendung zugelassen sind schließlich noch 3-wire Karten.
Speicher - Organisation: Die (relevanten) Daten stehen bei einer KVK ab der Adresse $1E. Dort steht
dann auf alle Fälle $60. Mit dem nächsten Byte berechnet man dann den Start der Datensätze. Leider habe ich hierzu keine gesicherten Informationen - die vorläufige Lösung ist im Source einsehbar und funkti4
5
http://www.towitoko.de/hpneu/prod_extern.htm
MUSCLE http://www.linuxnet.com/
Preprint Patientenreminder
7
oniert anscheinend hervorragend! Alle weiteren Bytes werden nun auf Marken (Tags) abgesucht (sind >=
$80), die eine bestimmte Bedeutung haben (siehe Tabelle Anm. siehe dazu [9]). Ihnen folgt ein 2. Byte,
dass die Größe des jeweiligen Datensatzes angibt und danach kommt der Datensatz selbst. Das wiederholt sich bis zibt die Anzahl der Leerzeichen ($20) an , die bis zum vorletzten Byte benötigt werden, um
den verbleibenden Speicher "aufzufüllen". Das letzte Byte (Adresse $FF) hat den Wert $00 und ist der
Schluss.
3.5 Einwahlprogramm
3.5.1 analoge Telefonverbindung
Soll der Rechner, auf dem das Programm Patientenreminder zum Einsatz kommt, an eine analoge Telefonleitung angeschlossen werden, so ist ein externes Modem erforderlich. Zur Verwendung während der
Entwicklungszeit kam das 3Com U.S.Robotics 56K Faxmodem. Aber alle externen Modems können prinzipiell eingesetzt werden. Sogar Handys mit Modem-Funktionalität wie das Siemens SI45 konnten eingesetzt werden. Auf dem PC sollte das Softwarepaket "wvdial"6 installiert sein. Obwohl der Quellcode in
das Programm Patientenreminder integriert wurde, besitzt dieses Softwarepaket eine Zusatzkomponente,
die das leichte Konfigurieren neuer Modems ermöglicht.
wvdial lädt während der Ausführung die Datei /etc/wvdial.conf. Dort werden alle zum Verbindungsaufbau
relevanten Daten vorgehalten. Bei der Konfiguration der ppp-Verbindung mit Hilfe von yast, wird letztlich
auch diese Datei angepasst.
Damit die Authentisierung beim Verbindungsaufbau erfolgreich durchgeführt werden kann, müssen die
Rechte folgender Dateien auf 766 verändert werden:
/etc/wvdial.conf
/etc/ppp/pap-secrets
/etc/ppp/chap-secrets
3.5.2 digitale Telefonleitung
Zum Anschluss an eine digitale (ISDN) Leitung muss eine ISDN Karte installiert werden. mit einem aktuellen Treiber. Konkret ist das Programm getestet unter der FritzCard PCIv2.0 bzw. unter der FritzCard
PCMCIA 2.0 7.[8]. Diese Karten benutzen abweichen von der in der Suse Linux Version 7.0 vorgegebene
ISDN Treiber einen neuen CAPI Treiber CAPI 2.0-Treiber (/latest CAPI 2.0 Driver Linux - Kernel 2.4.184GB). Um die Karten zu aktivieren muss der Treiber vorher geladen werden. Nach dem Laden des Programms finden sich in der Datei aktuell „install_passive.de“ nähere Installationsanweisungen.
Zu bemerken gilt, dass auch hier wie bei der analogen Verbindung die Rechte der Dateien „/etc/ppp/papsecrets“ und „/etc/ppp/chap-secrets“ zu ändern sind.
6
http://open.nit.ca/wvdial/
7
http://www.avm.de/de/FRITZ/
Preprint Patientenreminder
8
4. Hauptfenster – Funktionen
Das folgende Bild zeigt die grafische Benutzeroberfläche des Programms Patientenreminder.
Fig.1 Hauptfenster, Bsp Variante GynCall
Es dient dazu die Patientendaten anzuzeigen (bei Kartenlesereingabe) oder einzugeben bei der manuellen
Eingabe und die Funktionalitäten zu steuern
Im normalen Praxisbetrieb werden die Daten vom Kartenleser eingelesen. Um den Kartenleser zu aktivieren muss der Button "Kartenleser aktivieren" gedrückt werden. Im Feld "Meldung" erscheint dann eine
Rückmeldung, ob der Kartenleser bereit ist. Bei erfolgreichem Start bleibt der Button "Kartenleser aktivieren" gedrückt, bis der Kartenlesemodus mittels des Buttons "deaktivieren" beendet wird.
Wird eine Krankenkassenkarte in den Kartenleser gesteckt, so wird diese registriert und ausgelesen. Die
Daten werden in den Feldern angezeigt. Sind die Personendaten des Patienten dem System bereits bekannt, so wird der Button "untersucht" aktiviert. Es wird davon ausgegangen, dass die Informationen
nicht geändert werden sollen. Drücken von "untersucht" speichert den Tag als Untersuchungstag ab.
(Hier nicht sichtbar und bereits implementiert ist die Möglichkeit aus verschiedenen Untersuchungstypen
zu selektieren.) Sollen doch die Personendaten verändert werden, so muss der nun aktive Button "Korrektur" gedrückt werden. Die Felder "Handy-Nummer" und "mail-Adresse" sind nun bereit editiert zu werden und das Geschlecht kann verändert werden. Jetzt ist auch der Button "speichern" aktiv, der beim
Betätigen die Daten neu abspeichert.
Soll ein Patient ohne Krankenkassenkarte eingeben werden, so muss der Button "neuer Patient" gedrückt
werden. Jetzt müssen alle Felder von Hand eingegeben werden, um eine Speicherung zu ermöglichen. Ist
der Patient bereits registriert, so kann er mittels Pressen des Knopfes "Datenbank" selektiert werden.
Insbesondere das Feld Geburtstag wird vor dem Speichern auf Richtigkeit überprüft. Das Format sollte wie
folgt aussehen: tt.mm.jjjj. Zu bemerken ist, dass die Felder "Titel", "Vorname", "Name" und "Geburtstag" im Fall der Kartenleseeingabe nur lesbar aber nicht editierbar sind.
Preprint Patientenreminder
9
Soll der SMS -Versand aktiviert werden, so muss auf die richtige Hardware-Anpassung geachtet sein. Der
Kartenlesemodus muss deaktiviert sein. Ein einfaches Betätigen des Buttons "SMS Versand aktivieren" ist
dann ausreichend, um alle nötigen Schritte (einwählen und SMS -Versand) zu starten.
5. Interne Datenspeicherung
Im folgenden wird die Datenspeicherung beschrieben wie sie in der Version Patientenreminder 1.2 realisiert ist, in der keine Trennung zwischen manuell und aus Karten eingelesenen Daten vorgenommen wird.
Sie ist einem vorhergehenden Modell sehr verwandt, denn außer der Zusammenlegung hat sich an der
eigentlichen Struktur nichts verändert. (Die vormals getrennte Funktionalität macht sich in hier nicht sichtbaren Details im Quellcode bemerkbar.)
Trotz aufgehobener Trennung gibt es dennoch zwei Datensätze. Ein Datensatz enthält die sogenannten
Stammdaten in der direkt nur selten zu veränderten Größen wie Name, mail Adresse gespeichert werden.
Ein weiterer Datensatz (variable Daten) enthält Informationen über versendete SMS und wahrgenommene
Untersuchungs- und Impftermine. In der Programmversion Patientenreminder 1.2 sind Impfungen nicht
vorgesehen, das Programm ist aber prinzipiell auch dafür ausgelegt. In der Beschreibung soll dies nun mit
verfolgt werden.
1. Stammdaten:
Im folgenden wird der Struct-wiedergegeben in denen die Stammdaten gespeichert sind.
typedef struct {
char KraKaNr[12]; // Krankenkassen-Nummer
char VKNR[8];
// Krankenkassen-Name
char VersNr[12]; // Versichertennummer
char VersStat[6]; // Versicherten-Status
char StatErg[3]; // Status- Ergänzung
char Titel[10];
char Vorname[30];
char NameZus[30]; // Name-Zusatz
char Name[30];
char GebDatum[9];
char PLZ[8];
char Strasse[60];
char Ort[60];
char Guelt[5];
// Gültigkeit
char mail_adr[50]; // Mail-Adresse
char HandyNr[50]; // Handy-Nummer
bool maskulin;
// Geschlecht
bool manuell;
// Info ob manuelle oder Kartenlesereingabe
unsigned index;
// Laufindex (erhöht sich um ins bei jedem neuen Patienten)
} patient;
Werden die Daten vom Kartenleser eingelesen, so sind alle Elemente des Struktes mit Werten gefüllt. Bei
manueller Eingabe ist das nicht der Fall. Es werden nur Titel, Vorname, Name, Geburtsdatum, Geschlecht,
Handy-Nummer und Mail-Adresse gespeichert. Zusätzlich wird ein Laufindex erzeugt, der sich bei jedem
neuen Eintrag um eins erhöht. Die Speicherung aller Daten im Fall der Kartenlesereingabe hat den Sinn
sich auf mögliche Erweiterungen der Programmfunktionen bereits vorzubereiten, wie zum Beispiel eine
Erinnerung mit Postkarten (Speicherung der Adresse) vornehmen zu können.
2. variable Daten
In den variablen Daten sind Informationen über die Patienten abgespeichert, die sich während der Ausführung des Programms mit der Zeit ändern. Die Daten sind in folgender C- Struktur geordnet.
Preprint Patientenreminder
10
typedef struct {
char LetzUntersu[9];
char ImpfStr[20*(5+5*8)+1];
char ImpfStrSMS[20*(5+1+8)+1];
char VorsStrSMS[10*(5+1+8)+1];
char VorsStr[10*(5+1+8)+1];
} patientReg;
Das Programm ist ausgelegt, um mit verschiedenen Impf- und Untersuchungstypen umgehen zu können.
Insgesamt können bis zu 20 verschiedene Impfungsarten mit maximal fünf Impfterminen verarbeitet werden. Zusätzlich ist vorgesehen, dass bis zu 10 Untersuchungstypen gespeichert werden. Die Informationen
sind in Strings vom Typ array of char gespeichert. Dabei unterteilen sich die zwei Typen Untersuchungund Impftypes wiederum in zwei Speicherstrings. Einer gibt Informationen über die wahrgenommen Untersuchung/Impfung, der andere gibt Auskunft über die versendete SMS zu einem anstehenden Untersuchungs-/Impftermin.
Im folgenden werden die einzelnen Strings in ihrer Bedeutung beschrieben. Felder die Datumsangaben
beinhalten speichern diese im Format ddmmjjjj (8 byte lang) ab.
char LetzUntersu[9]: speichert das Datum der letzten Untersuchung ab.
char ImpfStr[20*(5+5*8)+1]: Speichert Daten für 20 Impfungen zu maximal fünf Terminen ab. Ein Speicherbereich für eine Impfung setzt sich zusammen aus eine 5-byte großen Impfkennung und weiteren fünf Feldern zu je 8 byte, die Platz haben, um die Datume abzuspeichern für die aufgesuchten Impftermine. Die letzte 1 in dem Feld "20*(5+5*8)+1" schafft Platz für eine abschließende
Null.
char ImpfStrSMS[20*(5+1+8)+1]: ähnlich wie ImpfStr nur werden hier die Daten der versendeten SMS zu
max. 20 verschiedenen Impfungen gespeichert. Ein Speicherbereich für eine Impfung setzt sich
zusammen aus 5 byte für die Impfkennung, einem byte für die Zahl der versendeten SMS für einen Termin und 8 byte für das Datum der letzten versendeten SMS. Die letzte 1 in dem Feld
"20*(5+5*8)+1" schafft Platz für eine abschließende Null.
char VorsStr[10*(5+1+8)+1]: speichert Daten für bis zu 10 Vorsorgetypen ab. Der Speicherbereich für einen Vorsorgetyp besteht aus 5 byte für die Kennung einer Vorsorge, einem byte für die Zahl der
aufgesuchten Termine zu einem Vorsorgetyp und 8 byte für das letzte Datum der aufgesuchten
Vorsorgeuntersuchung.
char VorsStrSMS[10*(5+1+8)+1]; speichert Daten für den SMS Versand für max. 10 Untersuchungstypen.
Der Aufbau eines Speicherbereichs zugeordnet eines Untersuchungstyps ist identisch mit dem im
VorsStr- String, nur beziehen sich hier die Angaben auf die zuletzt versendete SMS anstatt auf
den zuletzt aufgesuchten Untersuchungstermin.
In der Anordnung der einzelnen Imp- bzw. Untersuchungstypen gilt es einen Unterschied zu beachten.
Im Fall der Impfung kann die Reihenfolge in der die Impftypen im ImpfStr und ImpfStrSMS angeordnet
sind variieren. Während der Programmausführung untersucht ein spezieller Algorithmus beide Strings und
produziert eine Zuordnungstabelle damit SMS und Impftermin aufeinander passen. Dieser Freiheitsgrad in
der Anordnung ist vorgesehen, um es einer evt. nachfolgenden Version zu erleichtern bereits vergebene
Impftermine ohne Umständlichkeit in den Impfstring einzutragen. Es wird einfach der nächste freie Platz
genommen. Außerdem können insgesamt mehr als 20 Impfungen zur Speicherung zur Verfügung stehen,
nur für einen Patienten ist die Zahl aus speichertechnischen Gründen begrenzt.
Im Fall der Vorsorgeuntersuchung ist die Reihenfolge der Typen gleich. Die ersten (5+1+8) byte gehören
bei dem VorsStr und dem VorsStrSMS String zum gleichen Typus. Man kann hier den Einwand erheben,
dass die Information über den Typ dann einmal unnötig gespeichert ist, was mit ja zu beantworten ist.
Hier zeigt sich, dass die Konzeption während des Entwickelns mehrmals verändert und neuen Überlegungen angepasst wurde und es in der Ausführung nicht vollständig in optimaler Form umgesetzt ist.
Preprint Patientenreminder
11
6. Zusammenfassung und Ausblick
In oben stehenden Kapiteln wurde die Funktionsweise des Patientenreminders und seine wesentlichen
Datenstrukturen beschrieben. Weitere technische Details lassen sich entnehmen aus [1]. Bislang ist das
Programm von keiner Anwendungsseite nachhaltig getestet und muss somit als Beta-Version angesehen
werden. Zur Zeit der Drucklegung hat sich herausgestellt, dass mit neuen Linux – Versionen Anpassungen
an dem Quelltext vorgenommen werden müssen, um mit neuen Compilern das Projekt auf dem neuesten
Stand zu halten. Auch erscheint ein Wechsel der Datenbank von der zur Zeit verwendeten Berkeley Version zu „gdbm“ sinnvoll, da es sich als Standard durchsetzt und für diese Verwendung vollkommen ausreichend ist. Eine Variante mit Unterstützung von USB – Kartenlesern wäre sicherlich ein weitere Schritt zur
Modernisierung. Wie es sich zeigt werden nun mit der Versionen Linux 8.1 interne Modems unterstützt.
Hier könnte eine Anpassung geschehen. Für ein Forschungsprojekt wichtiger wäre die Entwicklung einer
von Anfang an verschlüsselten Datenverbindung nach außen. Damit wäre auch ein Grundstein gelegt,
Teile der Anwendung zum Versenden von Arztbriefen und anderen sicherheitsrelevanten Informationen
zu verwenden. Zertifikate, ausgestellt vom institutseigenen Trustcenter, könnten hier einen sinnvollen Beitrag liefern.
Preprint Patientenreminder
12
Referenzen
[1] Bernd Dusemund, Christoph Meinel. Patientenreminder – Eine Technische Beschreibung, internes
Papier „Institut für Telematik“, 2002
[2] http://www.agendacomputing.de/home/index-d.htm
[3] http://www.fltk.org/
[4] http://www.sleepycat.com/
[5] http://www.towitoko.de/hpneu/prod_extern.htm
[6] MUSCLE http://www.linuxnet.com/
[7] http://open.nit.ca/wvdial
[8] http://www.avm.de/de/FRITZ/
[9] David van Gorkom, Die Chipcard Technology Site http://stud-gis.htw-saaland.de/
~ofourman/projekte/campuscard/doc/anhang/smartcard/Die%20Chipcard%20Technology%20Sit
e.html