Evaluation des Neugeborenenscreenings - DPV

UNIVERSITÄTSKLINIKUM ULM
Akademie für Gesundheitsberufe
Schule für Medizinische Dokumentation
STUDIENARBEIT
Praktikant
Name
Manuel Holger Staib
Kurs
MD37
Thema
Evaluation des Neugeborenenscreenings:
Softwareentwicklung zur Verlaufsdokumentation bei konnataler Hypothyreose
Praktikumsstelle
Institution, Abteilung
Universität Ulm, Abt. Epidemiologie
AG computergestütztes Qualitätsmanagement in der Medizin (CAQM)
Straße, Hausnummer
Albert-Einstein-Allee 47
PLZ, Ort
89081 Ulm
Praktikumszeitraum
Beginn
04. Februar 2008
Ende
13. Juli 2008
Praktikant:
Manuel Holger Staib, MD37
Praktikumsstelle:
Leiter: Prof. Dr. med. Reinhard Holl
Universität Ulm, Abteilung Epidemiologie
AG computergestütztes Qualitätsmanagement in der Medizin (CAQM)
Albert-Einstein-Allee 47
89081 Ulm
Thema der Arbeit:
Evaluation des Neugeborenenscreenings:
Softwareentwicklung zur Verlaufsdokumentation bei konnataler Hypothyreose
Abstract
Leistungsvergleiche sind ein Instrument der Qualitätssicherung in der Krankenversorgung.
Eine Arbeitsgruppe an der Abt. Epidemiologie der Universität Ulm bietet solche Leistungsvergleiche für Zentren der pädiatrischen Diabetologie und Endokrinologie an. Zur Entwicklung der dabei verwendeten Erhebungssoftware wird Visual FoxPro eingesetzt. Der
Bericht beschreibt einige Merkmale eines solchen Programmes am Beispiel des neu
vorgestellten Moduls „Hypothyreose“.
Schlagwörter
elektronische Datenerfassung, Visual FoxPro, Qualitätssicherung, angeborene
Hypothyreose
Student trainee:
Manuel Holger Staib, MD37
Internship location:
Supervisor: Prof. Dr. med. Reinhard Holl
Universität Ulm, Abteilung Epidemiologie
AG computergestütztes Qualitätsmanagement in der Medizin (CAQM)
Albert-Einstein-Allee 47
89081 Ulm
Topic:
Evaluation of the newborn screening:
Developing software for continued documentation of patients with congenital hypothyroidism.
Abstract
Benchmarking constitutes a means of quality management. A team belonging to the department of epidemiology at the university of Ulm (Donau) is offering benchmarking programs to
special pediatric hospitals of diabetes and endocrine diseases. Visual FoxPro ist used for the
development of the necessary data capturing applications. This report describes several
features of such an application on the example of the recently published instance
„Hypothyreose“ – a data capturing application tailored for patients with congenital hypothyroidism.
Keywords
electronic data capture, Visual FoxPro, quality management, congenital hypothyroidism
Praktikumsstelle
Das Praktikum wurde an der Medizinischen Fakultät der Universität Ulm geleistet, bei der
Arbeitsgruppe „computergestütztes Qualitätsmanagement in der Medizin“ (CAQM) der Abteilung
Epidemiologie.
Unter der Leitung von Prof. Dr. med. Holl beschäftigt sich diese Gruppe mit Leistungsvergleichen von
medizinischen Leistungserbringern in den Bereichen pädiatrische Diabetologie und pädiatrische
Endokrinologie.
Seit Mitte der Neunziger Jahre des letzten Jahrhunderts besteht mit dem Angebot DPV ein Programm
zur externen Qualitätssicherung für (pädiatrische) Diabetesversorgung, welches bundesweit – und
zunehmend auch in den deutschsprachigen Nachbarländern als weit verbreitete Initiative genutzt wird.
Das Programm beinhaltet eine von der Arbeitsgruppe entwickelte und herausgegebene Microsoft
Windows-Anwendung zur ausführlichen Verlaufsdokumentation für Diabetespatienten nach dem
Vorbild einer elektronischen Krankenakte und dem Qualitätsvergleich QS-DPV, bei welchem die
teilnehmenden Zentren ihre Daten in anonymisierter Form an das CAQM schicken, welches von den
gesammelten Daten aller Zentren Leistungsvergleiche („Benchmarking“) anfertigt und verteilt.
Eine vergleichbare Initiative stellt das Programm APV dar, welches zur Dokumentation und Leistungsbewertung bei Adipositas eingesetzt wird und die Initiativen für die endokrinologischen Erkrankungen
AGS und Hypothyreose befinden sich derzeit in der Entwicklung.
Außer den Benchmarkingprogrammen betreut das CAQM epidemiologische Studien und führt
biometrische Auswertungen durch. Zur Zeit des Praktikums handelte es sich dabei um eine
Adipositas-Evaluationsstudie der BZgA (Bundeszentrale für gesundheitliche Aufklärung).
Der Mitarbeiterstamm besteht aus wenigen fest angestellten Ärzten und Programmierern und je nach
Bedarf freien Mitarbeitern (Dokumentare oder Informatikstudenten) auf Werkvertragsbasis.
Tätigkeiten
Die während des Praktikums geleistete Arbeit bestand nahezu ausschließlich aus Entwicklung und
Pflege von Dokumentationsanwendungen der PEDA-QS-Familie in der Entwicklungsumgebung
Microsoft Visual FoxPro (Version 9).
Ausgehend von den Programmquellen der Anwendung „AGS“ (Dokumentationsprogramm für
Patienten mit Adrenogenitalem Syndrom) bestand der erste Meilenstein darin, eine Lösung zur
Dokumentation für Patienten mit angeborener Hypothyreose zu veröffentlichen. Als technisches und
gestalterisches Vorbild dienten dafür die drei bereits produktiv eingesetzten Programme für DPV
(Diabetes), APV (Adipositas) und AGS. Inhaltlich sollte das Programm dazu in der Lage sein, einen
von der AQUAPE vorgegebenen Merkmalskatalog vollständig abzubilden.
Als Neuentwicklung für die Programmfamilie war nach der ersten Veröffentlichung der Hypothyreosesoftware die Überarbeitung, beziehungsweise ein Neuentwurf eines Moduls erwünscht,
welches aus den eingegebenen Patientendaten automatisch Arztbriefe erstellt.
Zur ersten Erprobung sollte das neue Modul in Hypothyreose und AGS integriert werden. Die
Implementierung in AGS ging einher mit einer Umgestaltung und Aktualisierung der Programmfunktionen
nach dem
Vorbild der
Hypothyreosesoftware, nachdem
ich das
Projekt vom
ausscheidenden AGS-Entwickler übernommen hatte.
Nach der Veröffentlichung der aktualisierten Version von AGS bestand die Aufgabe im Ausbau eines
Kontextmenüs der Programme, welches dem Anwender erlauben soll, beim Rechtsklick auf ein
Eingabefeld diverse Funktionen, wie eine kontextsensitive Erläuterung, einen tabellarischen oder einen
grafischen Verlauf dieses Merkmals anzuzeigen. Dieses Modul wurde während des Praktikums in die
Programme Hypothyreose, DPV und AGS implementiert.
Die Programmveröffentlichungen erforderten die Gestaltung und Erprobung von Update- und
Installationsroutinen,
sowie
die
Aktualisierung
der
betreffenden
Internetseiten.
Neben
der
Programmiertätigkeit sind die Entwickler außerdem die Ansprechpartner der Benutzer bei technischen
oder auch inhaltlichen Problemen und leisten telefonische oder schriftliche Unterstützung.
Weitere Aufgaben äußerten sich im Digitalisieren und Ordnen von Fragebögen einer betreuten
Adipositasstudie, der Konvertierung von fremden Datensätzen in das Format der PEDA-QS-Familie
oder kleineren Wartungsarbeiten an den Abteilungscomputern.
Inhalt
1
Neugeborenenscreening: konnatale Hypothyreose ............................... 1
2
Arbeitsgruppe Qualitätssicherung der Arbeitsgemeinschaft
Pädiatrische Endokrinologie (AQUAPE).................................................. 1
2.1
Die Erhebungsbögen für die Verlaufsdokumentation bei angeborener
Hypothyreose.................................................................................................3
3
die DPV-Software als Ausgangspunkt für die Entwicklung
weiterer Datenerhebungsanwendungen................................................. 4
4
Die Entwicklungsumgebung Microsoft Visual FoxPro 9 (VFP9) ..........5
4.1
Visual FoxPro: Die Oberfläche .....................................................................5
4.2
die Programmiersprache von Visual FoxPro ...............................................7
4.3
das Datenformat............................................................................................8
4.4
Datenbankstrukturen im Vergleich zur Arbeit mit freien Tabellen..........9
5
die erste Version der Anwendung: Hypothyreose v1.01 .......................10
5.1
Datenbasis....................................................................................................10
5.2
Patientenerfassung und Verlaufsbeobachtung..........................................10
5.3
Export, Datensicherung und Datenübermittlung .................................... 13
5.4
Arztbrief-Generator..................................................................................... 13
5.5
Update-/Erstinstallationsroutine ................................................................ 16
5.6
Teilnahme am Hypothyreose-Benchmarking............................................ 17
6
Veröffentlichung und Resonanz.............................................................. 18
7
Zukunftsaussichten.................................................................................... 18
1
Neugeborenenscreening: konnatale Hypothyreose
Seit den frühen Siebziger Jahren des letzten Jahrhunderts werden in Deutschland allen Neugeborenen (mit
Zustimmung der Eltern) in den ersten Lebenstagen Blutproben zur Früherkennung von angeborenen Störungen
des Stoffwechsels oder endokriner Organe entnommen [1].
Als angeborene Defekte sind die geprüften Erkrankungen im Allgemeinen nicht heilbar. Jedoch können durch
frühzeitige Therapierung die Symptome und permanente Schädigungen minimiert, oder sogar vollständig
unterdrückt werden.
Die entnommenen Proben werden zur Untersuchung an eines von zwölf deutschen Screeninglabors geschickt,
welche diese auf Auffälligkeiten hinsichtlich der in Richtlinien des Bundesausschusses der Ärzte und Krankenkassen
bestimmten Erkrankungen (und zwar ausschließlich) testen [2]. Einer dieser Tests ist die Serumkonzentration des
Thyroidea-stimulierenden Hormons. Eine Erhöhung des Ergebnisses (>20mU/l) liefert einen ersten Verdacht auf
eine Unterfunktion der Schilddrüse (Hypothyreose). Eine in diesem Stadium unbehandelte konnatale (=angeborene) Hypothyreose führt mit hoher Wahrscheinlichkeit zu Entwicklungsstörungen der Intelligenz, des
Hörvermögens und der Sprache [3, S.992].
Patienten mit bestätigter angeborener Hypothyreose sind auf eine lebenslange Hormonsubstitution (L-Thyroxin)
angewiesen.
2
Arbeitsgruppe Qualitätssicherung der Arbeitsgemeinschaft
Pädiatrische Endokrinologie (AQUAPE)
Die Arbeitsgemeinschaft Pädiatrische Endokrinologie (APE) ist ein Zusammenschluss von Medizinern, welche sich
mit der Erforschung, Diagnostik und Behandlung von Störungen des Hormonstoffwechsels und hormonbildender
Drüsen bei Kinder und Jugendlichen beschäftigen. Sie sieht ihre Aufgaben in der Förderung wissenschaftlicher
Projekte, Weiterbildung und Öffentlichkeitsarbeit. Im Jahr 1997 wurde von dieser Arbeitsgemeinschaft die
„Arbeitsgruppe Qualitätssicherung der Arbeitsgemeinschaft Pädiatrische Endokrinologie“ (AQUAPE) initiiert,
welche gezielt mittels vergleichender Statistik die Situation in der Versorgung pädiatrisch-endokrinologischer
Krankheiten aufklären und verbessern soll [4].
Das Konzept „Qualitätssicherung“ bedeutet hierbei in der Praxis: Ein behandelndes oder diagnostizierendes
Zentrum dokumentiert die eigene Arbeit und den Status und Fortschritt seiner Patienten nach einem
standardisiertem Fragenkatalog und übermittelt diese Daten pseudonymisiert in regelmäßigem Abstand (zum
Beispiel halbjährlich) an eine zentrale Datensammelstelle. Dort können die Daten zusammengeführt werden, um
die aktuelle Gesamtsituation in der Versorgung des jeweiligen Bereichs aufzuklären. Außerdem werden die Daten
jedes dokumentierenden Zentrums zu denen der anderen Zentren in Relation gesetzt („Benchmarking“), um gezielt
Schwächen, oder auch Erfolge und Fortschritte
in der Versorgung aufzudecken. Auf diese Weise entdeckte
erfolgreiche Konzepte können daraufhin in neue Leitlinien einfließen.
Ist die Stichprobe der teilnehmenden Zentren repräsentativ, gibt die Auswertung eines solchen Vergleichs dem
einzelnen Zentrum eine zuverlässige Beurteilung der eigenen Leistung und liefert gegebenenfalls konkrete Ansätze
zur Verbesserung. Neben dem Vergleich zu anderen Stellen liefert die Auswertung auch Übersicht über die Ent-
1
wicklung des Zentrums selbst im Vergleich zum Status in der Vergangenheit. Die Teilnahme an einem solchen
Vergleich ist für das Zentrum freiwillig.
Bislang sind von der AQUAPE fünf solcher Qualitätssicherungsprojekte für pädiatrisch-endokrinologische
Krankheitsbilder vorgesehen: Das Adrenogenitale Syndrom (AGS), konnatale (angeborene) Hypothyreose, Pubertas
praecox, STH-Mangel (Somatotropes Hormon) und Basedow-Hypothyreose [5, Seite 1].
Nachdem von der Arbeitsgruppe die zu dokumentierenden Parameter im Konsens entschieden wurden, sollen den
teilnehmenden Zentren geeignete Werkzeuge zur Datenerhebung und -übermittlung zur Verfügung gestellt
werden. Dazu werden die in der Vergangenheit üblichen Papierbögen nach und nach durch computergestützte
Datenerfassung ersetzt. Die Dateien für AGS und konnatale Hypothyreose bestehen seit dem Jahr 2000. Für die
Erhebung, beziehungsweise Digitalisierung der erhobenen Daten wurde bisher eine in Microsoft Access erstellte
Anwendung eingesetzt, welche von Informatikstudenten der Otto-von-Guericke-Universität Magdeburg entwickelt
wurde. Durch die guten Erfahrungen, welche die Arbeitsgruppe für computergestütztes Qualitätsmanagement in
der Medizin an der Universität Ulm mit dem Qualitätssicherungsprojekt für Diabetespatienten, DPV sammeln
konnte, wurde entschieden, die Auswertung der Daten und die Weiterentwicklung der Erhebungssoftware nach
Ulm zu verlegen. Seit 2007 wird von dieser Gruppe die Erhebungssoftware für AGS auf Basis der DPV-Software
bereitgestellt und im April 2008 wurde die erste produktive Version der Erhebungs- und Patientenverwaltungssoftware für konnatale Hypothyreose veröffentlicht, auf deren Entwicklung in diesem Bericht näher eingegangen
werden soll.
2.1
Die Erhebungsbögen für die Verlaufsdokumentation bei angeborener
Hypothyreose
Der vereinbarte Merkmalskatalog der AQUAPE ist auf zwei Erfassungsbögen aufgeteilt, welche in Papierform von
den teilnehmenden Zentren ausgefüllt werden sollten.
Auf dem ersten Bogen mit dem Titel „Anamnese und Erstdiagnostik“ (Anlage 1) werden zuerst Daten der
vorhergehenden Schwangerschaft und zum Geburtsverlauf erfasst. Besonderes Gewicht liegt hier auf den Angaben
zur Situation der Schilddrüse bei der Mutter, gefolgt von der kindlichen Anamnese mit Fragen zum Zustand bei der
Geburt und bei der Erstuntersuchung. Nach den Anamnesedaten und den Werten, welche beim Neugeborenenscreening zur Aufnahme führten, werden noch die Laborwerte (Schilddrüsenhormone im Serum u.a.) und die
relevanten Ergebnisse eventuell stattgefundener bildgebender Verfahren (Sonografie oder Szintigrafie) aus der
ersten Untersuchung erfasst, sowie Angaben zur Einleitung der Therapie (Datum der Diagnosestellung,
Therapiebeginn, anfängliche L-Thyroxindosis).
Der zweite Bogen mit dem Titel „Therapie und Verlauf“ (Anlage 2) ist für eine Kontrolluntersuchung von sich
bereits in Therapie befindenden Patienten vorgesehen. Er dokumentiert den augenblicklichen Gesundheitszustand
und Therapieverlauf. Abgefragt werden dabei aktuelle Körpermaße, vorgenommene Medikation, der gegebenenfalls
durchgeführte Entwicklungs- oder Hörtest, Ergebnisse der bildgebenden Diagnostik und Laborwerte der
Schilddrüsenhormone (T4, freies T4, T3) und des Thyroidea-stimulierenden Hormons (TSH)
Der größte Teil der Daten wird qualitativ mit den möglichen Ausprägungen „j“, „n“ und „k.A.“ („ja“, „nein“, „keine
Angabe“) erhoben, Mengen und Größenangaben (zum Beispiel Hormonkonzentrationen oder Körpergewicht) als
Zahlenwert mit vorgegebener Einheit , lediglich für die Angaben der verabreichten (hypothyreosefremden)
Medikamente und der Name des Screeninglabors werden Freitextfelder verwendet.
2
3
die DPV-Software als Ausgangspunkt für die Entwicklung
weiterer Datenerhebungsanwendungen
Von der Arbeitsgruppe für computergestütztes Qualitätsmanagement in der Medizin werden derzeit vier
Softwareprojekte entwickelt und betreut:
-
DPV (Diabetessoftware zur prospektiven Verlaufsdokumentation)
-
APV (Adipositaspatienten-Verlaufsdokumentation)
-
AGS (Verlaufsdokumentationssoftware für Patienten mit Adrenogenitalem Syndrom)
-
Hypothyreose (Verlaufsdokumentationssoftware für Patienten mit angeborener Hypothyreose)
Um die Wartung und Weiterentwicklung übersichtlich zu halten, besteht die Vorgabe, die Programme möglichst
modular aufzubauen und spezielle Lösungen soweit möglich zu vermeiden. Diese Politik soll dem Umstand
Rechnung tragen, daß die zuständigen Programmentwickler über die Jahre häufig wechseln und dabei auch
mehrere Programme gleichzeitig betreuen.
Als ältestes und umfangreichstes Programm liefert DPV die Kerne der anderen Projekte. Da die Entwicklung an
DPV nie von FoxPro abgewichen ist, oder komplett überholt wurde, stammen Teile des Quellcodes noch aus den
frühen Neunziger Jahren und machen keinen oder nur wenig Gebrauch von der technischen Weiterentwicklung
FoxPros. Die bereits angesprochene gestalterische Freiheit der Programmiersprache (Aufgaben mit mehreren
Ansätzen lösen und diese beinahe beliebig kombinieren zu können) schlägt sich durch die Vielzahl der beteiligten
Entwickler trotz guter Vorsätze in einer deutlichen Inkonsistenz der Programmierung nieder, welche nicht nur die
angewandten Methoden, sondern auch die Qualität der Lösungen und deren Kommentierung betrifft.
AGS und Hypothyreose sind zwei von der AQUAPE angeregte Projekte. Ihre Aufgabe besteht darin, zwei
festgelegte Erfassungsbögen abzubilden, daher ist ihr Datenmodell im Wesentlichen identisch: Bei einem Patienten
(Stamm- und Ersterfassungsdaten) werden mehrere Verlaufsbeobachtungen durchgeführt (Verlaufsdaten).
Außerdem soll es möglich sein, einem Patienten mehrere Ärzte zuzuordnen (Kontaktdaten), wobei ein Arzt auch
mehrere Patienten betreuen kann.
Für die 2007 veröffentlichte Version der AGS-Software wurde DPV als Basis verwendet. Alle für deren Zweck
unnötigen
Elemente
wurden
entfernt
und
neue
Masken
für
Patientenstammdaten,
Arztdaten
und
Verlaufsbeobachtungen erstellt. Durch die strukturelle Ähnlichkeit zum AGS-Konzept, bot sich für die Realisation
der Hypothyreosesoftware an, anstatt wieder von DPV auszugehen, einfach das AGS- Projekt umzuschreiben.
4
Die Entwicklungsumgebung Microsoft Visual FoxPro 9 (VFP9)
Die vorgegebene Plattform für die Entwicklung der Datenerhebungssoftware ist Visual FoxPro Version 9.0SP2 der
Firma Microsoft. Dabei handelt es sich um eine für Datenbankanwendungen spezialisierte Programmiersprache mit
eigener Entwicklungsumgebung in der Familie der „Visual“-Produkte von Microsoft (Programmierumgebungen,
welche eine Programmentwicklung auf grafischer Basis erlauben und nicht unbedingt auf das händische Schreiben
von Quellcode angewiesen sind).
Historisch handelt es sich dabei um die Übernahme des Produkts „FoxPro“ der Firma Fox Software, welches als
Konkurrenzprodukt zu dBase mit ähnlicher Syntax vertrieben wurde.
3
Das letzte große Versionsupdate (9.0 Codename „Europa“) wurde im Dezember 2004 veröffentlicht und das
aktuelle Servicepack 2 im Oktober 2007. Die Weiterentwicklung der Plattform wurde von Microsoft offiziell
eingestellt, wobei der Anwendersupport noch bis zum Jahr 2015 weiterhin geleistet werden soll.
4.1
Visual FoxPro: Die Oberfläche
Die Entwicklungsarbeit findet bei Visual FoxPro (wie für viele traditionelle Microsoft-Windows-Anwendungen
typisch) in einem „Multiple Document Interface“ (MDI) statt. Ein übergreifendes Programmfenster wird dabei in
diverse Unterfenster aufgeteilt, welche jeweils eigene Funktionen erfüllen.
Abbildung 1: Programmentwicklung in Visual FoxPro 9
Zu den wichtigsten Modulen gehören:
-
Project Manager
Ein Katalog über alle Dateien, welche einem Projekt angehören. Die einzelnen Elemente werden kategorisiert
dargestellt (Datenbanken, freie Tabellen, Formulare, Berichte, Programmskripte, etc.)
(siehe Abbildung 1, „1“)
4
-
Designer (Table-, Form-, Report-, Class-, etc.)
Spezielle Entwurfsansichten für die einzelnen Elemente. Die Designer für Formulare und Berichte sind in einem
grafischen „What You See Is What You Get“- Stil umgesetzt, welche dem Entwickler erlauben, die Ein- und
Ausgabemasken während der Gestaltung so zu sehen, wie sie letztendlich in der Endanwendung dargestellt
werden (siehe Abbildung 1, „2“). Das Designerfenster für Tabellen bietet eine tabellarische Ansicht der Felder
einer Tabelle mit Feldformaten und deren Dimensionierung und eigenen Registern für Indizes, Validierung und
Triggerfunktionen.
-
Command
Ein Parser, bzw. Kommandozeileninterpreter in welchem fast alle Befehle der Programmiersprache zur
Verfügung stehen. Voraussetzung für die Ausführung einer Aufgabe ist dabei, daß sie sich mit einer einzigen
Kommandozeile aufrufen lässt, daher sind beispielsweise Schleifenkonstrukte nur über Umwege anwendbar.
(siehe Abbildung 1, „3“)
-
Code
Ein Texteditor mit Syntax-Highlighting, automatischer Quelltextformatierung und IntelliSense (der Editor
schlägt eingeständig während des Tippens mögliche folgende Elemente vor und zeigt eine kurz gefasste
Dokumentation dazu), ausgerichtet auf die Programmiersprache von FoxPro (siehe Abbildung 1, „4“).
Zu den übrigen Modulen gehören das „Data Session“-Unterfenster, welches alle im Moment aktiven Tabellenzeiger
auflistet und verwaltet, das „Code References“-Unterfenster, in welchem das gesamte aktive Projekt nach Text
durchsucht werden kann und ein ausführliches Debuggermodul.
4.2 die Programmiersprache von Visual FoxPro
Zur
Erstellung
von
anwenderspezifischen
Funktionalitäten
wird
in
Visual
FoxPro
eine proprietäre,
objektorientierte und prozedurale Programmiersprache der vierten Generation verwendet. In ihren Grundzügen
handelt es sich dabei um eine Weiterentwicklung von xBase, einer Familie datenorientierter Programmiersprachen,
welche sich an dem Datenbankmanagementsystem dBase von Ashton-Tate orientieren [6].
Als Programmiersprache eines Datenbankmanagementsystems liegt ihr Schwerpunkt im Zugriff auf Daten in
Tabellen. Neben den klassischen xBase-Befehlen, ist auch SQL vollständig in die Sprache eingebunden und kann
ohne weitere Voreinstellungen im Code verwendet und mit den xBase-Befehlen kombiniert werden,
beziehungsweise diese ersetzen.
Eine Abfrage der Tabelle .\data\kunden könnte in xBase beispielsweise so aussehen:
USE data\kunden IN 0 ALIAS ktabelle && öffnet die Tabelle im Alias „ktabelle“
SELECT ktabelle
&& aktiviert die Tabelle
LOCATE FOR nname == "Trob"
&& sucht die erste Entsprechung
IF FOUND() THEN
Messagebox(wohnort)
&& Zeigt den Inhalt des Feldes in einer Dialogbox
ENDIF
USE IN ktabelle
&& schließt die Tabelle
5
Dasselbe Ergebnis liefert diese Variante mit Verwendung von SQL:
SELECT wohnort FROM data\kunden WHERE nname == "Trob" INTO ARRAY a_ergeb
IF _tally > 0 THEN
&& _tally: Anzahl der Ergebnisse der letzten Abfrage
Messagebox(a_ergeb[1,1])
ENDIF
Beide Varianten sind ohne weitere Angaben oder Initialisierungen ausführbar. „SELECT“ ist hier ein Beispiel für die
Mehrfachbelegung von Befehlen: Im ersten Beispiel aktiviert es über den Aliasnamen „ktabelle“ eine so genannte
„Workarea“ – ein Objekt mit der Funktion eines Datenzeigers in einer Tabelle. Die Feldnamen der Tabelle können
dadurch zur Laufzeit wie Variablen verwendet werden, welche den Wert der entsprechenden Spalte enhalten, in
dem Datensatz, in welchem sich der Zeiger befindet. Im zweiten Beispiel leitet das „SELECT“ eine SQL-Anweisung
ein, welche ein Abfrageergebnis in einem zweidimensionalen Array speichert.
4.3
das Datenformat
Durch die Unterstützung von ADO- und ODBC-Schnittstellen steht Visual FoxPro der Zugang zu einer breiten
Palette von Datenformaten offen. Das Stammdatenformat ist dabei von dBase abgeleitet. In diesem Format wird für
eine Tabelle eine eigene Datei angelegt (mit der Dateiendung ".DBF"), welche die blanken Daten und ihre
Definition enthält und (sofern erforderlich) eigene Dateien für die Indizes (Endung ".CDX") und für die Inhalte von
Memofeldern (Textfelder unbestimmter Größe, Dateiendung ".FPT") dieser Tabelle.
Tabellen können in dieser Form entweder für sich stehen (in der FoxPro-Nomenklatur "freie Tabelle") oder in einer
Datenbank organisiert sein, bestehend aus dem eigentlichen Datenbankbehälter (".DBC"), einer Memodatei
(".DCT") und gegebenenfalls einer Indexdatei (".DCX").
Ist eine Tabelle einer Datenbank zugeordnet, können in der Datenbank Relationen zu anderen enthaltenen
Tabellen bestimmt werden. Außerdem lassen sich unter anderem Datenvalidierungen und Trigger bestimmen,
welche für freie Tabellen nicht zur Verfügung stehen.
Datenbanken bieten außerdem die Möglichkeit, Views anzulegen – dabei können in deren SELECT-Anweisung
nicht nur Tabellen auftreten, welche in der Datenbank enthalten sind, sondern auch freie Tabellen.
4.4 Datenbankstrukturen im Vergleich zur Arbeit mit freien Tabellen
Die Entscheidung, ob in einem Projekt vorwiegend mit freien Tabellen oder mit Datenbankbehältern gearbeitet
wird, ist eine Frage der Umstände. Der Hauptvorteil eines Datenbankbehälters besteht darin, daß er dem
Programmierer einigen Aufwand bei der Einhaltung der Datenintegrität ersparen kann, indem Beziehungen
zwischen den Indexfeldern der einzelnen Tabellen erstellt und von der Datenbank überwacht werden.
Weitere Leistungsmerkmale von Datenbanktabellen sind:
-
Primärschlüsselfelder,
-
Bestimmung von Standardwerten und automatisch berechneten Daten,
-
Datensatzvalidierungen auf unterster Ebene,
-
lange Feldnamen (bei freien Tabellen ist die Länge auf zehn Zeichen begrenzt),
6
-
INSERT-, UPDATE- und DELETE-Trigger,
-
Bestimmung von Ein- und Ausgabeformaten, sowie
-
Feldkommentare
Diese Daten werden im Datenbankbehälter gespeichert. Dadurch, und um die Datenintegrität zu gewährleisten, ist
eine Datenbanktabelle fest an ihren Behälter gebunden. In der Praxis bedeutet das: Auch wenn die Tabellendateien
physisch von den Datenbankdateien getrennt sind, lassen sie sich nur in Verbindung mit diesen öffnen. Umgekehrt
reagiert die Datenbank sehr sensibel auf Veränderungen der Tabelle – so ist es nicht möglich, eine Datenbanktabelle
bei Bedarf durch eine neue Version (auch wenn diese dieselbe Struktur bietet) zu ersetzen. Stattdessen muss
entweder die alte Version mit den neuen Daten aufgefüllt werden, oder die alte Version aus der Datenbank entfernt
werden (die Tabelle wird „befreit“) um die neue aufzunehmen. Letztere Methode macht die Neudefinition aller
oben genannten Datenbanktabellenmerkmale nötig.
Die wichtigsten, vermutlich einzigen Vorteile eines Verzichts auf die Funktionalitäten der Datenbankbehälter
bestehen in einer pragmatisch gesehen deutlich verringerten Fehleranfälligkeit und einer einfacheren
programmiertechnischen Handhabe, welche sich insbesondere dann bemerkbar macht, wenn die Dateien oft
überschrieben und ersetzt werden (zum Beispiel durch aktualisierte Programmversionen, oder Datensicherungen).
5
die erste Version der Anwendung: Hypothyreose v1.01
5.1
Datenbasis
Wie bei den Vorbildprogrammen handelt es sich bei Hypothyreose nicht um eine Kombination aus Server und
Client, sondern um eine einzelne Anwendung mit eingebetteter Datenbank.
Für die zugrunde liegende Datenbasis wurden die verwendeten Tabellen in zwei Datenbanken eingefügt, um den
erhöhten Komforts bei der Arbeit mit SQL-Views nutzen zu können. Datenbankrelationen wurden allerdings nicht
definiert, so daß die Datenintegrität alleinige Aufgabe der Anwendung bleibt, nach dem Vorbild von DPV, welches
Lösch- und Aktualisierungskaskaden eigenständig durchgeführt.
Die beiden Datenbanken sind hypodb\hypodb.dbc und sysdb\sysdb.dbc.
In der HYPODB-Datenbank sind alle Tabellen mit Patientendaten abgelegt, sowie alle Definitionen von
verwendeten SQL-Views.
Die Datenbank
SYSDB beinhaltet Tabellen
mit Systemdaten, wie etwa einen ICD10-Katalog, eine
Einheitendefinition oder Tabellen mit Programmcode und Metadaten für Maskenfelder.
5.2
Patientenerfassung und Verlaufsbeobachtung
Der grundlegende Anspruch an die Anwendung besteht darin, die von der AQUAPE beschlossenen Fragebögen
abzubilden. Die zu erfassenden Merkmale wurden unterschieden zwischen einmaligen und sich verändernden
Daten und daran orientiert verteilt auf zwei Tabellen. Die Datenpflege erfolgt für diese Tabellen in zwei getrennten
Bildschirmformularen, den Masken „Stammdaten und Screening“ und „Verlaufsdaten“.
7
In der äußeren Gestaltung sind sich die beiden Masken sehr ähnlich: Über Reiter und farbige Rahmen werden die
Merkmale des Datensatzes in sinnverwandte Abschnitte unterteilt. Manche quasiredundanten Merkmale der
Fragebögen wurden beibehalten,
aber
auf
der
logische
gebracht,
Oberfläche
in
Zusammenhänge
um
widersprüchliche
Angaben zu vermeiden. So ist es
beispielsweise
nicht
mehr
möglich, der Mutter gleichzeitig
eine gesunde Schilddrüse und eine
Thyreoiditis zu unterstellen, da
das zweite Feld nur dann aktiv ist,
wenn das erste auf „j“ (=“ja“)
gesetzt wurde. Im Hintergrund
werden dennoch beide Werte mit der
Abbildung 2: Stammdatenformular in Hypothyreose
ausgewählten Antwort gespeichert,
um versehentliche Datenverluste zu vermeiden.
Unter der Oberfläche unterscheiden sich die beiden Masken deutlich:
Die Stammdatenmaske wurde in dieser Form von AGS übernommen und die Merkmale, Initialisierungen und
Plausibilitätsprüfungen den neuen Anforderungen angepasst. Die grundlegende Technologie stammt aus DPV: Um
einen Datensatz anzulegen, erstellt das Programm eine leere Tabelle mit der Struktur der Stammdatentabelle in
einem temporären Verzeichnis. In dieser Tabelle wird der neue Datensatz angelegt und bearbeitet und erst beim
Verlassen des Formulars in die eigentliche Stammdatentabelle geschrieben, wobei hier erst die endgültige PatientenID vergeben wird. Um einen bestehenden Datensatz zu ändern wird dieser (nach Auswahl des betreffenden
Patienten in einer eigenen Suchmaske) in eine temporäre neue Tabelle kopiert und von dort gelesen und verändert.
Bei der Speicherung des veränderten Datensatzes wird die temporäre Kopie wieder zurück in die
Stammdatentabelle kopiert und überschreibt damit den alten Datensatz, welcher (um Updatekonflikte im Netzwert
zu vermeiden) vom Aufruf bis zur Speicherung gesperrt wurde.
Die Maske für die Verlaufsbeobachtungen
Hypothyreose
wurde
für
komplett
neu
entwickelt und folgt technisch
eher dem Konzept, welches bei
der
Adipositasdokumen-
tationssoftware APV verwendet
wurde. Die Merkmale der Verlaufsbeobachtung wurden in zwei
Tabellen aufgeteilt: Eine Tabelle
hypodb\hypo_verlauf
mit
den
ambulant erfassten Daten und
Abbildung 3: Verlaufsdatenformular in Hypothyreose
eine
Tabelle
8
hypodb\hypo_laborwerte mit den Laborwerten, welche über eine Kombination aus Patientenschlüssel und Untersuchungsdatum ein-eindeutig miteinander verknüpft sind. Die aus datenbanktechnischer Sicht nicht nötige
Aufteilung folgt eher der menschlichen Sichtweise der Daten und wurde von der Projektleitung ausdrücklich
gewünscht. Für die Maske vereint werden diese beiden Tabellen (zusammen mit einigen Angaben aus der
Stammdatentabelle) in einer aktualisierbaren SQL-View, welche dem Formular als Datenbasis zugrunde gelegt ist.
Dieses Vorgehen erspart den Umweg über manuell angelegte temporäre Kopien, da bei der Arbeit mit einer SQLView die Transaktionskontrolle von der Datenbank übernommen wird und der Benutzer alle Änderungen an den
Daten mit den Funktionen TABLEREVERT() wieder rückgängig machen oder mit der Funktion TABLEUPDATE()
besiegeln kann.
Für den Anwender spürbar ist diese Veränderung nur darin, daß er aus dem Formular für die Patientensuche
sowohl einen neuen Datensatz anlegen, als auch einen bestehenden verändern kann. Da dieses Verhalten für die
Stammdatentabelle nicht nötig ist (Der Anwender muss schließlich nicht erst einen Patienten auswählen, um einen
neuen Patienten anzumelden) und die Laufzeit durch die Schreiboperationen nicht spürbar verlängert wird, wird
die momentane Lösung in dieser Form vorerst beibehalten.
5.3
Export, Datensicherung und Datenübermittlung
Damit die Eingaben auch tatsächlich für ein Benchmarking verwendet werden können, benötigen die Anwender
eine Möglichkeit, die Daten aus dem Programm zu exportieren und sie an die auswertende Stelle zu schicken. Bei
den PEDA-QS-Programmen erfolgt diese Datenübermittlung inzwischen über E-Mail. Das Programm bietet dafür
die Funktion „Datensicherung“, welche den momentanen Datenbestand in ein passwortgeschütztes ARJ-Archiv
packt.
Da Personalien für die vergleichende Qualitätssicherung nicht gebraucht werden, hat der Anwender auch die
Möglichkeit, die Daten bei einem Export zu „anonymisieren“. Hierbei handelt es sich tatsächlich um eine
Pseudonymisierung, da lediglich die Vor- und Nachnamen der Patienten unkenntlich gemacht werden, während
die Patientennummern und alle erfassten Geburtstage (Kind und Mutter) in den exportierten Daten verbleiben,
weil diese für die Auswertung benötigt werden.
Das pseudonymisierte Exportarchiv wird vom Anwender an die Arbeitsgruppe CAQM geschickt, welche die Daten
zuerst auf Verwertbarkeit überprüft und schließlich in die nächste Benchmarking-Auswertung einbringt.
Die nichtanonymisierte Fassung versteht sich als interne Datensicherung für die erfassende Stelle. Eine solche
Datensicherung kann im Havariefall oder bei einer Softwaremigration über die Funktion „Daten zurückspielen“
zum Wiederbefüllen der Tabellen verwendet werden.
Alternativ zu der ARJ-Archivierung können die Daten auch (in anonymisierter oder nichtanonymisierter Form)
unverschlüsselt als dBase-, Excel- oder CSV-Tabellen exportiert werden.
5.4
Arztbrief-Generator
Benchmarking zur Qualitätssicherung erfordert eine zuverlässige und aktuelle Datenbasis. Dies bedeutet teils
erheblichen Dokumentationsaufwand neben der alltäglichen Arbeit in der Patientenversorgung, was ohne weitere
Gegenleistung die Akzeptanz der leistenden Kräfte mindert. Um die Anwender unterstützend zu motivieren,
konsequent und aktuell Daten einzupflegen, ist es hilfreich, wenn ihnen dadurch an anderer Stelle die Arbeit
9
erleichtert wird. In anderen Worten: Programmfunktionen, welche aus rein epidemiologischer Sicht nicht
notwendig, aber für den Anwender nützlich sind, können (wenn auch nur indirekt) die Datenqualität erhöhen.
Eine solche Programmfunktion wäre die Möglichkeit, durch die Software Arztbriefe erstellen zu lassen, welche ihre
Diagnosedaten aus der angelegten Datenbasis ziehen. In DPV ist ein solches Modul bereits realisiert, welches auch
für die anderen Programme übernommen wurde. Es bietet die Möglichkeit, für ein einzelnes Untersuchungsdatum
einen Arztbrief zu erstellen, entweder in Form eines FoxPro-Berichts (Vorteil: Keine zusätzlichen Anforderungen an
den Computer des Anwenders; Nachteil: Die Gestaltung ist vom Endbenutzer nicht veränderbar) oder in Form
eines Serienbriefdokuments in Microsoft Word (Vorteil: Freie Gestaltung des Briefes durch den Anwender möglich;
Nachteil: Der Anwender benötigt eine Version von Microsoft Word).
Nachteile dieser Implementierung:
-
Es kann nur eine einzelne Untersuchung im ausgegebenen Arztbrief auftauchen.
-
Die Automation von Word wird mit veralteten DDE-Kommandos ausgeführt, welche spezifisch für eine Version
gewählt werden müssen.
-
undurchsichtiger, schwach kommentierter Quellcode
Aus der Idee, das Modul um die Möglichkeit zu erweitern, mehrere Untersuchungstermine auf einem generierten
Arztbrief erscheinen zu lassen, entstand das Projekt eines neuen, flexibleren Arzbriefmoduls, welches seit Mai 2008
versuchsweise in Hypothyreose und AGS eingesetzt wird. Die Erstellung eines integrierten Arztbriefes ist in dieser
Fassung nicht möglich, stattdessen verwendet das Modul ausschließlich Microsoft Word.
Kernstück der neuen Lösung ist die OLE-Automation eines vom Benutzer wählbaren Microsoft-Word-Serienbriefes,
welcher als Datenquelle eine von dem Programm generierte CSV-Datei benutzt. Die Verwaltung der verwendbaren
Vorlagen geschieht ebenfalls in diesem Arztbriefmodul: Über eine eigene Maske können neue Vorlagen angemeldet,
sowie bestehende Vorlagen verändert, dupliziert oder gelöscht werden. Um mit einer angemeldeten Vorlage einen
Brief zu generieren, wählt der Anwender in der Hauptmaske einen Patienten und einen Empfänger, sowie die
gewünschten Untersuchungstermine. Mit einem Klick auf „Ausgabe“ wird daraufhin die Automation gestartet:
Zuerst wird eine temporäre Datenbasis erstellt, mit einem Datensatz pro Empfänger. Eine Tabelle mit Metadaten
beschreibt, welche Felder in diese Datenbasis aufgenommen werden und deren Inhalt. Pro Datensatz in dieser
Tabelle werden zwei Spalten in der Datenbasis angelegt: Eine Spalte A mit dem nutzbaren Inhalt (zum Beispiel
Spalte „Name“, Inhalt: „p_vname + ' ' + p_nname“) und eine Spalte ADRUCK, welche aussagt, ob A sinnvollen Inhalt
enthält oder nicht. Beispiel:
GEW
GEWDRUCK
GEWE GEWEDRUCK
78,7
ja
kg
ja
0,3
nein
kg
ja
Die Verwendung dieser Felder in einer Word-Serienbriefvorlage könnte in diesem Fall lauten:
{IF{MERGEFIELD GEWDRUCK}="ja" "
Gewicht: {MERGEFIELD GEW}{MERGEFIELD GEWE}" ""}
Damit würde beim ersten Datensatz der Ausgabetext „Gewicht: 78,7 kg“, angeführt von einem Zeilenumbruch
stehen, während im zweiten Datensatz die Zeile inklusive Einheit und Beschriftung ausgelassen würde.
10
In der Tabelle mit den Datenbasisfeldern ist außerdem gespeichert, ob es sich bei dem Feld um ein einzeln
auftretendes Datum (zum Beispiel: Geschlecht des Patienten) oder um ein fortlaufendes handelt (zum Beispiel:
Untersuchungsdatum). Im letzteren Fall wird das betreffende Feld um die Anzahl der gewählten
Beobachtungstermine (sofern mehr als einer ausgewählt ist) vervielfältigt und durchnummeriert. Somit belegt ein
Verlaufsmerkmal bei der Auswahl von fünf Untersuchungsterminen in der Datenbasis zehn Spalten (fünf Termine
mal zwei, für Ausprägung und DRUCK-Feld).
Ist die Datenbasis erstellt, wird die OLE-Automation gestartet. In Word wird dadurch eine Kopie der Vorlage
geöffnet. Sollen mehrere Untersuchungstermine im Brief erscheinen, wird nun ein „Verlaufsbereich“ zwischen zwei
Textmarken vervielfältigt und die darin enthaltenen Merkmale per Suchen/Ersetzen durchnummeriert. Der so
manipulierten Vorlage wird daraufhin die Datenbasis zugewiesen und der Ausdruck eingeleitet.
Nachteil dieser OLE-Automation ist die vergleichsweise lange Rechenzeit, welche deutlich zunimmt, je mehr
Untersuchungstermine ausgewählt wurden. So benötigte ein Bericht für acht Termine mit (vor der
Vervielfältigung) 114 Datenfeldern auf einem AMD Athlon64 3000+ knapp vierzig Sekunden. Die gleiche Vorlage
für einen Bericht mit zwei Terminen benötigte zehn Sekunden, ein Bericht mit nur einem Termin unter drei
Sekunden (die Suchen/Ersetzen-Operation wird in diesem Fall nicht durchgeführt).
Eine Umgehung der Suchen/Ersetzen-Operation in Word durch direkte Dateimanipulation war nicht erfolgreich, da
Word nicht mehr in der Lage war, das extern veränderte Dokument korrekt zu öffnen.
5.5
Update-/Erstinstallationsroutine
Da das Programm stetig weiterentwickelt wird und man den Anwender an diesen Weiterentwicklungen auch
teilhaben lassen möchte, muss die Installation gewährleisten, daß eventuell bestehende Daten und
Benutzereinstellungen nicht überschrieben oder in anderer Form gefährdet werden. Erreicht wird diese
Absicherung bei Hypothyreose durch eine Aufteilung des Installations-, beziehungsweise Aktualisierungsvorgangs:
Das Installationsarchiv, erstellt mit dem skriptbasierten Setup-Werkzeug „InnoSetup“, entpackt die Auslieferung in
das angegebene Zielverzeichnis und überschreibt dabei alle eigentlichen Programmdateien mit den Dateien der
neuen Version, also alle Dateien außer den Tabellen, Datenbanken und Serienbriefen. Die neuen Versionen dieser
Dateien werden vorübergehend in einem Unterverzeichnis .\update\ gespeichert.
Der zweite Schritt der Aktualisierung findet in der Datei „vupdate.fxp“ statt, welche nach der Installation im
Programmverzeichnis liegt und deren Existenz bei jedem Programmstart abgefragt wird. Diese Datei enthält
Prozeduren zur Übertragung der Benutzertabellen in die neue Datenbank.
Die vupdate-Prozedur prüft zuerst die Existenz der vorherigen Datentabellen ab und unterscheidet damit, ob es sich
bei der Ausführung um eine Neuinstallation (keine Daten vorhanden) oder eine Aktualisierung („Update“) handelt.
Bei einer Neuinstallation werden schlicht die Datenbanken aus dem Update-Verzeichnis an ihre bestimmungsgemäßen Positionen verschoben, während bei einer Aktualisierung die Dateien in ihrer Verwendung unterschieden
werden. Es gibt hierbei drei Kategorien von Tabellen:
1. Tabellen, welche ausschließlich vom Benutzer gefüllt werden
(zum Beispiel die Stammdatentabelle „hypodb\hypo_stammdaten.dbf“)
2. Tabellen mit Systemeinstellungen, welche vom Benutzer geändert oder erweitert werden können (zum Beispiel
die Einheitendefinition „sysdb\einheit.dbf“)
11
3. Tabellen, auf deren Inhalt der Benutzer keinen Einfluß hat
(zum Beispiel die Tabelle mit dem ICD10-Register „sysdb\icd.dbf“)
In die erste Kategorie fallen alle Tabellen der „hypodb“-Datenbank. Bei diesen werden die Tabellen des updateVerzeichnisses mit den Daten der bestehenden Tabellen befüllt und danach die alte Datenbank durch die neue
ersetzt.
Die Datenbank „sysdb“ beinhaltet die Dateien der zweiten und dritten Kategorie. Für die Tabellen der zweiten
Kategorie ist jeweils eine individuelle Behandlung nötig, welche in einer neuen Programmversion aktualisiert
werden muss, sobald sich die Struktur der Tabelle ändert. Prinzipiell müssen dabei die Tabellen des updateVerzeichnisses um alle Benutzereingaben ergänzt werden, sofern sie in die neue Datenstruktur passen.
Sind diese Spezialbehandlungen abgeschlossen, wird die gesamte Datenbank „sysdb“ in das Zielverzeichnis
verschoben und überschreibt dabei die vorherige Version.
5.6
Teilnahme am Hypothyreose-Benchmarking
Um die Anwender davon abzuhalten, die Hypothyreosesoftware zu verwenden, ohne am Benchmarking
teilzunehmen, befindet sich das Programm nach der Erstinstallation in einem „Demo“-Modus. Wird in diesem
Zustand gestartet, erscheint vor der Benutzeranmeldung der Lizenzvertrag, welcher u.a. die Entwickler gegen
Haftungsansprüche bei Datenverlust absichern soll und der Anwender wird aufgefordert, der Lizenz zuzustimmen
oder weiterhin die Demoversion zu betreiben. In diesem Modus ist die Funktionalität des Programms dahingehend
eingeschränkt, daß lediglich zwei Patienten angelegt werden können und das Programm nur dreißig Tage vom
ersten Aufruf an betrieben werden kann.
Um die Hypothyreosesoftware dauerhaft nutzen zu können, muss von der Arbeitsgruppe CAQM eine Signaturdatei
angefordert werden, nach welcher verlangt wird, wenn der Anwender den Lizenzbedingungen zustimmt.
Wesentliches Element dieser Signaturdatei ist eine Zeichenkette, die „Signatur“, welche eindeutig eine
Anwenderstelle identifiziert. Diese Zeichenkette wird in jedem Datensatz der Patiententabellen zusätzlich
gespeichert, damit bei der Auswertung im Benchmarking ein Patientendatensatz dem erfassenden Zentrum
zugeordnet werden kann.
6
Veröffentlichung und Resonanz
Eine erste Version der Datenerhebungssoftware für Hypothyreose wurde im Frühjahr 2008 einer interessierten
Gruppe von Testpersonen zugänglich gemacht und am 12. April 2008 auf einer Konferenz der AQUAPE vorgestellt.
Rückmeldungen seitens der Endbenutzer sind seither (Stand Juni 2008) nicht eingetroffen, was nur wenig über die
Praxistauglichkeit
der
Version
aussagt,
da
die
Software
ihren
Haupteinsatzbereich
in
langfristigen
Beobachtungszeiträumen hat und sich durch die Spezifizierung auf eine Krankheit mit vergleichsweise geringer
Prävalenz (ca. 1:4000) nicht im alltäglichen Gebrauch befindet.
7
Zukunftsaussichten
Die weitere Entwicklung der Software wird sich vorerst auf eventuell nötige Fehlerbeseitigungen beschränken und
sich ansonsten analog zur Weiterentwicklung der Geschwisterprogramme verhalten. Seit dem letzten Update ist ein
12
Kontextmenü für die Eingabemasken hinzugekommen und eine Funktion zum automatischen Auslesen von
Stammdaten aus einer Krankenkassenkarte steht vor der Vollendung. Wirklich neue Anregungen speziell für
Hypothyreose werden vermutlich erst beim nächsten Anwendertreffen im November 2008 einfließen.
Da mittlerweile klar ist, daß Visual FoxPro künftig nicht mehr aktualisiert wird, drängt sich langfristig der Wechsel
der gesamten PEDA-QS-Familie auf eine andere Programmierplattform auf. Dieser Schritt würde die Programme
von vielen Altlasten befreien, welche entweder durch die lange Entwicklungsgeschichte von DPV (verfügbare
Technologien, welche nicht genutzt werden) oder durch Defizite in Visual FoxPro (zum Beispiel das fehlende
Grafikmodul oder der Umstand, daß immer noch Probleme mit Leerzeichen in Pfadangaben auftreten) begründet
sind.
13
Literatur
[1] Elterninformation des Neugeborenenscreening Heidelberg
http://www.klinikum.uni-heidelberg.de/fileadmin/kinderklinik/Abteilung_I/elterninfo_deutsch.pdf
[21.06.2008]
[2] Bekanntmachungen: Beschluss über eine Änderung der Richtlinien des
Bundesausschusses der Ärzte und Krankenkassen über die Früherkennung von
Krankheiten bei Kindern bis zur Vollendung des 6. Lebensjahres (Kinder-Richtlinien)
zur Einführung des erweiterten Neugeborenen-Screenings
vom 21. Dezember 2004
http://www.aerzteblatt.de/v4/archiv/artikel.asp?src=suche&id=46488 [21.06.2008]
[3] Reuter, P.: „Springer Lexikon Medizin“,
Springer-Verlag Berlin Heidelberg New York, 2004, ISBN 3-540-20412-1
[4] Qualitätssicherung in der Endokrinologie
http://www.paediatrische-endokrinologie.de/index.php?catid=22 [21.06.2008]
[5] Jahresbericht der AQUAPE 2005
http://www.med.uni-magdeburg.de/aquape/Links/Bericht_2005.pdf [21.06.2008]
[6] deutsche Wikipedia: xBase
http://de.wikipedia.org/wiki/Xbase [21.06.2008]