Voellmy Daniel

Abstract

After the complete rollout of an electronic patient record in a university hospital from 2007 to 2013, a critical review of some project issues was undertaken. One issue is the complexity resulting from a highly configurable and scriptable product. Complexity can be kept within reasonable limits by concepts that emphasise enterprise wide standards, and an effectual ICT governance. The rollout strategy had three functional blocks throughout all clinics in three rounds. The rollout strategy proved to be not ideal, but this was inevitable due to the evolving software development process. Requirements engineering turned out to be the key issue. Effective and consistent functionality should be ensured by a formal specification process combined with early and frequent software reviews including the clinical stakeholders. To minimise quality issues, software testing has to be formalised and intensified.

Zusammenfassung

Nach Abschluss der Einführung eines Klinikinformationssystems (KIS) an einem Universitätsspital wird eine kritische Bilanz zum gewählten Vorgehen gezogen. Um die Komplexität hoch parametrierbarer Produkte in Grenzen zu halten, sind unternehmensweite Fachkonzepte und eine stringente «ICT-Governance» notwendig. Die gewählte horizontale Einführungsart war nicht optimal, aber unter den gegebenen Umständen ohne Alternative. Als grösste Herausforderung wird die Erhebung von Anforderungen identifiziert: Mit einem formellen Requirements-Engineering und engmaschigen Software-Reviews muss die Nachhaltigkeit der hergestellten Funktionen sichergestellt werden. Den Software-Tests müssen mehr Zeit und Bedeutung zugemessen werden.

Einleitung

Kürzlich fand die Projektabschlussfeier für das Klinikinformationssystem des Inselspitals Bern statt. Es ist die Zeit der Projektbilanzen. Rückblick: Das Inselspital schrieb 2007 die Beschaffung des KIS aus, nachdem ein Investitionskredit von knapp 5,8 Mio. CHF bewilligt worden war. Aus einer breit abgestützten Evaluation ging ein hoch parametriertes Schweizer KIS-Produkt hervor. Die Spitalleitung forderte eine möglichst einheitliche Lösung für alle 223 klinischen Organisationseinheiten des Inselspitals. Speziallösungen für einzelne der gut 4000 Anwendenden sollten wenn möglich vermieden werden.

Die Projektbilanz zeigt, dass das KIS im vollen Funktionsumfang eingeführt wurde. Insgesamt dauerte die Einführung jedoch länger als geplant und im Gegensatz zu den überwiegend elektronisch dokumentierenden Bettenstationen tun sich einzelne Ambulatorien mit dem KIS nach wie vor schwer. Die Benutzerzufriedenheit erreicht gute, aber nicht hervorragende Werte. Die im Folgenden beschriebenen angetroffenen Herausforderungen und die angewandten (Gegen-)Strategien zeigen auf, welche allgemein gültigen Erkenntnisse sich aus allfällig begangenen Fehlern ableiten lassen.

Hoch parametrierbare Systeme als Komplexitätstreiber

Um die Wünsche unterschiedlicher Kunden möglichst exakt zu erfüllen, sind die meisten KIS-Produkte als Baukastensystem ausgestaltet. Hochparametrierbare Systeme erlauben kundenspezifische Massanfertigungen und Änderungen bis zu Erweiterungen der Datenstrukturen. Die ausgesprochene Parametrierfähigkeit des am Inselspital eingesetzten Produkts war nach ausführlicher Evaluation ausschlaggebend für den Zuschlag bei der Ausschreibung.

Wie sich im Projektverlauf zeigte, ist Hochparametrierung ein Komplexitätstreiber. Die Systemtheorie besagt, dass die Kompliziertheit eines Systems quadratisch mit dessen Anzahl Untersysteme wächst, wenn die Untersysteme nicht gleichartig sind. Individualparametrierungen sind per se Neuentwicklungen mit einem Risiko für «Kinderkrankheiten», was Nachbesserungen erfordert. Nachbesserungen verschieben die Projekt-Folgevorgänge und erhöhen dadurch die Projektkomplexität. Werden mit Individualparametrierungen zudem funktionale Varianten bereitgestellt, ergibt sich eine kombinatorische Explosion der Variantenvielfalt. Darunter leidet wiederum die «Usability»: Unerfahrenen Benutzenden erscheint die Bedienung des KIS kompliziert.

Die Gegenstrategie heisst Standardisierung: keine Varianten bestehender Funktionen einführen, möglichst keine Spezialformulare erstellen, die Datenstrukturen des Grundprodukts nicht erweitern. Konsequent angewandt, hätten im vorliegenden Projekt Hunderte von Änderungsvorschlägen der Kliniken abgewiesen werden müssen, was den Prämissen des Projekts widersprochen hätte.

Stattdessen wurde ein Mittelweg zwischen «Wunschkonzert» und radikaler Standardisierung gesucht. Fachkonzepte und entsprechende Projektsteuerungsgremien reduzierten Spezialwünsche in akzeptablem Mass. Immer wieder wurde versucht, die Pareto-Regel (80/20) durchzusetzen. Ob die Gratwanderung gelang, lassen möglicherweise die Benutzerzufriedenheitsumfragen erahnen: Die Kompliziertheit des KIS und das Fehlen von Spezialfunktionen werden unter den Kritikpunkten etwa gleich häufig genannt. Dies deutet darauf hin, dass der Grat ungefähr getroffen wurde.

Einführung – horizontal, vertikal oder Big Bang?

Die Einführung des KIS fand in drei flächendeckenden horizontalen Runden statt: Nach der stationären Dokumentation ab Ende 2008 folgten 2010 die ambulante Dokumentation und anschliessend die Pflegedokumentation. Mit der dritten Stufe wurden der elektronische Verordnungsprozess sowie die Medikation eingeführt.

Dieses horizontale Vorgehen hat den Nachteil, dass jede Klinik die KIS-Funktionen in mehreren Stufen einführt und zwischen der ersten und letzten Stufe einen Mischbetrieb mit KIS und Vorgängersystem unterhält. Dies führt zu ineffizienten Abläufen, Doppelspurigkeiten, unnötiger Kompliziertheit und vermindert die Initial-Akzeptanz des KIS.

Hätte der vollständige KIS-Funktionsumfang vor der Einführung robust und erprobt bereitgestanden, wäre das vertikale Modell anwendbar gewesen – Einführung des gesamten Funktionsumfangs Klinik für Klinik. Zwischen der ersten und der zuletzt eingeführten Klinik wäre zwar eine lange Periode mit sehr unterschiedlicher Arbeitsweise entstanden, was aber durch die klinikinternen Effizienzgewinne wettgemacht worden wäre.

Beim vorliegenden Projekt stand jedoch die Funktionalität nicht von Anfang an bereit. Viele Funktionen mussten auf Einführungsrunden hin parametriert werden. Wäre die gesamte Funktionalität vor der Erstklinik finalisiert worden, um die vertikale Einführung zu ermöglichen, hätte sich der Einführungsbeginn weit nach hinten verschoben. Zudem ist eine Zweitklinik erst zur Einführung bereit, wenn sämtliche Wünsche der Erstklinik erfüllt sind und die Benutzer ihre vollständige Zufriedenheit mit dem System bestätigen. Das kann jeden Projektplan sprengen. Eine flächendeckende Einführung des gesamten Funktionsumfangs (Big Bang) stand wegen der stufenweisen Realisierung nicht zur Debatte.

Rückblickend war das horizontale Einführungsmodell mit Schwierigkeiten behaftet, aber dennoch besser als die Alternativen.

Anforderungen definieren: eine unmögliche Aufgabe?

Dem Schlüssel-Erfolgsfaktor für Projekte, dem adäquaten Einbezug der Betroffenen, wurde im vorliegenden Projekt bestmöglich Rechnung getragen: Vor der Systemevaluation diskutierten 280 Personen und mehrere Expertengruppen; ein Katalog von über 1400 Kriterien resultierte. In den Realisierungs- und Einführungsphasen beschäftigte sich ein umfangreicher Apparat von Gremien laufend mit den geäusserten Anforderungen. Die Projektteams führten Hunderte von Interviews mit Klinikvertreterinnen und -vertretern.

Trotzdem blieben zielgenaue Anforderungsspezifikationen die Ausnahme. Die nach bestem Wissen und Gewissen erhobenen Benutzeranforderungen erwiesen sich oft als nicht tragfähig. Anforderungs-Irrtümer traten während der Implementierungsspezifikation, der Realisierung, der Tests, der Schulung, der Einführung oder erst Monate nach der Einführung zu Tage. Die Korrekturen solcher Anforderungs-Irrtümer verursachten grossen Aufwand. Eine typische Ursache für Fehlspezifikationen war der Röhrenblick: Einzelne Benutzergruppen forderten, teilweise unter Androhung einer Einführungsverweigerung, lokale Anpassungen ohne Nutzen oder gar zum Schaden für andere Anwendenden. Unter Zeitdruck führt dies zu einem unüberlegten «Schnellschuss», der in gehäufter Form ein «Wunschkonzert»unter den Benutzenden entstehen lässt. Ein anderer Denkfehler passiert, wenn der aktuelle Anwendungsfall nach Einführung des Systems oder durch andere externe Faktoren verloren geht: Der neue Anwendungsfall zieht einen Anforderungs-Shift nach sich. Ein klassischer Irrtum ist das Spezifizieren und Realisieren von Funktionen, die wie «Papierformulare auf dem Bildschirm» aussehen. Solche Formulare werden später als Fremdkörper empfunden, wenn der zugrundeliegende papierbasierte Anwendungsfall durch das KIS abgelöst ist.

Die gelernte Lektion ist klar: Es darf kein Aufwand gescheut werden, die künftigen Anwendungsfälle gegenüber der Anwenderschaft plausibel zu machen. Die entsprechenden Konzepte sind durch Managementbeschlüsse abzusichern, die nötigenfalls auch gegen eine Klinikleitung durchgesetzt werden. Bei Neuentwicklungen sind die Zwischenstände mit einem «Prototyping» während der gesamten Realisierungszeit engmaschig den Anwendenden zu zeigen, um einen allfälligen Anforderungs-Shift früh zu erkennen. Dabei ist der Nachteil der erschwerten Terminprognosen von Beginn an klar zu kommunizieren.

Testen als Qualitätsindikator

Für das Testen von Software gibt es anerkannte Vorgehensstandards. Zentrale Pfeiler sind eine testorientierte Entwicklungsmethodik und ein Testkonzept. Im Idealfall stehen die Testroutinen mit Testdrehbuch schon vor der Programmierung fest. Laut gängiger Meinung sollten Tests etwa 40% der Entwicklungszeit beanspruchen.

Die Realität im vorliegenden Projekt war anders. Das stetige Anpassen von Testdrehbüchern an dynamische Spezifikationen beanspruchte zu viele Ressourcen. Folglich wurde nach dem «best effort»-Prinzip getestet: Viele Fehler konnten gefunden werden, allerdings nicht immer genug. Die teilweise fehlerhafte Parametrierung wurde zunächst in die Schulungsumgebung übertragen und belastete die Anwender-Schulungen. Blieb sie auch in den Schulungen unentdeckt, wurde sie erst im Produktivbetrieb über den 7×24-Support gemeldet. Die anschliessende Behebung solcher Produktiv-Fehler durch so genannte «Hotfixes» verursachte Stress und Zusatzaufwand auf Projekt- und Benutzerseite.

Beim Testen muss abgewogen werden: Sicher ist, dass das Testkonzept als Teil einer Qualitätsstrategie griffig formuliert werden muss. Brauchbare Testdrehbücher müssen als Teil der Softwaredokumentation jeweils vor Entwicklungsbeginn eingefordert und bei sich ändernder Anforderungslage angepasst werden. Ob eine Projektleitung auch dann eine absolute Fehlerfreiheit einfordern soll, wenn Einführungstermine durch zusätzliche Testrunden gefährdet sind, muss im Einzelfall entschieden werden.

Fazit

Dass das Projekt überhaupt zum Abschluss kam, ist nicht selbstverständlich: Laut Standish Group scheitern 31% der IT-Projekte weltweit (The Standish Group: CHAOS Summary 2012 report. http://www.standishgroup.com ). Davon ausgehend, dass die grössten anzunehmenden Fehler beim beschriebenen Projekt nicht eingetreten sind, konnten die oben beschriebenen Lerneffekte ausgemacht werden.

Die wichtigste Erkenntnis aber ist, dass es bei Informatik auf dieser Ebene nicht mehr um «0 und 1» geht, sondern um die Suche nach dem Grat zwischen den zum Scheitern führenden Extremen.

Correspondence

Korrespondenz:

Dr. med. Daniel R. Voellmy

Leiter Service Center Medizinische Applikationen

Informatik und Kommunikation

Inselspital, Universitätsspital Bern

Freiburgstrasse 10

3010 Bern


Daniel.Voellmy[at]insel.ch

Copyright

Published under the copyright license
“Attribution – Non-Commercial – NoDerivatives 4.0”.
No commercial reuse without permission.
See: emh.ch/en/emh/rights-and-licences/