Ich liebe es, hier in Stanford zu sein und die inspirierende Gesellschaft des universitären Umfelds genießen zu dürfen.

Umso konsternierter bin ich, wenn ich beim Joggen auf solche “Meinungsbekundungen” stoße.

Liegt es nur daran, dass ich Deutscher bin, wenn mir hier die Worte fehlen?

Was wird ein Arzt von einem Pharmakonzern erwarten, dessen Medikamente er verschreibt? Natürlich, dass dieses Medikament zugelassen und in klinischen Studien ausreichend auf Wirksamkeit und ein gutes Nutzen-Risiko-Verhältnis validiert wurde.

Was wird ein Arzt von einem Medizintechnikhersteller erwarten, dessen Produkt er anwendet? Natürlich, dass dieses Produkt zugelassen und in klinischen Studien ausreichend auf Wirksamkeit und ein gutes Nutzen-Risiko-Verhältnis validiert wurde.

Was wird ein Arzt von einem Softwarehersteller erwarten, dessen Produkt er dem Patienten verschreibt? Offensichtlich nichts, denn britische Ärzte verschreiben neuerdings Apps – natürlich welche ohne “Zulassung”.

Jede Brille, jeder Rollstuhl muss den Anforderungen der Medizinprodukterichtlinie genügen. Ärzte dürfen und müssen davon ausgehen, dass diese grundlegenden Anforderungen erfüllt sind. Aber für Apps scheint das nicht zu gelten?

Sind diese so harmlos = nutzlos, dass Sie keinen Schaden anrichten? Oder sind sie nur nützlich, ohne Nebenwirkungen zu haben? Solche Produkte kannte ich bisher kaum. Spielt ja keine Rolle, denn ohne Konformitätsbewertung muss man sich ja keine Gedanken darüber machen.

Danke an Stefan Popp für den Lesetipp

Die Bäume blühen, die Sonne scheint, es ist Frühling – in Kalifornien.

Hoffentlich bald auch wieder in Deutschland.

So einfach die Frage erscheint, so komplex mag die Antwort schlussendlich lauten. Doch wagen wir uns ran an die Beantwortung:

Eine GUI ist dann beschrieben, wenn Sie mit dieser Beschreibung einen Software-Entwickler beauftragen können, diese GUI umzusetzen, ohne dass dieser weitere Fragen stellen muss.

Sie sollten eine GUI pixelgenau einschließlich aller Größen Positionen, Schriftarten, Farben usw. spezifizieren. Dabei werden Sie auf viele Redundanzen stoßen, weshalb ich empfehle, diese allgemeinen Aspekte in einen Style Guide auszulagern.

Zu einer GUI Spezifikation gehört aber auch eine Beschreibung, wie sich diese auf Aktionen der Nutzer verhält. Die Teilnehmer des Seminars “Usability, Requirements & IEC 62366″ wissen, dass Nutzer nur drei Dinge tun können:

1. Etwas eingeben (z.B. Text oder grafisch)
2. Etwas auswählen (z.B. den Click auf einen Button)
3. Eine kognitive Leistung erbringen wie erkennen, verstehen oder unterscheiden.

Beschreiben Sie also auch, was die Nutzer eingeben oder auswählen können und wie sich das System dann verhält. Beispielsweise

• auf welche Bildschirmseite die Benutzeraktion führt. Die Ãœbersicht all dieser Möglichkeiten nennen manche den “Screen-Flow”
• wie sich das System im Fehlerfall verhält. Das hilft Ihnen, die Softwarespezifikation nochmals auf Vollständigkeit zu prüfen.

Wenn es Ihnen zu viel Arbeit ist, die Style Guides zu formulieren, oder wenn Sie unsicher sind, ob Sie an alles gedacht haben, dann nutzen Sie die Normenfamilie ISO 9241 als entscheidende Hilfestellung. Oder kommen Sie zum sensationellen Seminar “Usability, Requirements & IEC 62366″ mit Thomas Geis. Das nächste ist schon fast wieder ausgebucht. Zögern Sie nicht zu lange.

So, ich bin dann mal weg.

Einmal pro Halbjahr (mindestens) plagt mich das Fernweh. Jetzt ist es wieder soweit. Also ab in meine zweite Heimat Stanford. Mal sehen, was ich für den nächsten MBA-Studiengang einfädeln kann und welche Kooperationen sich triggern lassen.

Foto: Volkmar Otto

Natürlich bin ich auch in den nächsten 10 Tagen unverändert für Sie da. Ich antworte wie immer schnell und gerne. Nur die Telefonate müssten wir auf den Nachmittag verschieben.

Jedes Frühjahr darf ich meine Masterstudenten bei den Projekt- bzw. Masterarbeiten unterstützen. Ich möchte Ihnen verraten, wie es die Teilnehmer meiner Studiengänge schaffen, ihr Ziel zu erreichen. Dieser Tipp könnte auch für Sie hilfreich sein:

Die Abwärtsspirale…

Wenn man sich ein (zu) großes Ziel gesetzt hat, ist man anfangs von der Aussicht, es zu erreichen, vielleicht euphorisiert. Doch dann droht der Alltag: Tag für Tag vergeht, ohne dass man sich aufrafft, mit der Arbeit zu beginnen. Das schlechte Gewissen steigt, gleichzeitig scheint das Ziel immer weiter in die Ferne zu rücken.

Forscher haben inzwischen messen können, dass man sogar hormonell in eine richtige Abwärtsspirale gerät. Der Frust über das scheinbare eigene Versagen wirkt zunehmend lähmend. Man fühlt sich schlecht und im schlimmsten Fall sogar als Versager.

… und wie man sie vermeiden kann

Natürlich darf es niemals soweit kommen. Doch wie kommt man aus diesem Abwärtssog wieder hinaus?

Die Antwort mag trivial klingen:

Durch einen kleinen Erfolg kommt man zurück auf die richtige Spur. Nehmen Sie sich also jeden Tag eine ganz kleine Aufgabe vor, die Sie Richtung Ziel führt. Nur fünf Minuten. Das ist wichtig, nur fünf Minuten. Die Hürde muss wirklich sehr, sehr niedrig und einfach zu nehmen sein.

Sie glauben gar nicht, wie gut es sich anfühlt, diese fünf Minuten dann wirklich gearbeitet zu haben. Meist führt das dazu, dass man gleich weiter macht. Da spricht nichts dagegen. Aber beginnen Sie nicht, sich für den nächsten Tag wieder mehr (zu viel) vorzunehmen. Fünf Minuten, alles andere ist freiwillig.

Es mag sich absurd anhören: Fokussieren Sie nicht auf das finale Ziel (z.B. die Abschlussarbeit, die Kunden, die Sie anschreiben wollen, den Projektplan, den Sie zu erstellen haben usw.), sondern nur auf den jeweils nächsten Schritt. Nur auf den nächsten Schritt. Es ist jetzt wichtig, dass Sie wieder in Gang kommen. Vergessen Sie für eine Weile das große Ziel.

Und was könnte Ihre heutige Fünf-Minuten-Aufgabe sein? Wir wäre es damit, die Fünf-Minuten-Aufgaben für die nächsten drei Tage aufzuschreiben?

Schon das Wortungetüm “Softwaresystemanforderungsdokument” lässt einem schaudern, oder? Manche gruseln sich aber noch mehr bei der Vorstellung, so ein Dokument schreiben zu müssen. Was soll denn da rein?

Die kurze Antwort lautet: In dieses Dokument muss alles rein, was das Softwaresystem aus Blackbox-Sicht beschreibt. Und eine Blackbox verhält sich nach außen nur über ihre Schnittstellen. Derer gibt es bei Software primär zwei:

1. Die grafische Benutzerschnittstelle und
2. Die technischen Schnittstellen wie über Netzwerke, Bus-Systeme usw.

Bei dieser Beschreibung hilft Ihnen die ISO 25010 als wertvolle Checkliste:

In weiteren Blog-Beiträgen werde ich mit Ihnen einige Überlegungen dazu teilen, wie man die beiden Typen an Schnittstellen im Detail beschreibt.

Mehr über die Dokumentationslandschaft lernen Sie schnell und bequem im Institutsclub. Beantragen Sie doch eine kostenlose und unverbindliche Probemitgliedschaft. Diese dauert vier Wochen und verlängert sich auch nicht zu einer Vollmitgliedschaft. Ganz fair!

Und wieder bekomme ich eine spannende Frage in meiner Auditsprechstunde gestellt: Was ist die Lebensdauer von (medizinischer) Software?

Eine ausgezeichnete Frage! Es ist klar, dass Software im Gegensatz zu Hardware nicht altert. Zumindest nicht direkt, indirekt schon. Das weiß jeder, der versucht, sein altes Lieblingscomputerspiel auf einen neuen Rechner zu installieren. Die Umgebung der Software wie das Betriebssystem, Treiber, Hardware und andere notwendige Softwarepakete haben sich soweit verändert (weiterentwickelt), dass die ursprüngliche Software nicht mehr funktioniert.

Wer legt fest, wie lange die Lebensdauer medizinischen Software fest?

Wie lange die Lebensdauer ist, entscheiden Sie als Hersteller.

Wie legt man diese Lebensdauer fest?

Es ist möglich, dass Sie

• einen harten Endtermin setzen,
• eine Zeitspanne ab Kauf bestimmen,
• eng gesteckte Voraussetzungen an Hardware und Betriebssystem formulieren oder
• die Lebensdauer definieren als die Zeitspanne bis eine neue Version auf dem Markt ist.

Wann spricht man von einer “neuen Version”?

Erst einmal führt jede noch so kleine Änderung Bei zu einer neuen Version. Die Frage ist eher die: Wann muss ich ein Konformitätsbewertungsverfahren durchlaufen. Sie sollten zwei Fälle unterscheiden:

1. Sie machen eine marginale Änderung ohne Änderung des Funktionsumfangs (intended uses), beispielsweise bei einem Bugfix. Dann wäre das das gleiche Produkt, eine neue Konformitätsprüfung ist nicht notwendig.
2. Sie ändern den Funktionsumfang, dann ist eine neue Konformitätsbewertung notwendig. Sie können dann entscheiden, ob damit die Lebensdauer der alten Version abgelaufen ist oder Sie sogar parallel mehrere Versionen Ihres Produkts gleichzeitig im Markt haben.

Ob Sie diese Parallelität erlauben und wie Sie das Ende der Lebensdauer definieren, entscheiden Sie. Ebenso entscheiden Sie abhängig vom Risikomanagement, wie Sie das Lebensende der Produkte erzwingen:

Wie erzwinge ich das Lebensende meiner Software?

Auch hier stehen Ihnen mehrere Varianten offen. Z.B.:

• Durch eine Schutzmaßnahme: Beispielsweise prüft die Software selbständig ob es eine neue Version gibt und lädt die dann automatisch herunter oder startet gleich gar nicht mehr.
• Durch einen Hinweis: Sie lassen die Anwender wissen, dass es eine neue Version gibt und fordern ihn zum Update auf.

Zentrales Entscheidungskriterium für die Wahl des Lebensendes und der Wahl der Möglichkeiten, dieses zu erzwingen, ist das Risikomanagement. Wie so etwas genau funktioniert lernen Sie beispielsweise in unserem CPMS-Seminar.

wird sich der Mitarbeiter der Uniklinik Freiburg denken. Stimmt. Kleine Änderung, große Wirkung. Und die besteht darin, dass auf einmal streng vertrauliche Laborwerte wildfremder Menschen im Briefkasten von Thomas S., einem Patienten dieser Uniklinik, landen.

Wenn die privatärztliche Verrechnungsstelle nicht so ungeschickt auf die Beschwerde von Thomas S. reagiert und dieser daraufhin nicht den Landesdatenschutzbeauftragten eingeschaltet hätte, wäre der Fall wohl nie an die Öffentlichkeit, sprich in die Badische Zeitung gelangt (hier geht’s zum Artikel).

Der Programmierfehler stört mich nicht. Ich frage mich vielmehr:

• Wie kann es sein, dass eine einzelne Person (ohne Code Review) solche Änderungen machen darf?
• Von wie vielen dieser Fehler erfahren wir nicht?
• Welche dieser Fehler führen nicht nur zu einer Verletzung des Datenschutzes sondern zur Verletzung oder dem Tod von Patienten?

Zugegeben, die Systeme und ihre Vernetzung sind so komplex geworden, dass man sie kaum noch durchschauen und vollständig beherrschen kann. Aber ein paar “Best Practices” könnte man schon einhalten.

Ãœbrigens: Software-Entwickler können diese Best-Practices bei mir lernen. Beispielsweise im Rahmen der Ausbildung zum “Certified Professional for Medical Software”.

Danke SM für den Lesetipp

Kommt Ihnen so eine Kurve bekannt vor?

Mich erinnert sie in fataler Weise an die Anzahl der Fehler, die das BfArM zu Risiken mit medizinischer Software veröffentlicht. Und leider trifft dieser Eindruck zu. Die Kurve gibt nämlich die Anzahl der Zwischenfälle mit klinischen Informationssystemen an.

Die Studie, aus der das Bild stammt, listet auch die Gründe wie fehlerhafte Implementierung, unvollständige oder fehlerhafte Referenzdaten, Probleme beim Upgrade/Update und mangelnde Gebrauchstauglichkeit.

Lesen Sie diesen Artikel: Myers RB, Jones SL, Sittig DF. Review of reported clinical information system adverse events in US Food and Drug Administration databases. Appl Clin Inf 2011; 2: 63–74.

Falls Sie fürchten, dass Ihr System auch in Gefahr läuft, in solch einer Statistik zu erscheinen, dann geben Sie mir Bescheid. Mir gelingt es meist sehr schnell, die kritischsten Punkte zu finden und Lösungen anzubieten. Das ist natürlich kein Allerheilmittel, aber senkt die Wahrscheinlichkeit, auf dem Radar von BfArM und FDA zu erscheinen.