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.

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.

“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.

Kennen Sie dieses Bild?

Es stammt aus der ISO 9001, der Schwesternorm “unserer” ISO 13485. Dann wissen Sie, dass die beiden Normen Prozessnormen sind, also explizit Prozesse fordern. Und Sie kennen auch diese Prozesse:

• Verantwortung der Leitung
• Management von Ressourcen
• Produktrealisierung und Dienstleistungserbringung
• und Messung, Analyse und Verbesserung.

Doch halt! Stimmt das? Natürlich nicht ganz, denn sonst gäbe es ja nur vier Prozesse. Dieses Bild beschreibt eher die Bereiche, die Ihre Prozesse abdecken müssen. Eine Zuordnung könnte für ein Softwarehaus exemplarisch (und nicht vollständig) wie folgt aussehen:

Danke BF für Anregung.

Ãœbrigens: Wenn Sie das Gefühl haben, dass Sie Ihre Prozesse, gleich aus welcher Prozessgruppe, Sie eher behindern als Ihnen helfen, dann sollten Sie mich kontaktieren. Ich kann oft innerhalb weniger Stunden, das “Fett”, das sich über Jahre in den QM-Handbüchern und SOPs angesammelt hat identifizieren und helfen, es zu entfernen. Damit Sie den Spaß und die Geschwindigkeit beim Entwickeln nicht verlieren. Melden Sie sich bei mir.

Heute habe ich ein QM-Handbuch zum reviewen (super deutsches Wort, oder?) bekommen. Es ist eins der Dokumente, die jedes Narkotikum absolut überflüssig machen. Das Ding gehört unters Betäubungsmittelgesetz!

Ist das nicht bei allen QM-Handbüchern so, werden Sie sich fragen? Nein!!! Die Dinger sind nur deshalb so schrecklich, weil nichts Substanzielles drinsteht.

Ein Beispiel gefällig? Bitte, wie Sie wünschen: Unter Qualitätsziele steht in diesem fantastischen Handbuch, man wolle eine hohe Kundenzufriedenheit erreichen. Ach ne. Mit solchen Zielen werden Sie das nie erreichen.

Glauben Sie mir, solch ein Text ist wertloses Gesülze. Wenn Sie rausfinden wollen, ob Ihre Qualitätsziele etwas taugen, dann machen Sie den Lackmus-Test:

Streichen Sie alles raus, was nicht für jede andere gleichartige Firma auch gilt. Und wenn dann nichts übrig bleibt, dann treten Sie das ganze Handbuch in die Tonne. Denn dann ist das komplette QM-System f***** up – nicht nur das Handbuch. QM-Systeme müssen Top-Down aufgebaut sein. Und wenn schon das Top wertlos ist, wird es auf den Schichten drunter nicht besser. Davon abgesehen, dass das Beispiel nicht einmal ein Qualitätsziel darstellt. Ich glaube, da muss ich gleich noch einen Beitrag dazu schreiben….

PS: Wenn Sie gedanklich Ihr QM-Handbuch gerade in die Tonne getreten haben, dann melden Sie sich sofort bei mir. Wir bauen das Ding innerhalb weniger Tage wieder sauber auf. Aber eine Warnung vorweg: Der Fisch stinkt vom Kopf: Der Chef muss bei diesem Umbau mindestens einen halben Tag dabei sein. Mit ihm möchte ich besprechen, was die wirklichen Ziele sind. Was die DNA seines Unternehmens ist. Sonst wird das nichts.

Das schreckt Sie nicht ab? Dann sollten Sie mich wirklich rufen.

Ein Missverständnis möchte ich gleich zu Beginn klären: SOUP, also Software of Unknown Pedegrine, ist gemäß Definition der IEC 62304 Software unbekannter Herkunft, keine Software, deren Source-Code man nicht hat.

Bei SOUPs ist die Entstehung der Software unbekannt – besser ausgedrückt, die Dokumentation fehlt, die diese Entstehung beschreibt. Damit ist jede Closed Source Software ohne Dokumentation eine SOUP. Es ist aber falsch zu schließen, dass Software, über deren Code man verfügt (z.B. die eigene Software), keine SOUP sei. Sic! Der eigene Code kann durchaus eine SOUP sein. Wenn er nämlich nicht dokumentiert ist.

Gibt es die Möglichkeit, eine SOUP nachträglich zu “heilen” und den Ritterschlag zur “normalen” Software zu erteilen? Sie vom Aschenputtel zur Prinzessin zu “promoten”?

Die theoretische Antwort lautet nein, die praktische Antwort lautet ja.

Es wäre ja weltfremd zu glauben, die Firmen würden ihre Software immer zu dem Zeitpunkt dokumentieren, wo es Sinn ergibt. Die traurige Wahrheit ist doch, dass man planlos (bitte verzeihen Sie diese negative Einschätzung) entwickelt und danach die Dokumentation nachzieht. Man baut also erst das Haus und zeichnet danach den Bauplan. Und genau das gleiche können Sie für jeden fremden/anderen Code auch machen. Zu diesem Pragmatismus sind inzwischen auch die Auditoren gekommen.

Es gibt Sie also die Wandlung von der hässlichen SOUP zur wunderschönen Software-Prinzessin.