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.

Wissen Sie, wie ich Produktmanager erlebe?

Das sind Menschen, die den ganzen Tag mit den Kunden reden, von denen 100e Meinungen einholen, die sich teilweise decken und teilweise widersprechen, und die diese “Meinungsvielfalt” an die Entwicklung rantragen, um dann gesagt zu bekommen, das ginge so einfach und in der gewünschten Zeit überhaupt nicht. Und wenn dann ein Kunde laut schreit, rennt der arme Produktmanager wieder zur Entwicklung, um dann zu hören, die Kunden schienen ja nicht zu wissen, was sie wollen.

Kommt Ihnen das bekannt vor?

Falls ja, wissen Sie, dass Ihre Firma zumindest noch Effizienzpotenziale hat. Die können Sie übrigens relativ elegant nutzen, wenn Sie (bzw. Ihr Produktmanagement) verstehen, was ein Produktmanager eigentlich tun sollte:

Ein Produktmanager ist eine Person, die Nutzungskontexte identifiziert und darin Nutzungsanforderungen ableitet.

Und dieses Ableiten verlangt ein methodisches Vorgehen. Dazu gibt es ein Verfahren, das Sie zu genau diesen Nutzungsanforderungen und von dort zu den Systemanforderungen führt.

Das eigentlich faszinierende ist nicht nur das fast mathematische Vorgehen (Sie brauchen keine Hokus-Pokus-Psychologie und Kreativtechniken), sondern dass Sie damit auf wirkliche Produktinnovationen stoßen. Wenn Sie dieses Verfahren beherrschen, haben Sie eine Lizenz zum Gelddrucken. Glauben Sie nicht? Ich erlebe es mit Thomas Geis immer und immer wieder.

Überzeugen Sie sich selbst und besuchen Sie unbedingt das Seminar “Usability, Requirements und IEC 62366″ von und mit Thomas Geis. Mein Tipp: Melden Sie sich gleich an, die Reihen füllen sich schnell und wir haben in der Villa dieses Mal nicht den ganz großen Raum bekommen.

“Ich bin doch dafür zu alt”, meint ein potenzieller Interessent für das Masterstudium IT im Gesundheitswesen. “Ich bin doch schon fast 50″.

Ja super, dann stehe ich ja auch kurz vorm geistigen Verfall, denke ich, verkneife mir aber die Bemerkung. Wäre auch unnötig: Unser Gehirn ist und bleibt bis in hohe Alter flexibel. Das hat übrigens eine Studie an Londoner Taxifahrern herausgefunden, deren Gehirn sich bereits während des Lernens auf die Taxisprüfung änderte. Zwar ziemlich einseitig, nämlich nur in den Regionen, die für die Orientierung zuständig sind. Gut, das mag nicht überraschen.

Quelle: Welt Kompakt vom 12.12.2011.

Unser bisher ältester “Student” war übrigens 62. Für ihn ist das Lernen nicht nur etwas, das Freude macht und die Neugier befriedigt, sondern das ihn geistig auch Jung hält. Recht hat er, denn genau das ist eine Empfehlung der Wissenschaftler.

Bleiben auch Sie geistig jung und beruflich erfolgreich. Mein Rezept ist ebenfalls das Lernen – beispielsweise im Rahmen eines Masterstudiums. Melden Sie sich doch bei mir, damit wir Ihr Brain-Wellness-Programm besprechen können.

“Horror-Trend gestoppt” hört sich gut an, oder? So nach BILD-Zeitung .

Dabei ist die Sache gar nicht so witzig. Vom ersten Quartal 2010 bis zum dritten Quartal 2011 waren die über das BfArM gemeldeten Risiken durch medizinische Software um 300%(!) gestiegen.

Im letzten Quartal sieht die Sache wieder etwas besser aus:

Ein Grund zu Entwarnung? Wenn man es gut findet, dass nur noch jeden zweiten Tag ein Fehler gemeldet wird, vielleicht schon. Aber gut ist anders.

Gleich zwei meiner Kunden haben mich gestern am Institut besucht. Beide kamen mit dem gleichen Anliegen, sie bei der Produktakte zu unterstützen. Beide hatten das gleiche Problem, nämlich “Anforderungen” auf das Pflichtenheft und das Lastenheft aufteilen zu müssen. Und beide machten den gleichen Fehler:

Sie beschreiben im Lastenheft die “Anforderungen” grob granular, im Pflichtenheft dann detaillierter. Und wenn es bei manchen “Anforderungen” keinen Unterschied zwischen den grob und fein granularen Beschreibungen gibt, steht in beiden Dokumenten dasselbe. Entsprechend obskur wird dann die Aufteilung der Tests, die man dann Verifizierung und Validierung nennt. Ähnlich obskur wird dann die Nachverfolgung (Traceability).

Wieso kommt es zu diesen Schwierigkeiten? Was machen diese Hersteller falsch? Wie sollte man es richtig machen?

Zu diesen Schwierigkeiten kommt es unter anderem deshalb, weil die Aufteilung relativ willkürlich ist. Richtig müsste man zwischen Nutzungs- und Systemanforderungen unterscheiden. Ein Beispiel:

Die Nutzungsanforderung könnte lauten: “Der Internist muss am System alle Patienten mit einem zu niedrigen Hämoglobinwert erkennen können”.

Die zugehörige Systemanforderung könnte dann heißen: “Das System zeigt in der Patientenübersicht alle Patienten mit einem zu niedrigen Hämoglobin in roter fetter Schrift der Größe 12 Punkt an.” Konkret würde man hier die GUI vollständig spezifizieren, einschließlich dem Screen Flow und deren Verhalten bei Benutzeraktionen – einschließlich Fehleingaben.

Dass die Erarbeitung der Systemanforderungen in mehreren Schritten von grob nach fein erfolgen kann, möchte ich nicht in Abrede stellen. Es bleiben aber Systemanforderungen. Und Systemanforderungen sind nur dann valide, wenn es dazugehörige Nutzungsanforderungen gibt.

Und um das Thema Testen anzusprechen:

Die Prüfung, ob die Nutzungsanforderungen erfüllt sind, heißt Validierung, die Prüfung, ob Systemanforderungen erfüllt sind, heißt Verifizierung.

Nun mögen Sie fragen, wie man zu Nutzungsanforderungen kommt und wie man aus Nutzungsanforderungen Systemanforderungen ableiten kann. Dazu habe ich nur einen wirklich guten Tipp:

Besuchen Sie unbedingt das Seminar “Usability, Requirements und IEC 62366″ von und mit Thomas Geis. Ich selbst werde wieder dabei sein. Denn von niemandem lernt man besser als von den Besten.

Melden Sie sich gleich an, die Reihen füllen sich schnell und wir haben in der Villa dieses Mal nicht den ganz großen Raum bekommen.

Ich bin stolz, auf das was ich erreicht habe. Hört sich unbescheiden an, aber so ist es :

Ich genieße das Privileg, mit einem Team aus ebenso kompetenten wie netten Menschen arbeiten zu dürfen. Ich freue mich, über die Vielzahl an Produkten und Dienstleistungen, mit denen wir unsere Kunden unterstützen. Und deren Rückmeldung (von wirklich allen Kunden), wie effizient, effektiv und unkompliziert wir geholfen haben, gibt mir die Kraft, immer weiter an uns und den Produkten und Dienstleistungen zu feilen.

Da alles so wächst und gedeiht, ist es nicht einfach, den Überblick zu wahren. Daher habe ich ein kurzes Video gedreht, in dem ich Ihnen zeige

• wer wird sind, was wir können und wie wir denken: Damit Sie einschätzen können, ob wir zu Ihnen passen.
• was wir Ihnen anbieten: Damit Sie wissen, auf welche Weise wir Ihnen helfen können.
• was wir Ihnen kostenlos geben: Damit Sie sofort beginnen können, noch schneller, noch fehlerfreiere medizinische Software zu entwickeln und problemlos durchs Audit zu kommen. Ganz im Sinne einer IEC 62304, ISO 13485 usw.Und genau das ist unsere Mission.

Schauen Sie sich das Video an.