Datum: 26.1.1996
Version: 4
Verantwortliche: Prof. Dr. C. Ohmann
G. Belenky
Klinik für Allgemein- und Unfallchirurgie
Heinrich-Heine-Universität
Moorenstr. 5, 40225 Düsseldorf
Tel.: 0211/81-16142, 16149, 17403
Fax: 0211/316978
Copyright (c) Ohmann/Belenky/Keim/Otterbeck 1996, Heinrich-Heine-Universität Düsseldorf
| E-mail: |  Prof. C. Ohmann | |
| WWW | http://www.uni-duesseldorf.de/WWW/MedFak/TheoChir/ak_eval/Welcome.html |
Unter Mitarbeit von:
Dr. B. Puppe, Institut für Informatik, Universität Würzburg
K. Steinfatt, Technische Universität Hamburg-Harburg
R. Schmidt, Institut für Medizinische Informatik, Rostock
Inhaltsverzeichnis
0. Vorbemerkungen und Allgemeines
2. Validierung
3. Beurteilung von Funktionalität
und Benutzerfreundlichkeit
4. Beurteilung des klinischen Nutzens
In dem MEDWIS-Programm werden wissensbasierte Systeme unterschiedlichen Typs und mit verschiedenem Ziel und Inhalt erarbeitet. Dies umfaßt Wissensbasen, bei denen primär das Auffinden medizinischer Details anhand von Suchkriterien im Vordergrund steht, Lernhilfen mit dem Ziel des Trainierens von Nutzern durch Fakten und Erklärungen und Entscheidungshilfen zur konkreten Unterstützung bei der Lösung von Patientenproblemen unter Einbeziehung von Beratung, Vorschlägen und Kritiken (1). Die wissensbasierten Systeme unterscheiden sich hinsichtlich der Arbeitsfunktionen (z.B. Dolmetscher, Lotse, Lehrer, Stellvertreter, Schiedsrichter, Wachhund, Erinnerer, Simulator) aber auch im Hinblick auf die medizinischen Aufgaben, wobei fachübergreifende medizinische Themen (Lehr- und Tutoringsysteme, operative Therapie), spezielle klinische Themen (Stoffwechselkrankheiten, neurologische Krankheitsbilder) und die Unterstützung spezieller diagnostischer Leistungsbereiche (Bildverarbeitung, Labormedizin) und therapeutischer Leistungsbereiche (Arzneimittel, Intensivmedizin) im MEDWIS-Programm Berücksichtigung finden (2). Bei der Evaluierung muß selbstverständlich der Typ der Informationstechnologie, die evaluiert werden soll, berücksichtigt werden. Die Ziele der Evaluierung, die verwendeten Methoden und Instrumente unterscheiden sich beispielsweise bei einem PACS-System im Vergleich zu einer Chipkarte, einem Entscheidungsunterstützungssystem oder einem Informationssystem (3). In dem Leitfaden werden vornehmlich Aspekte der Evaluierung behandelt, die für alle Arten von wissensbasierten Systemen von Bedeutung sind. Spezielle Forderungen, die nur bestimmte Arten von Wissensbasen betreffen, werden als solche gekennzeichnet.
Bei der Evaluierung wissensbasierter Systeme sollen folgende Grundsätze beachtet werden:
Das methodische Vorgehen bei der Evaluierung ist als einzuhaltende Vorgabe im Rahmen der Projektplanung festzulegen. Die detaillierte Durchführung sollte, wie bei einer klinischen Therapiestudie, in einem Protokoll festgelegt werden (4). Wird kein Protokoll verwendet, so kann die Evaluierungsstudie allenfalls der Hypothesenfindung dienen. Eine Hypothesentestung ist nur bei einem vorher festgelegten Protokoll möglich. Darüberhinaus ist eine biometrische Konsultation zu empfehlen. Bei der Evaluierung des klinischen Nutzens eines wissensbasierten Systems sollte dieses Protokoll, wenn nötig, der Ethikkommission vorgelegt werden. Zu den Inhalten des Evaluierungsprotokolles gehören:
(i) Fragestellung, Ziel
(ii) Patienten
(iii) Methodik
(iv) Interventionen
(v) Zielkriterien
(vi) Untersuchungen und Beobachtungsparameter
(vii) Biometrie
(viii) Studienablauf am einzelnen Patienten
(ix) Ethik, einschl. Datenschutz
(x) Verantwortlichkeiten
b) Strategie
Wesentliches Merkmal der Evaluierung ist der Vergleich von Qualitätskriterien (z.B. Responsezeit, Richtigkeit) mit einem Referenzwert. Dabei sollten vorhandene Standards in der Literatur oder mindestens quasi-Standards verwendet werden. Durch den Vergleich soll überprüft werden, ob die gestellten Anforderungen erreicht werden (8, 9).
Die Evaluierung sollte sich an folgender Phaseneinteilung orientieren (7, 8):
(i) Verifizierung
(ii) Validierung
(iii) Beurteilung von Funktionalität und Benutzerfreundlichkeit
(iv) Beurteilung des klinischen Nutzens
Bei der Verifizierung steht die Demonstration der Konsistenz, Vollständigkeit und Richtigkeit der Software im Vergleich zur Spezifikation im Vordergrund. Bei der Validierung wird die Qualität und Eignung des Gesamtsystems unter Einbeziehung aller Komponenten (z.B. Wissenserwerb, Wissensbasis, Inferenzmaschine) im Hinblick auf das klinische Problem untersucht. Die Testung der Funktionalität und Benutzeroberfläche umfaßt Aspekte wie die Benutzbarkeit, die Akzeptanz, die Sicherheit, die Effizienz, die Zuverlässigkeit, die Flexibilität, die Modularität und die Portabilität. Die Evaluierung des klinischen Nutzens erfordert die Ermittlung der Auswirkungen des Systems auf Struktur, Prozeß und Ergebnis der Krankenversorgung.
Die Evaluierung ist ein iterativer und zyklischer Prozeß ("spiral life-cycle model" (5, 6). Immer dann, wenn ein Prototyp entwickelt oder modifiziert wurde, muß er reevaluiert werden, um mögliche Fehler zu entdecken. Diese Reevaluierung sollte entsprechend der Phaseneinteilung erfolgen. Sie sollte mit Verifizierung beginnen, an die sich Validierung, Evaluierung von Funktionalität und Benutzerfreundlichkeit und ggf. die Evaluierung des klinischen Nutzens anschließen sollte. Wegen der Komplexität des Evaluierungsprozesses sollte dabei ökonomisch vorgegangen werden. Nur solche Module, die signifikant verändert wurden, bedürfen einer vollständigen Reevaluierung.
e) Evaluierer
Der Evaluierungsprozeß muß Systementwickler, klinische Experten und potentielle zukünftige Nutzer einbeziehen. Die Rolle der verschiedenen Personengruppen bei den unterschiedlichen Phasen und Aspekten der Evaluierung muß spezifiziert werden.
Die Evaluierung sollte logische Testung, Laborstudien und Feldstudien umfassen (5). Wissensbasierte Systeme, die in der Klinik zur Anwendung kommen sollen, müssen unbedingt im klinischen Umfeld getestet werden. Laborstudien sind nicht ausreichend (8).
Bei der konventionellen Softwareerstellung versteht man unter Verifizierung die Untersuchung, ob ein Produkt in einer bestimmten Phase der Softwareentwicklung die Spezifikationen erfüllt oder nicht, die vorher festgelegt wurden (10). Verifizierung dient dazu, Fehler in der Software zu eliminieren und bestätigt, daß das Produkt entsprechend den Spezifikationen entwickelt wurde (11). Durch Verifizierung läßt sich die Frage "Bauen wir das System richtig?" beantworten (12). Im Zusammenhang mit wissensbasierten Systemen erfährt der Begriff Verifizierung eine Erweiterung. Zusätzlich zur Überprüfung, ob ein Produkt die festgelegten Spezifikationen erfüllt, dient die Verifizierung der Überprüfung der internen Konsistenz (6, 13). Verifizierung erfolgt während der Entwicklung eines wissensbasierten Systems. Es wird dabei als eine "gläserne Box" betrachtet.
Basierend auf den Wünschen und Anforderungen der Nutzer werden ein Anforderungsprofil und eine Systemspezifikation erarbeitet (8). Durch Verifizierung wird ermittelt, ob eine gegebene Entwicklungskomponente des wissensbasierten Systems die Spezifikation erfüllt oder nicht (13). Diese Definition der Verifizierung setzt voraus, daß ein wissensbasiertes System entsprechend vorgegebener Spezifikationen entwickelt werden sollte. Bei dem Softwareengineering sollte auf aktuelle Modelle (z.B. Spiralmodell, V-Modell) zurückgegriffen werden. Das V-Modell (Vorgehensmodell), welches vom Bundesministerium für Verteidigung und vom Bundesministerium des Inneren empfohlen wird, regelt die Softwareentwicklung mittels einer einheitlichen und verbindlichen Vorgabe von Aktivitäten (Tätigkeiten) und Produkten (Ergebnissen). Es umfaßt vier Submodelle: die Softwareerstellung, die Qualitätssicherung, das Konfigurationsmanagement und das Projektmanagement (35). Das Projektmanagement plant, kontrolliert und informiert die anderen drei Submodelle. Die Qualitätssicherung gibt Qualitätsanforderungen, Prüffälle und -kriterien vor und kontrolliert sowohl die Produkte als auch die Einhaltung der Standards. Das Konfigurationsmodell verwaltet die in den Submodellen erzeugten Produkte.
Ein wissensbasiertes System kann nur verfiziert werden, wenn die Wissensbasis zugänglich ist. Ein Experte muß in der Lage sein, auf einzelne Wissensmodule zugreifen zu können (13).
Bei regelbasierten Systemen sollten folgende Checks durchgeführt werden:
(ii) syntaktische Überprüfung
von Einzelregeln
(iii) strukturelle Überprüfung
des Regelwerkes
(i) semantische Überprüfung
von Einzelregeln
Jede einzelne Regel sollte dahingehend überprüft werden, ob die vorgegebene Syntax erfüllt ist und ob sie überhaupt anwendbar ist. Besser als die nachträgliche Überprüfung eingegebener Regeln auf ihre syntaktische Konsistenz ist eine graphische Eingabemaske, die nur syntaktisch richtige Regeln akzeptiert bzw. bei fehlerhaften oder unvollständigen Regeln den Wissensbasis-Architekten sofort auf die Mängel aufmerksam macht. Dadurch ist die syntaktische Richtigkeit sichergestellt. Gleichzeitig erspart man sich den großen Aufwand einer nachträglichen Überprüfung. Tests, mit deren Hilfe fehlerhafte oder inkonsistente Regeln entdeckt werden, sind der strukturellen Überprüfung zuzuordnen (13). Strukturelle Überprüfungen können durchgeführt werden, ohne die Bedeutung einzelner Regeln und Fakten zu kennen. Hierzu zählen unter anderem die Entdeckung von redundanten Regeln, von logischen Inkonsistenzen, von Zyklen und von Subsumierungen (6, 13). Darüber hinaus sollten ebenfalls Überprüfungen hinsichtlich der Vollständigkeit des Regelwerkes stattfinden. Unerwünscht sind Situationen, in denen das regelbasierte System nicht in der Lage ist, Schlußfolgerungen aufgrund der vorhandenen Daten zu ziehen (mangelnde Kompetenz). Die Identifikation von Kombinationen von Parametern, die mit den vorhandenen Regeln nicht abgedeckt werden, weisen auf fehlende Regeln hin. Je höher der Strukturierungsgrad der Regeln eines wissensbasierten Systems ist, um so anspruchsvoller kann die strukturelle Überprüfung sein. Besteht das System nur aus Einfachregeln (wenn Einzelsymptom X, dann Diagnose Y), kann überprüft werden, ob es für jedes Symptom der Wissensbasis eine zugehörige Regel gibt. Bei komplexer Regelsyntax (mehr oder weniger komplexe Verknüpfungen von Symptomen in der Regelvorbedingung) kann sich die Überprüfung auch auf höhere Strukturierungsprinzipien beziehen. Allerdings sind Struktur und Semantik sehr eng aufeinander bezogen, so daß formalen Prüfungen enge Grenzen gesetzt sind. Bei einer Vielzahl von Variablen läßt sich aufgrund der kombinatorischen Explosion ein solcher automatischer Check nicht mehr durchführen, dann sind bestimmte Methoden einzusetzen (6). Die semantische Testung dient der Identifkation von nicht zulässigen Werten bei Variablen und ähnlichen Fehlern. Hierbei handelt es sich ausschließlich um formale Fehler, die Einschätzung einer einzelnen Regel oder eines regelbasierten Systems im Hinblick auf den klinischen Wert ist Teil der Validierung.
Die Kosistenztestung bei fallbasierten Systemen umfaßt die folgenden Maßnahmen:
zu (1): Jeder einzelne Fall in der Fallsammlung des Systems muß auf Vollständigkeit und Konsistenz der Falldaten überprüft werden. Man kann sich die nachträgliche Prüfung sparen, wenn die Falldaten über eine Datenerfassungsmaske eingegeben werden, welche die erforderlichen Checks sofort ausführt und sich bei Eingabefehlern oder fehlerhaften bzw. unvollständigen Daten meldet. Werden Fälle aus Datenbanken übernommen, ist die syntaktische Konsistenzprüfung besonders wichtig.
zu (2): Wenn sich die Fallsammlung über einen längeren Zeitraum erstreckt, kann sich die Schwierigkeit ergeben, daß der medizinische Fortschritt (neue Methoden, Diagnosen, Befunde etc.) Änderungen der Befunddokumentation bewirkt, was zur Inkonsistenz der Daten von alten und neuen Fällen führt. Die Inkonsistenzen können durch Abbildung der Daten alter Fälle auf das neue Befunddokumentationsschema (falls möglich), oder umgekehrt durch die Abbildung der Daten neuer Fälle auf das alte Schema der Befunddokumentation beseitigt werden. Dies ist jedoch mühsam und ohne Abstriche an der Datenqualität kaum durchführbar.
Für jede zu stellende Diagnose muß überprüft werden, ob es in der Fallsammlung eine bestimmte Mindestzahl von Fällen gibt, die dem Retrieval zur Verfügung stehen.
Zu (3): Vorab sollte spezifiziert werden, welchen Bedingungen die vom Retrieval ausgewählten Fälle genügen sollen. Dann ist zu überprüfen, in wie weit das Retrieval diese Spezifikation erfüllt. Abhängig vom gewählten Schema des Fallvergleichs ist zu überprüfen, ob die Fallvergleichskriterien über alle Befunde und Diagnosen konsistent implementiert wurden. Da die Semantik zahlreiche Besonderheiten und Ausnahmen bedingt, sind formalen Prüfmethoden dabei enge Grenzen gesetzt.
2. Validierung
Bei dem klassischen Softwaredesign versteht man unter Validierung den Prozeß der Software-Evaluierung am Ende des Entwicklungsprozesses mit dem Ziel, die Übereinstimmung mit den Anforderungen sicherzustellen (10). Die Validierung bestätigt, daß die Wissensbasis korrekt ist und daß die vorgesehenen Aufgaben erfüllt werden können. Durch die Validierung läßt sich die Frage "Bauen wir das richtige System?" beantworten (12). Im wesentlichen dient die Validierung also dazu, die Richtigkeit und Zuverlässigkeit des in der Wissensbasis enthaltenen Wissens zu überprüfen (6). Um die Entwicklung unbrauchbarer Programme zu verhindern, sollte die Validierung schon während des Entwicklungsprozesses einsetzen, um gegebenenfalls Korrekturen vornehmen zu können. Selbstverständlich kann an einen klinischen Einsatz nur gedacht werden, wenn die endgültige Wissensbasis umfassend validiert wurde.
Für die Validierung lassen sich
die folgenden Grundsätze formulieren:
a) Programmunabhängige Wissenstestung
Das wissensbasierte System sollte unabhängig von der konkreten Implementation unter Negierung von Aspekten wie Funktionalität und Benutzerfreundlichkeit getestet werden. Dabei sollte ausschließlich die Qualität des Wissens anhand der Ergebnisse gemessen werden. Eine programmunabhängige Wissenstestung setzt jedoch voraus, daß der Kontext, in dem Wissen verwendet wird, berücksichtigt werden kann.
b) Schrittweises Vorgehen
Die Validierung sollte schrittweise duchgeführt werden, beginnend mit der Beurteilung einzelner Wissensmodulen, dann der Untersuchung von logischen Beziehungen zwischen Modulen und schließlich einer Überprüfung des gesamten wissensbasierten Systems.
c) Bewertungsmaßstab
Wesentliches Element der Validierung ist der Vergleich der vom System erzielten Ergebnisse mit einem Referenzwert, dem sogenannten Goldstandard (8, 9). Dieser Standard sollte möglichst weitgehend mit der Wirklichkeit übereinstimmen. Für die Ermittlung eines Goldstandards gibt es, abhängig vom Problem, unterschiedliche Vorgehensweisen. Bei Diagnosesystemen sollte eine möglichst hohe Diagnosesicherheit angestrebt werden. Die Diagnosesicherheit kann beispielsweise anhand des folgenden Schlüssels erfaßt werden:
C1: Standarddiagnostik, C2: Spezielle Diagnostik (z..B. Ultraschall), C3: Operation, C4: Pathologie, C5: Autopsie (14). Bei andersgearteten Problemstellungen, etwa bei Therapieempfehlungen, gibt es häufig keinen objektiven Standard. In solchen Situationen sollte man versuchen Quasi-Standards zu verwenden. Ist das nicht möglich, so sollten klinische Experten zur Bewertung hinzugezogen werden. Um zu verhindern, daß die Einschätzung mit Fehlern behaftet ist, sollte dies von externen Experten vorgenommen werden (15). Der Bewertungsmaßstab sollte unbedingt vor einer Evaluierung des wissensbasierten Systems festgelegt werden, um weitere Fehlerbildungen zu vermeiden.
Bei der Bewertung durch externe Experten sollte die Variabilität der Einschätzung, gemessen an der Test-Retest-, der Intrabeobachter- und der Interbeobachtervariabilität erfaßt werden. Standardmaße der Übereinstimmung, wie z.B. die k-Statistik, sollten dabei Anwendung finden (6). Um den Grad der Beobachtervariation zu reduzieren, empfiehlt sich die Durchführung von Gruppenprozessen, wie z.B. die Delphi-Technik oder nominale Gruppenprozesse (5, 16).
d) Ort der Validierung
Die Validierung des wissensbasierten Systems sollte sowohl im Labor als auch in der klinischen Anwendung erfolgen. Letzteres sollte in prospektiven Studien unter kontrollierten Bedingungen durchgeführt werden und reproduzierbare Ergebnisse liefern. Der Sinn der Validierung in einer Feldstudie liegt darin zu überprüfen, ob die im Labor unter experimentellen Bedingungen erzielten Ergebnisse bei Anwendung in der Klinik reproduziert werden können. Die Übertragbarkeit vom Labor in die Klinik oder von einer Klinik in die andere ist nicht immer gegeben, nicht zuletzt wegen der Unterschiede in der Terminologie, im Patientengut, der Datensammlung und der Organisationsstruktur.
e) Testfälle
Die Testung der gesamten Wissensbasis erfolgt am sinnvollsten mit Testfällen. Um aussagekräftig zu sein, müssen die Testfälle bestimmten Qualitätskriterien genügen (6, 13). Die Testfälle sollten aus dem klinischen Anwendungsgebiet stammen. Es sollte sich wenn möglich um tatsächliche klinische Fälle handeln, wobei eine prospektive Datensammlung unter qualitätskontrollierten Bedingungen vorzuziehen ist. Sollte dies nicht möglich sein, sollten die Fälle durch unvoreingenommene Experten erzeugt worden sein. Darüberhinaus sollten die Testfälle einen unterschiedlichen Schwierigkeitsgrad besitzen und möglichst viele Aspekte des Systems testen (13). Um den Wert einer Validierung einschätzen zu können, bedarf es einer genauen Beschreibung des Testdatensatzes, z.B. mit Fallzahl, Art der Datensammlung (prospektiv, retrospektiv), Art und Umfang der zur Anwendung gekommenen Regeln (bzw. Wissensmodule bei anderen Wissensdarstellungen) und die Verteilung des Zielkriteriums (z.B. Diagnosen).
e) Durchführung der Validierung
Optimistisch verfälschte Ergebnisse sind zu erwarten, wenn Lernfälle, mit denen das wissensbasierte System aufgebaut wurde, auch bei der Testung verwendet werden (17). Eine klare Trennung von Trainings- und Testfällen ist daher ein unbedingtes Muß bei der abschließenden Validierung, eine Mehrfachbenutzung eines Falles ist nicht zulässig. Darüberhinaus sollte die Validierung unbedingt von unabhängigen Experten durchgeführt werden. Selbstverständlich sollte die Validierung prospektiv und unter kontrollierten Bedingungen erfolgen.
f) Auswertung
Für die Auswertung der Validierung sollten statistische Methoden herangezogen werden. Die Vorhersagen aufgrund des wissensbasierten Systems sollten mit dem Standard verglichen werden und anhand von Standardmaßen (z.B. Sensitivität, Spezifität, Richtigkeit, prädiktiver Wert) beurteilt werden. Für die Einschätzung der Variabilität sollten Konfidenzintervalle hinzugezogen werden. Wann immer möglich sollten ebenfalls statistische Tests durchgeführt werden, z.B. zum Vergleich der Richtigkeit der Vorhersage des Arztes und des wissensbasierten Systems.
3. Evaluierung von Funktionalität und Benutzerfreundlichkeit
Eine umfassende Evaluierung der Funktionalität und Benutzerfreundlichkeit ist unbedingte Voraussetzung für die erfolgreiche Anwendung wissensbasierter Systeme in der klinischen Routine. Die grundsätzliche Vorgehensweise besteht darin, zur Charakterisierung der Qualität eines Softwareproduktes einzelne Qualitätsmerkmale zu definieren und dann separat zu testen. Für die Evaluierung einzelner Aspekte gibt es unterschiedliche Vorgehensweisen, Studientypen und Instrumente, die im folgenden beschrieben werden:
a) Allgemeines Vorgehen
Die Evaluierung von Funktionalität und Benutzerfreundlichkeit sollte sowohl im Labor als auch in der klinischen Anwendung erfolgen. Sie sollte während der Entwicklung, unmittelbar vor Einführung in die Klinik und bei routinemäßiger Anwendung durchgeführt werden.
b) Merkmale der Evaluierung
Zwei Gruppen von Merkmalen können unterschieden werden. Zum einen sind dies Qualitätsmerkmale, deren Bewertung primär Sache der zukünftigen Nutzer ist. Hierzu zählen:
Dies umfaßt vor allen Dingen die Benutzeroberfläche, aber auch Aspekte der Implementation, der Operabilität, der Gewöhnung, der Kommunikativität, des Verhältnisses von Input/Output und der Einheitlichkeit der Datendarstellung (4). Zur Benutzerfreundlichkeit gehört auch die Verständlichkeit mit Merkmalen wie Selbstbeschreibungsfähigkeit, d.h. die Bereitstellung ausreichender Information für die Benutzer um die Ziele, die Voraussetzungen, die Umgebungsbedingungen, den Input, den Output, die Komponenten und den Status erkennen zu können, die Kürze der Darstellung unter Vermeidung der Präsentation von exzessiver Information und die Leserlichkeit der Information (12). Standards für die Erstellung von Bildschirmmasken und Dialogen sollten unbedingt verwendet werden (z.B. 18, 19). Dabei sollte auf "style guidelines" der verschiedenen Platformen und auf allgemeine Richtlinien und Normen (z.B. DIN 66234) Rücksicht genommen werden.
(ii) Effizienz
Einen besonders kritischen Punkt bei der klinischen Anwendung wissensbasierter Systeme stellt die Reaktionszeit dar. Es ist notwendig die Ausführungszeit für bestimmte Funktionen und Eingaben quantitativ zu ermitteln. Dies umfaßt auch den Zeitaufwand, der vom Nutzer benötigt wird, um auf bestimmte Programmkomponenten, Funktionen oder Bildschirme zugreifen zu können (4).
(iii) Zuverlässigkeit
Die Zuverlässigkeit betrifft unter anderem Fehler in der Bedienungsanleitung, in den Bildschirmmasken und im Programm (4). Weitere Aspekte sind die Fehlertoleranz und -behandlung.
Darüberhinaus gibt es Qualitätsmerkmale, deren Testung die Einbeziehung von Softwareexperten erforderlich macht. Dies sind:
(iv) Testbarkeit
Die Fähigkeit zur Testbarkeit wissensbasierter Systeme basiert auf Eigenschaften wie Modularität, Einfachheit und Selbstbeschreibungsfähigkeit (21). Voraussetzung sind ein informatisches Konzept und Softwaredesign und -entwicklung basierend auf den anerkannten Methoden des Softwareengineering (z.B. 21, 22).
(v) Wartbarkeit
Hierunter versteht man Möglichkeiten, die Software funktionsfähig zu erhalten. Dies schließt auch die Fähigkeit zum Updaten der Software ein.
Voraussetzung für den Einsatz in der klinischen Routine ist
die Evaluierung des wissensbasierten Systems hinsichtlich der
Sicherheit und der Einhaltung der für den medizinischen Bereich
zutreffenden Datenschutzbestimmungen. Der Evaluierung des Systems
geht die Ermittlung der Schutzbedürftigkeit der Daten, eine
Bedrohungs- und Risikoanalyse voraus. Darauf aufbauend muß
ein Sicherheitskonzept erstellt werden. Es wird empfohlen, nach
dem IT-Sicherheitshandbuch
des Bundesamtes für Sicherheit in der Informationstechnik
vorzugehen. Der Datenschutzbeauftragte des Krankenhauses sollte
bei der Erstellung eines Konzeptes zum Risikomanagement
miteinbezogen werden. Sicherheitsvorkehrungen müssen
verhältnismäßig und finanzierbar, aber auch für
den Benutzer leicht handhabbar sein.
Der Umgang mit personenbezogenen Daten im medizinischen Bereich
unterliegt zahlreichen gesetzlichen Bestimmungen. Bei der Evaluierung
ist zu prüfen, ob diesen Bestimmungen Rechnung getragen wird.
Dazu gehören das Bundesdatenschutzgesetz (BDSG), insbesondere
die Anlage 1 zu § 9 (technischer Datenschutz), § 9 (technischer
Datenschutz), § 203 StGB (Arztgeheimnis), das Sozialgesetzbuch
V, das im jeweiligen Bundesland gültige Landesdatenschutzgesetz,
Krankenhausgesetz und die Berufsordnung für Ärzte.
Zu den in der Anlage 1 zu den § 9 BDSG genannten "10
Geboten des Datenschutzes" gehören: Zugangskontrolle,
Datenträgerkontrolle, Speicherkontrolle, Benutzerkontrolle,
Zugriffskontrolle, Übermittlungskontrolle, Eingabekontrolle,
Auftragskontrolle und die Organisationskontrolle. Bei der Verarbeitung
sensibler medizinischer Daten kommen einer geeigneten Benutzer-
und der Zugriffskontrolle besondere Bedeutung zu. Deshalb sind
Verfahren zur Identifikation und Authentifikation der Benutzer
vorzusehen. Flankiert werden diese Maßnahmen durch ein organisatorisches
Umfeld, das z.B. Regelungen bei der Einstellung und beim Ausscheiden
von Mitarbeitern festlegt.
- Zuverlässigkeit und
Verfügbarkeit
Wird das wissensbasierte System in der klinischen Routine eingesetzt,
so sind geeignete Maßnahmen zu treffen, die die Verfügbarkeit
des Systems sicherstellen. Dazu gehört ein Continuity-Planning
mit einem Backup-Service.
- Integrität
Zur Gewährleistung der Integrität des Systems
gehören geeignete Maßnahmen zur Abwehr von Viren, Würmern
und trojanischen Pferden. Zum Sicherheitskonzept gehören
Bestimmungen, wie bei dem Verdacht auf Angriffen vorzugehen ist.
Bei Problemen mit Personal Computern kann das MicroBIT Virus Center
an der Universität Karlsruhe oder das Virus Test Centrum
an der Universität Hamburg um Rat gefragt werden. Bei Problemen
im Bereich UNIX und Netze ist das Computer Emergency Response
Team des DFN-Vereins (DFN-CERT) an der Universität Hamburg
ein geeigneter Ansprechpartner. Ist das wissensbasierte System
an ein Weitverkehrsnetz angeschlossen, sind Firewalls vorzusehen
und zusätzliche Penetrationstests durchzuführen.
Bei der Bewertung der Flexibilität steht die Möglichkeit zur Anpassung des wissensbasierten Systems auf neue Umgebungen oder neue klinische Bereiche im Vordergrund. Die Flexibilität wird wesentlich bestimmt durch den Grad der Parametrierbarkeit der Software.
(viii) Portabilität
Die Portabilität wird charakterisiert durch den Grad der Hardwareunabhängigkeit.
Ein wissensbasiertes System muß bezüglich aller oben
genannten Qualitätsaspekte evaluiert werden.
(ix) Interoperabilität
Hierbei soll festgestellt werden, in welchem Grade sich das wissensbasierte
System in andere Systemumgebungen integrieren läßt.
Es ist zu überprüfen, ob vorhandene Standards für
Schnittstellen (z.B. HLZ) berücksichtigt
werden. Darüberhinaus ist von Interesse, ob Standards zum
Wissensaustausch (z.B. ARDEN-Syntax)
verwendet werden.
c) Studientypen
Für die Evaluierung von Aspekten der Funktionalität und Benutzerfreundlichkeit gibt es unterschiedliche Studientypen:
Hierunter versteht man die Beobachtung von Anwendern während der Benutzung des Systems. Sie sollte in allen Phasen der Systementwicklung im Labor und nach Abschluß im klinischen Anwendungsbereich erfolgen. Beobachtungsstudien sind ein wichtiges Instrument, um eine gute Softwarequalität zu erreichen (5). Beobachtungsstudien dienen der Erfassung von Bemerkungen, Kritiken und Empfehlungen durch Beobachter während der Lern- und Anwendungsphase von Nutzern. Sie sind geeignet die Benutzerfreundlichkeit aber auch Aspekte der Effizienz und Zuverlässigkeit einzuschätzen. Beobachtungsstudien sind prospektiv und setzen ein Protokoll voraus, in dem festgelegt wird was beobachtet werden soll und wie es beobachtet werden soll (16).
(ii) Logbuchstudien
Bei entsprechender Planung und Realisierung können gewisse Daten bei der Programmbenutzung automatisch erfaßt werden ("automatic data logging" (16)). Alle Nutzer- und Programmaktionen mit Zeiterfassung können aufgezeichnet werden. Logbuchstudien sollten Teil jeder Evaluierung sein und Aspekte wie Effizienz, Sicherheit und Zuverlässigkeit evaluieren. Dies sollte jedoch nicht dauerhaft stattfinden und vor allen Dingen anonymisiert durchgeführt werden.
(iii) Reaktionsstudien
Hierunter soll die Erfassung von Nutzerkommentaren durch zusätzliche Eingabemöglichkeiten im Programm verstanden werden (4). Damit können Kommentare erfaßt werden, ohne daß ein störender Beobachter notwendig ist. Um eine möglichst strukturierte und präzise Nutzerantwort zu erhalten, sollten an entsprechenden Stellen des Programmes verschiedene vorgegebene Eingabemöglichkeiten präsentiert werden und der Anwender sollte aufgefordert werden, die am ehesten zutreffende Aussage auszuwählen. Die Anwender sollten jedoch nicht durch zuviele zusätzliche Masken oder Tastatureingaben unnötig belästigt werden. Reaktionsstudien sollten sowohl bei der Bewertung von Benutzerfreundlichkeit, Sicherheit, Effizienz und Zuverlässigkeit Anwendung finden, können aber auch zur Unterstützung der Validierung eingesetzt werden. Wegen des Eingabeaufwandes sollten Reaktionsstudien zeitlich begrenzt durchgeführt werden.
(iv) Nutzerumfrage
Besonders nützlich ist die Erfassung der Benutzerfreundlichkeit und anderer Aspekte der Funktionalität in der klinischen Anwendung mit Hilfe einer Umfrage (5). Hier bieten sich Interviews oder Fragebogenaktionen an (16). Nutzerumfragen sind unabdingbarer Bestandteil jeder Evaluierung wissensbasierter Systeme. Sie setzen ein Studienprotokoll und die Verwendung evaluierter Instrumente mit standardisierten Antwortskalen voraus (23, 24, 9). Um den Aufwand zu begrenzen, sollten diese Umfragen in Zusammenarbeit mit Nutzern erfolgen.
d) Weitere Aspekte
Testbarkeit, Wartbarkeit, Sicherheit, Flexibilität, Portabilität und Interoperabilität sind vornehmlich Aspekte, die im Zusammenhang mit dem Design und der Struktur des wissensbasierten Systems zu sehen sind (4). Grundlage jeder Einschätzung sind eine adäquate Beschreibung von Design und Architektur des Produktes aus Sicht der Entwickler mit Hilfe der Entwicklungs- und Produktdokumentation. Darüberhinaus sollte angestrebt werden, bestimmte Softwareeigenschaften, wie z.B. Modularität, Selbstbeschreibungsfähigkeit und Einfachheit durch unabhängige Softwareexperten beurteilen zu lassen (4). Schließlich stellt die Beurteilung des Produktes aus Sicht des Anwenders hinsichtlich Support, Update, etc. ein wesentliches Element des Evaluierungsprozesses dar.
4. Evaluierung des klinischen Nutzens
Bei der Evaluierung des klinischen Nutzens werden Auswirkungen des Einsatzes von wissensbasierten Systemen auf die Anwender, die Organisation, die Gesundheitsversorgung, und die Qualität der Patientenversorgung untersucht (7, 8). Entsprechend den Grundsätzen der Qualitätssicherung werden zwischen Effekten auf die Struktur, den Prozeß und die Ergebnisse der Krankenversorgung unterschieden (9, 25). Der klinische Nutzen oder Schaden kann nur eingeschätzt werden, wenn Feldstudien im tatsächlichen klinischen Anwendungsbereich durchgeführt werden. Die Evaluierung des klinischen Nutzens stellt den mit Abstand schwierigsten Schritt im Evaluierungsprozeß dar. Es wird empfohlen Evaluierungsstudien zum klinischen Nutzen der zuständigen Ethikkommission vorzulegen.
a) Allgemeines Vorgehen
Die Evaluierung des klinischen Nutzens erfolgt nach Abschluß der Entwicklungsarbeiten, nachdem alle anderen Phasen der Evaluierung durchlaufen sind. Voraussetzung ist eine Feldstudie im klinischen Anwendungsbereich, die nach Möglichkeit als kontrollierte Studie durchgeführt werden sollte. Die Studie sollte bestimmte Qualitätskriterien erfüllen, vor allen Dingen sollte sie prospektiv sein und Fehler sowie Einflußfaktoren sollten kontrolliert werden.
4.1 Merkmale der Evaluierung
Eine vollständige Evaluierung des klinischen Nutzens umfaßt die folgende Aspekte:
(i) Strukturqualität
Die Strukturqualität der Krankenversorgung wird beeinflußt durch Faktoren wie Ausbildung, Fort- und Weiterbildung und Ausstattung des ärztlichen Arbeitsplatzes (Geräte, Infrastruktur). Im Rahmen der Evaluierung von wissensbasierten Systemen sollte daher untersucht werden, in welchem Maße sie die Strukturqualität im Krankenhaus verändern. Da der Einsatz von wissensbasierten Systemen häufig mit Lerneffekten verbunden ist, sind Effekte auf den Ausbildungsstand des Arztes durchaus denkbar. Ein anderer Effekt könnte darin bestehen, daß Informationen schneller, aktueller und mit besserer Qualität zur Verfügung gestellt werden.Im Zusammenhang mit der Strukturqualität sollte weiterhin untersucht werden, inwieweit das wissensbasierte System in die beabsichtigte Umgebung eingepaßt werden kann (9). Hierunter fallen Aspekte, wie z.B. die Frage, ob für den Einsatz des wissensbasierten Systems ausreichend Daten vorliegen, ob das wissensbasierte System im klinischen Ablauf zugänglich ist und wie das System mit anderen Quellen der Wissensbeschaffung integriert ist. In diesem Zusammenhang sollte darauf hingewiesen werden, daß Information selber in der Regel einen geringen Effekt auf das Verhalten des Arztes und auf die Qualität der Krankenversorgung hat (4). Medizinische Meinungsmacher oder eine strenge Führung des medizinischen Personals haben dagegen einen großen Einfluß. Bei Feldstudien zur Strukturqualität sollten daher unbedingt die Führungsrolle des Vorgesetzten und die verwendeten Kontrollmechanismen berücksichtigt werden.
(ii) Prozeßqualität
Den wesentlichen Punkt der Evaluierung des klinischen Nutzens stellen die Effekte auf den Prozeß der Krankenversorgung dar. Auswirkungen auf den Prozeß der Krankenversorgung sind Voraussetzung, um die Ergebnisse der Krankenversorgung verändern zu können. Während die Effekte eines wissensbasierten Systems auf die Ergebnisse der Krankenversorgung nur schwer und indirekt nachweisbar sind, lassen sich Änderungen im klinischen Ablauf eher nachweisen. Beispielsweise könnte der Effekt eines computerunterstützten Diagnosesystems durch die verbesserte Diagnosestellung, die Vermeidung zusätzlicher Untersuchungen, die schnellere Diagnosestellung und Therapiewahl nachgewiesen werden. Die Einschätzung der Prozeßqualität sollte klinische Aspekte (z.B. Auswirkungen auf Diagnosestellung und Therapiewahl), organisatorische Aspekte (z.B. Zufriedenheit des Personals, Arbeitsbelastung, Änderung der Tätigkeitsmerkmale), ökonomische Effekte (z.B. Kosten, Nutzen) und andere Aspekte, wie z.B. ethische und juristische Fragen umfassen (3). Entsprechend dem Typ des wissensbasierten Systems und der klinischen Fragestellung bedarf es der Aufstellung definierter Kriterien zur Messung der Prozeßqualität. Standards in der Literatur müssen dabei berücksichtigt werden.
(iii) Ergebnisqualität
Effekte auf die Ergebnisse der Krankenversorgung durch wissensbasierte Systeme sind von übergeordnetem Interesse, jedoch wegen vieler Einflußfaktoren sehr schwierig nachzuweisen (26). Die wichtigsten Maße der Ergebnisqualität sind folgende: Funktion bzw. Lebensqualität, Morbidität und Mortalität (3). Sollte ein wissensbasiertes System bis zur klinischen Serienreife gelangen, so ist der Nachweis der Ergebnisqualität zu fordern.
Im Zusammenhang mit der Ergebnisqualität sollte unbedingt zwischen "efficacy" und "effectiveness" unterschieden werden (27). "Efficacy" bezieht sich auf die Leistungsfähigkeit eines wissensbasierten Systems unter kontrollierten Studienbedingungen, "effectiveness" dagegen auf die Leistungsfähigkeit in der klinischen Routine.
Wissenschaftlicher Standard für den Nachweis von Therapieeffekten ist die randomisierte kontrollierte klinische Studie. Dieses Studiendesign wirft jedoch bei wissensbasierten Systemen erhebliche Probleme auf, da hier eine Vielzahl möglicher Fehler und Einflußgrößen zu berücksichtigten sind (9, 28). Die wichtigsten Stör- und Einflußgrößen sind (9):
Um den Einfluß positiver bzw. negativer Einstellungen gegenüber wissensbasierten Systemen einzuschränken, sollte wenn möglich eine weitgehende Verblindung stattfinden. Die Beurteilung von Krankheitsverläufen sollte beispielsweise von unabhängigen Beobachtern durchgeführt werden, ohne daß Kenntnis darüber besteht, ob das wissensbasierte System eingesetzt wurde oder nicht.
(ii) Enthusiasmus
Da wissensbasierte Systeme häufig am Ort der Entwicklung eingesetzt werden, besteht die Gefahr durch besonderes Engangement der Entwickler (z.B. 24-Std.-Service) die Ergebnisse zu verfälschen. Enthusiasmus ist eine häufige Fehlerquelle und sollte daher unbedingt kontrolliert werden (29). Eine einfache Möglichkeit ist die Testung des wissensbasierten Systems in neuen klinischen Umgebungen.
(iii) Zirkularität
Zirkularität stellt meist dann ein Problem dar, wenn die Entwicklung und Evaluierung durch das gleiche Team vorgenommen wird. Ein klassischer Fehler, der unbedingt vermieden werden muß, ist das Trainieren und Testen auf dem gleichen Datensatz. Die Folge sind optimistisch verfälschte Ergebnisse (17). Zirkularität entsteht auch dann, wenn diagnostische Parameter, die als Input für ein wissensbasiertes System verwendet werden, auch zur Festlegung der endgültigen Diagnose dienen. Gefordert werden muß eine von den Entwicklern unabhängige Evaluierung eines wissensbasierten Systems.
(iv) Statistische Fehler
Für die Evaluierung des klinischen Nutzens wissensbasierter Systeme gelten bezüglich der Fallzahlschätzung die gleichen Regeln wie für randomisierte Therapiestudien.- und ß-Fehler müssen im Rahmen der Studienplanung festgelegt und aufgrund verfügbarer Daten muß der Stichprobenumfang festgelegt werden.
(v) Hawthorne-Effekt
Allein die Tatsache, daß eine Evaluierungsstudie durchgeführt wird und die Ärzte sowie das Pflegepersonal unter Beobachtung stehen, führt in der Regel zu einer Verbesserung der Ergebnisse (30). Um eine Abschätzung des Hawthorne-Effektes vornehmen zu können, empfiehlt sich die Durchführung einer Basisphase vor Einsatz des wissensbasierten Systems, wobei dies möglichst ohne Wissen der Ärzte durchgeführt werden sollte.
(vi) Checklist-Effekt
Der Einsatz wissensbasierter Systeme führt häufig zu einer vollständigeren und besseren Datensammlung. Dieser Checklist-Effekt allein kann die Ergebnisse signifikant verbessern (31) und muß kontrolliert werden. Eine Möglichkeit besteht darin, die Datensammlung in allen Studiengruppen zu standardisieren oder bei einer Gruppe von Patienten nur die Datensammlung durchzuführen, um den quantitativen Einfluß abschätzen zu können.
(vii) Carry-over-Effekt
Der Carry-over-Effekt entsteht durch den Umgang der Nutzer mit dem wissensbasierten System. Durch die Aus- und Weiterbildung mit dem computerunterstützten System sind Übertragungseffekte möglich, auch wenn das wissensbasierte System bei einem Patienten nicht zur Anwendung kommt (32). Carry-over-Effekte sollten ebenfalls kontrolliert werden, beispielsweise durch die Randomisierung von Ärzten anstelle von Patienten.
(viii) Sekulare Trends
Durch eine lange Studiendauer, aber auch durch historische Vergleichsgruppen besteht die Gefahr, daß abgesehen vom eigentlich interessierenden wissensbasierten System andere signifikante Einflußfaktoren (z.B. organisatorische Änderungen, neue Technologie) zur Anwendung kommen. Durch die Vermeidung historischer Kontrollen und durch kurze Laufzeiten muß dieser Fehler verhindert werden.
(ix) Feedback/Audit
Durch die Durchführung eines systematischen Feedbacks mit Information der Ärzte über Erfolge bzw. Mißerfolge in der Diagnostik und Behandlung, lassen sich bekanntermaßen die Ergebnisse signifikant verbessern (31). Durch eine Gruppe mit und ohne Feedback läßt sich dieser Effekt quantifizieren.
4.3 Studientypen
Im folgenden sollen die verschiedenen Studientypen unter Berücksichtigung der Eignung für den Nachweis des klinischen Nutzens wissensbasierter Systeme dargestellt werden. Grundsätzlich sind die Qualitätsmerkmale von Therapiestudien auch auf Evaluierungsstudien übertragbar. Dies bedeutet: prospektiv besser als retrospektiv, kontrolliert besser als unkontrolliert, randomisiert besser als nicht randomisiert, gleichzeitige Kontrollen besser als historische Kontrollen, große Fallzahl besser als kleine Fallzahl und Verblindung besser als nicht verblindete Studien (33). Allerdings sind bei Evaluierungsstudien einige spezielle Aspekte zu berücksichtigen (9). Insgesamt fünf Studientypen lassen sich unterscheiden:
Randomisierte Studie
Prospektive Studie mit gleichzeitiger Kontrolle (nicht randomisiert)
Prospektive Studie mit historischer Kontrolle
Studie ohne Kontrollgruppe
Spezielle Studiendesigns
Zur Vereinfachung werden im folgenden nur Zwei-Gruppendesigns (Test- versus Kontrollgruppe) betrachtet.
4.3.1 Randomisierte Studie
Bei der Evaluierung von wissensbasierten Systemen können Patienten, Ärzte aber auch Abteilungen oder Funktionsbereiche Gegenstand der Randomisierung sein. Das klassische Vorgehen besteht in der Randomisierung von Patienten. Ein wesentliches Problem bei diesem Design ist der Carry-over-Effekt, der durch den Umgang mit dem wissensbasierten System entsteht und die Ergebnisse bei den Kontrollpatienten (kein wissensbasiertes System) beeinflußt. Einfache Randomisierung wurde bisher nur bei einigen Evaluierungsstudien durchgeführt und kann nur eingeschränkt empfohlen werden (32). Randomisiert man die Ärzte, so kann es vorkommen, daß sie die Randomisierung überhaupt nicht akzeptieren. Dennoch wurde dieses Design in einigen Studien erfolgreich durchgeführt und kann, wenn realisierbar, emphohlen werden (30). Eine Randomisierung von Kliniken scheidet wegen der Fallzahlproblematik in der Regel aus.
Ein wesentliches Problem bei randomisierten klinischen Studien zum Impakt stellt die Compliance dar. Mehr oder weniger häufig kommt das wissensbasierte System in der Testgruppe nicht zur Anwendung. Drei verschiedene Arten von Analyse sind dann möglich: "intention-to-treat", gemäß Protokoll, "as-treated" (Sheiner et al, Clin Pharm Ther, 95). Bei der "intention-to-treat"-Analyse werden die Gruppen wie sie ursprünglich randomisiert wurden miteinander verglichen. Die Analyse gemäß Protokoll bezieht nur solche Patienten in die Analyse ein, die tatsächlich korrekt nach Protokoll behandelt wurden. Bei der "as-treated-Analyse" werden die Patienten gemäß dem tatsächlichen Vorgehen gruppiert, d.h. z.B. Patienten, die der Testgruppe (wissensbasiertes System) zurandomisiert wurden, bei denen aber das System nicht zur Anwendung kam, werden der Kontrollgruppe zugeschlagen. Bei der "intention-to-treat"-Analyse besteht die Gefahr, daß durch eine schlechte Compliance in der Testgruppe Unterschiede nicht entdeckt oder unterschätzt werden. Umgekehrtes kann für die Analyse gemäß Protokoll gelten, wenn das wissensbasierte System nur bei solchen Patienten angewendet wird, wo es besonders vielversprechend ist. Fehlerhafte Ergebnisse erhält man ebenfalls bei der Analyse "as-treated". Je nachdem ob Patienten, bei denen das wissensbasierte System nicht zur Anwendung kommt, eine schechtere oder bessere Prognose besitzen, werden die Unterschiede unter- oder überschätzt. Um bei erheblicher Compliance die Effekte einer tatsächlichen Anwendung von wissensbasierten Systemen abschätzen zu können (sog. "method-effectiveness"), gibt es unterschiedliche modellbasierte methodische Ansätze.
Eine Randomisierung kann im Rahmen der folgenden Studiendesigns zur Anwendung kommen:
2-Gruppendesign mit Nachhermessung und Randomisierung
2-Gruppendesign mit Vorher/Nachhermessung und Randomisierung
Cross-over Design mit Randomisierung
4.3.1.1 Zwei-Gruppendesign mit Nachhermessung und Randomisierung
Bei diesem Design werden durch Randomisierung zwei Gruppen gebildet: eine Testgruppe, in der das wissensbasierte System zur Anwendung kommt, und eine Kontrollgruppe ohne Intervention oder mit einer Standardintervention (Beispiel 37).
4.3.1.2 Zwei-Gruppendesign mit Vorher-/Nachhermessung und Randomisierung
Dieses Design stellt eine Kombination eines historischen Vergleichs mit einer randomisierten Studie dar. Durch Randomisierung werden zwei Gruppen gebildet, eine Testgruppe und eine Kontrollgruppe. In der Testgruppe werden die Ergebnisse vor und nach Einführung des wissensbasierten Systems gemessen. In der Kontrollgruppe erfolgt dies analog im Hinblick auf eine Kontrollintervention (ggf. keine zusätzliche Intervention).
4.3.1.3. Cross-over Design mit Randomisierung
Bei diesem Design werden zwei Gruppen gebildet. In der einen Gruppe wird mit der Testung des wissensbasierten Systems begonnen, an die sich eine Kontrollphase ohne Einsatz des Systems anschließt. In der anderen Gruppe erfolgt dies umgekehrt.
4.3.2. Studie mit gleichzeitiger Kontrolle (nicht randomisiert)
Bei diesem Studiendesign werden eine Kontroll- und eine Testgruppe gleichzeitig untersucht. Im Gegensatz zur randomisierten Studie erfolgt die Zuteilung von Patienten, Ärzten oder Organisationseinheiten nicht randomisiert zu den verschiedenen Gruppen. Beispielsweise könnten computerinteressierte Ärzte der Intervention "computerunterstützte Diagnose" und die übrigen dem Computer negativ gegenüber eingestellten Ärzte der Kontrollgruppe zugeordnet werden. Eine nicht randomisierte Zuteilung führt in der Regel zu Fehlerbildungen, die einen Vergleich der Gruppen erschweren oder unmöglich machen. Ähnlich wie bei den randomisierten Studien sind folgende Designs denkbar:
2-Gruppendesign mit Nachhermessung ohne Randomisierung
2-Gruppendesign mit Vorher-/Nachhermessung ohne Randomisierung
Cross-over Design ohne Randomisierung
4.3.2.1 Zwei-Gruppendesign mit Nachhermessung ohne Randomisierung
Bei diesem Design werden durch nicht randomisierte Zuteilung zwei Gruppen gebildet: eine Testgruppe, in der das wissensbasierte System zur Anwendung kommt, und eine Kontrollgruppe ohne Intervention oder mit einer Standardintervention.
4.3.2.2 Zwei-Gruppendesign mit Vorher/Nachhermessung ohne Randomisierung
Dieses Design stellt eine Kombination eines historischen Vergleiches mit einer Studie mit gleichzeitiger Kontrolle dar. Durch nicht randomisierte Zuteilung werden zwei Gruppen gebildet, eine Testgruppe und eine Kontrollgruppe. In der Testgruppe werden die Ergebnisse vor und nach Einführung des wissensbasierten Systems gemessen. In der Kontrollgruppe erfolgt dies analog im Hinblick auf eine Kontrollintervention (ggf. keine zusätzliche Intervention).
4.3.2.3 Cross-over Design ohne Randomisierung
Bei diesem Design werden zwei Gruppen gebildet. In der einen Gruppe wird mit der Testung des wissensbasierten Systems begonnen, an die sich eine Kontrollphase ohne Einsatz des Systems anschließt. In der anderen Gruppe erfolgt dies umgekehrt. Die Zuteilung zu den Gruppen erfolgt nicht randomisiert.
4.3.3 Prospektive Studien mit historischer Kontrolle
Unter diesem Studientyp werden ausschließlich prospektive Studien, d.h. in die Zukunft geplante und durchgeführte Studien verstanden. Prospektive Untersuchungen von Interventionen, die mit retrospektiv erhobenen Daten aus Krankengeschichten verglichen werden, fallen nicht unter diesen Studientyp. Da bei diesem Design Test- und Kontrollgruppen zeitlich aufeinanderfolgend untersucht werden, handelt es sich um einen historischen Vergleich. Dieser Studientyp unterliegt dem Einfluß sekularer Trends. Es ist durchaus denkbar, daß die Gruppen nicht mehr vergleichbar sind, entweder durch Strukturungleichheiten im Patientengut oder durch Änderungen im Management.
4.3.3.1 Ein-Gruppendesign mit Vorher-/Nachhermessung
Bei diesem Design gibt es nur eine Gruppe. In dieser Gruppe werden die Ergebnisse vor und nach Einführung des wissensbasierten Systems untersucht.
4.3.3.2 Zeitreihendesign
Bei diesem Studiendesign gibt es nur eine Gruppe. Im einfachsten Fall wird der klinische Nutzen vor, während und nach dem Einsatz eines wissensbasierten Systems untersucht. Durch die Verwendung einer Postphase kann festgestellt werden, ob durch die Benutzung des wissensbasierten Systems ein Carry-over-Effekt entsteht.
4.3.3.3 Switch-on/switch-off-Design
Bei diesem Studiendesign wird in einer Gruppe mehrfach das wissensbasierte System eingeführt und entfernt. Damit ist eine Analyse des Carry-over-Effektes möglich.
4.3.4 Studie ohne Vergleichsgruppe
4.3.5 Sonstige Designs
4.3.6 Unkontrollierte Studie
Unkontrollierte Studien erlauben keinen Vergleich der Ergebnisse bei Einsatz eines wissensbasierten Systems mit einer Kontrollgruppe. Allenfalls ist eine Orientierung an Literaturergebnissen möglich. Dieser Studientyp sollte daher nicht zur Evaluierung des klinischen Nutzens herangezogen werden.
5. Informationsquellen
(Literatur)
1. Wyatt J (1991)
Computer-based knowledge systems
Lancet 338: 1431-1436
2. Publikation MEDWIS-Program
3. Jorgensen T (1995)
Measuring effects
In: van Gennip EMSJ, Talmon JS (Eds)
Assessment and evaluation of information technologies
IOS Press, 99-109
4. Ohmann C, de Dombal FT, Winding O, and the International
Evaluation Panel (1994)
Evaluation procedure in the TELEGASTRO project
Theor Surg 9: 90-103
5. Preece AD (1990)
Towards a methodology for evaluating experts system
Expert Systems 7: 215-223
6. Engelbrecht R, Rector A, Moser W (1995)
Verification and validation
In: van Gennip EMSJ, Talmon JS (Eds)
Assessment and evaluation of information technologies
IOS Press, 51-66
7. Clark K, O'Moore R et al. (1991)
A methodology for evaluation of knowledge-based systems"
In: Adlassnig KP, Grabner G, Bengston S, Hansen R (Eds)
Lecture Notes in Medical Informatics 45: 361-370
8. Nykänen P, Chowdhury S, Wigertz O (1991)
Evaluation of decision support systems in medicine
Comput Methods Progr Biomed 34: 229-238
9. Wyatt J, Spiegelhalter D (1990)
Evaluating medical expert systems: what to test and how?
Med Inform 15: 205-217
10. ANSI/IEEE Standard 729-1983 (1983)
IEEE Standard Glossary of Engineering Terminology
New York: IEEE
11. O'Leary DE (1993)
Verifiying and validating expert systems: a survey.
Expert systems in buiseness and finance: issues and applications.
Chapter 12: 181-208
12. Boehm B, Brown JR, Kaspar H, Lipow M, MacLeod GJ, Merrit MJ
(1978)
Characteristics of software quality
North Holland, Amsterdam
13. Suen CY, Grogono PD, Shinhai R, Coallier R (1990)
Verifying, validating and measuring the performance of expert
systems
Expert Systems Applic 1: 93:102
14. Hermanek P, Sobin LH (Ed.) (1987)
TNM. Classifikation of malignant fumours
Springer Verlag, Berlin
15. Talmon J, Smeets R (1995)
Case acquisition for knowledge-based decision support system validation
In: van Gennip EMSJ, Talmon JS (Eds)
Assessment and evaluation of information technologies
IOS Press, 67-74
16. Jorgensen T (1995)
Methods for data acquisition
In: van Gennip EMSJ, Talmon JS (Eds)
Assessment and evaluation of information technologies
IOS Press, 111-116
17. Weiss SM, Kulikowski CA (1991)
Computer systems that learn.
Morgan Kaufman, Publishers, San Francisco
18. Lauter B (1987)
Software-Ergonomie in der Praxis
Oldenburg, München
19. Microsoft Programming Series (1992)
The windows interface. An application design guide
Microsoft Press, Redmond
20. Watts R (1987)
Measuring software quality.
NCC, Manchester
21. Timmers T, Blum BI (eds) (1991)
Software engineering in medical informatics
North-Holland, Amsterdam
22. Coad P, Yourdon E (1991)
Object-oriented design
Yourdan Press, Prentice Hall
23. O'Keefe RM (1989)
The evaluation of decision-aiding systems guidelines and methods
Information Management 17: 217-226
24. Rohrmann B (1978)
Empirische Studien zur Entwicklung von Antwortskalen für
die
sozialwissenschaftliche Forschung
Z. Sozial Phsychol 9: 222-245
25. Donabedian A (1966)
Evaluating the quality of medical care
Millbank Memorial Quarterly 44: 166-206
26. Loop JW, Lusted LB (1978)
American college of radiology diagnostic efficacy studies
AJR 131: 173-179
27. Nohr C (1995)
From assessment to decision making.
In: van Gennip EMSJ, Talmon JS (Eds)
Assessment and evaluation of information technologies
IOS Press, 117-126
28. Ohmann C, Otterbeck R, Franke C, Röher HD (1994)
Evaluation of knowledge-based systems.
Workshop in cooperation and supported by the German MEDWIS programme,
11 March 1994 in Düsseldorf, Germany
Theor. Surg 9: 230-237
29. Gunn AA (1991)
The acute Abdomen: the role of computer-assisted diagnosis
Baillière's Clin Gastroenterol 5: 639-665
30. Wellwood J, Johannessen S, Spiegelhalter DJ (1992)
How does computer-aided diagnosis improve the management
of acute abdominal pain?
Ann Roy Coll Surg Engl 74: 40-46
31. Adams ID, Chan M, Clifford PC, Cooke WM, Dallos V,
de Dombal FT, Edwards MH, Hancock DM, Hewett DJ, McIntyre N,
Somerville PG, Spiegelhalter DJ, Wellwood J, Wilson DH (1986)
Computer-aided diagnosis of acute abdominal pain: a multicentre
study
Br Med J 293: 800-804
32. Russel I, Grimshow (1992)
The effectiveness of referral guidelines:
a review of the methods and findings of published evaluations
In: Roland M, Coulter A (eds) Hospital referrals
Oxford University Press, Oxford, pp 179-211
33. Lorenz W, Ohmann C (1983)
Methodische Formen klinischer Studien in der Chirurgie:
Indikation und Bewertung
Chirurg 54: 189-195
34. van Gennip EMSJ (1995)
Approaches to experimental design
In: van Gennip EMSJ, Talmon JS (Eds)
Assessment and evaluation of information technologies
IOS Press, 75-85
35. Plögert K (1993)
Die SW-Entwicklung verlangt ein standardisiertes Vorgehen
Teil1: Aufbau, Inhalt und Verwendung des Vorgehensmodells
Computerwoche, Ausgabe 8 vom 19.2.95
Teil 2: Das Vorgehensmodell in der Praxis
Computerwoche, Ausgabe 9 vom 26.2.95
Anforderungsprofil (bei Softwareengineering)
Anforderungen, rechtliche (Datenschutz)
Auswertung (der Validierung)
automatic data logging (bei Logbuchstudien)
Bedienungsanleitung (Eigenschaften bzgl. Benutzerfreundlichkeit)
Benutzerfreundlichkeit1 (als Qualitätsmerkmal bei Evaluierung)
Benutzerfreundlichkeit2 (Bewertung durch Reaktionsstudien)
Benutzerfreundlichkeit3 (Erfassung durch Umfragen)
Checklist-Effekt (als Stör- u. Einflußgröße)
Carry-over-Effekt (als Stör- u. Einflußgröße)
Carry-over-Effekt1 (Problem d. randomisierten Studie)
Carry-over-Effekt2 (bei Switch-on/switch-off-Design)
Cross-over Design mit Randomisierung (als Studiendesign)
Cross-over Design ohne Randomisierung (als Studiendesign)
Datensammlung (Typen bei Testung d. Wissensbasis))
Diagnosesicherheit (Schlüssel)
Diagnosestellung (vgl. Prozeßqualität)
Effizienz (wissensbasierter Systeme)
Effizienz1 (Bewertung durch Reaktionsstudien)
Ein-Gruppendesign mit Vorher-/Nachhermessung (als Studiendesign)
Einfachheit (als Softwareeigenschaft)
Entscheidungshilfen (=Wissensbasen)
Enthusiasmus (als Stör- u. Einflußgröße)
Entwicklungs- und Produktdokumentation
Ergebnisse der Krankenversorgung
Evaluierung (Grundsätze)
Evaluierung1 (Phasen)
Evaluierung2 (Bewertung v. Qualitätsmerkmalen durch Nutzer)
Experten (als Erzeuger v. Testfällen bzgl. Validierung)
Experten1 (als Durchführer d. Validierung)
fallbasierte Systeme (Konsistenztestung)
Fallzahl (bei Testung d. Wissensbasis)
Fehlerbehandlung (Kriterium f. Zuverlässigkeit)
Fehlertoleranz (wissenbas. Systeme)
Feldstudie (Ort der Validierung)
Feldstudie0 (als Evaluierungsbestandteil)
Feldstudie1 (Evaluierung d. klin. Nutzens)
Feldstudie2 (zur Strukturqualität d. Krankenversorgung)
Flexibilität (wissensbasierter Systeme)
Fragebogenaktionen (bei Nutzerumfrage)
Fragen, ethische u. juristische
Goldstandard (= Referenzwert)
Gruppenprozesse (zur Reduktion d. Beobachtervariation)
Hawthorne-Effekt (als Stör- u. Einflußgröße)
Integrität (Systemsicherheit, Virenabwehr)
Interne Konsistenz (wissensbasierter Systeme)
Iterativer Prozeß (=Evaluierung)
IT-Sicherheitshandbuch (Datenschutz)
klinische Anwendung (= Ort d. Validierung)
klinische Anwendung1 (=Ort d. Evaluierung v. Funktionalität u. Benutzerfreundlichkeit)
klinischer Anwendungsbereich (Ort f. Beobachtungsstudien)
Konzept, informatisches (vgl. Testbarkeit wissensbas. Systeme)
Labor (Ort der Validierung)
Labor0 (Ort d. Evaluierung v. Funktionalität u. Benutzerfreundlichkeit)
Labor1 (Ort v. Beobachtungsstudien)
Laborstudie (als Evaluierungsbestandteil)
Lebensqualität (Maß f. Ergebnisqualität d. Krankenversorgung)
Lernfälle (bzgl. Durchführung d. Validierung)
Lernhilfen (=Wissensbasen)
Leserlichkeit (Merkmal f. Benutzerfreundlichkeit)
Modularität (Kriterium f. Testbarkeit v. Wissensbasen)
Modularität1 (als Softwareeigenschaft)
Morbidität (Maß f. Ergebnisqualität d. Krankenversorgung)
Mortalität (Maß f. Ergebnisqualität d. Krankenversorgung)
Normen (DIN)
Nutzerkommentare (bei Reaktionsstudien)
Nutzerumfrage (als Bestandteil von Evaluierung)
Phaseneinteilung (der Evaluierung)
programmunabhängige Wissenstestung
prospektive Studien mit historischer Kontrolle
Prozeßqualität1 (Merkmale d. Einschätzung)
Qualitätskriterien (u. deren Vergleich bzgl. Evaluierung)
Qualitätskriterien1 (für Feldstudien)
Qualitätsmerkmale (d. Software bzgl. Funktionalität/Benutzerfreundlichkeit)
Qualitätsmerkmale1 (von Evaluierungsstudien)
Quasi-Standards (statt objektive Standards)
randomisierte kontrollierte klinische Studie
Referenzwert1 (vgl. Goldstandard)
regelbasierte Systeme (Testung)
Regeln (Typen u. Umfang bei Testung d. Wissensbasis)
Regeln, fehlerhafte/inkonsistente
Reaktionszeit (wissensbas. Systeme)
Richtigkeit (als Standardmaß bei Validierung)
Risikomanagement (Datenschutzkonzept)
sekulare Trends (vgl. Stör- u. Einflußgrößen)
sekulare Trends1 (bei prospekt. Studien mit histor. Kontrolle)
Selbstbeschreibungsfähigkeit (Merkmal f. Benutzerfreundlichkeit)
semantische Überprüfung (bei regelbasierten Systemen)
semantische Überprüfung1 (bei fallbasierten Systemen)
Sensitivität (als Standardmaß bei Validierung)
Sicherheit (wissensbasierter Systeme)
Sicherheit0 (Bewertung durch Reaktionsstudien)
Spezifikationen (bzgl. Verifizierung bei Softwareentwicklung)
Spezifität (als Standardmaß bei Validierung)
Standards (i.d. Literatur bzgl. Evaluierung)
Statistische Methoden (vgl. Auswertung d. Validierung)
Statistische Fehler (als Stör- u. Einflußgröße)
Statistische Tests (zur Auswertung d. Validierung)
Strategie (der Evaluierung)
Struktur der Krankenversorgung
Strukturqualität der Krankenversorgung (Faktoren)
strukturelle Überprüfung (bei regelbasierten Systemen)
strukturelle Überprüfung1 (bei fallbasierten Systemen)
Studie mit gleichzeitiger Kontrolle (nicht randomisiert)
style guidelines (f. Bildschirmmasken/Dialoge)
Subsumierungen (bei Testung v. wissensbas. Systemen auf interne Konsistenz)
Switch-on/switch-off-Design (als Studiendesign)
syntaktische Überprüfung (bei regelbasierten Systemen)
syntaktische Überprüfung1 (bei fallbasierten Systemen)
Systemspezifikation (bei Softwareengineering)
Testbarkeit (wissensbasierter Systeme)
Testfälle (zur Testung d. Wissensbasis)
Testung, logische (als Evaluierungsbestandteil)
Therapiewahl (vgl. Prozeßqualität)
Übertragbarkeit (v. Ergebnissen in Labor/klin. Anwendung)
Validierung11 (Durchführung)
Verfügbarkeit (wissensbas. Systeme in klin. Routine)
Voreingenommenheit (als Stör- u. Einflußgröße)
Wartbarkeit (der Software)
Wert, prädiktiver (als Standardmaß bei Validierung)
Wissensbasis (Testung auf Korrektheit)
Wissensbasis1 (Testung mit Testfällen)
Zeitaufwand (der Nutzung wissensbas. Systeme)
Zielkriterium (bei Testung d. Wissensbasis)
Zirkularität (als Stör- u. Einflußgröße)
Zuverlässigkeit (wissensbasierter Systeme)
Zuverlässigkeit1 (vgl. Sicherheit u. Datenschutz)
Zuverlässigkeit2 (Bewertung durch Reaktionsstudien)
Zwei-Gruppendesign mit Nachhermessung und Randomisierung
Zwei-Gruppendesign mit Vorher-/Nachhermessung und Randomisierung
Zwei-Gruppendesign mit Nachhermessung ohne Randomisierung
Zwei-Gruppendesign mit Vorher/Nachhermessung ohne Randomisierung
Zyklen (bei Testung v. wissensbas. Systemen auf interne Konsistenz)
