Holen Sie sich das kostenlose Infopaket, das Ihnen hilft, Ihr Medizinsoftware-Audit sicher zu bestehen. Mit diesem Infopaket Den ganzen Beitrag lesen »

Am Stand des Instituts auf der conhIT haben einige gefragt, wer denn der nette junge Mann ist (auf dem Bild ganz rechts).

Markus Gerhart wird zum Jahresende neuer Mitarbeiter des Instituts und v.a. unseren Beratungsteam verstärken. Solange bilden wir ihn aus, unter anderem zum Certified Professional for Medical Software.

Das nächste Zertifizierungsseminar findet übrigens am 18. Juni 2012 in Konstanz statt. Melden Sie sich bald an!

Kennen Sie die beiden anderen? Der zweite von links ist der ehemalige und treue Mitarbeiter und Alumni des Instituts, Michael Musick, der inzwischen die IT des Klinikums Augsburg leitet, daneben unsere wunderbare ITIL-Dozentin, Dörte Jaskotka.

Wir testen ziemlich ausführlich, lässt mich der Entwicklungsleiter eines klinischen Informationssystems (ein Medizinprodukt) wissen. Dennoch war ihr Auditor nicht damit zufrieden, frage ich zurück und möchte weiter wissen: “Welche Verfahren nutzen Sie, um Testfälle zu spezifizieren?”.

Erst etwas später weiß ich das anschließende Schweigen des Entwicklungsleiters zu deuten: Weder spezifiziert man Testfälle, noch leitet man diese systematisch mit einem Verfahren her. Der Tester klickt sich einfach durch die Anwendung.

So etwas ist weder effektiv, Fehler werden also nur mit einer unzureichend hohen Wahrscheinlichkeit gefunden, noch effizient. Und im Audit kann man so sicher auch nicht glänzen. Genau deshalb hat man mich gerufen.

Doch wie geht es besser?

Wenn Sie die “fertige” Anwendung testen, führen Sie meist einen Blackbox-Test durch, also einen Test dessen Testfälle Sie herleiten, ohne das Innenleben des Produkts kennen zu müssen.

Man unterscheidet mehrere Blackbox-Testverfahren, beispielsweise

• Äquivalenzklassenbasiertes Testen
• Grenzwertbasiertes Testen
• Fehlerbasiertes Testen
• Zustandsbasiertes Testen
• Testen mit Entscheidungstabellen
• Usw.

Ich habe für Sie im Institutsclub sechs webbased Trainings zum Testen veröffentlicht, in denen ich all diese Verfahren erkläre. Sie können eine kostenlose und unverbindliche Probemitgliedschaft beantragen.

Die Studierenden meiner Masterkurse “IT im Gesundheitswesen” lernen das im Rahmen ihres Studiums. Dabei üben Sie das Spezifizieren von Testfällen u.a. am Beispiel der oben zu sehenden Bildschirmmaske oder am Beispiel ihrer eigenen Anwendungen.

Wissen Sie was mich wirklich geschockt hat? Als ein Intensivpfleger mit seinen neu erworbenen Kenntnissen nach 10 Minuten lebensbedrohliche Fehler in einem Anästhesieprogramm fand.

xDT: ADT, BDT, KVDT, LDT und weitere Familienmitglieder

Mai 2004: Haben Sie immer so ein Verkehrschaos auf Ihrem Firmenparkplatz, frage ich meinen Beratungskunden, den Entwicklungsleiter einer großen kassenärztlichen Vereinigung. Nein, nur zu Quartalsbeginn, wenn die Ärzte ihre Datenträger abgeben, lautet die kurze Antwort.

Ich kann es kaum glauben. Im 21. Jahrhundert werden Daten auf physikalischen Datenträgern persönlich abgegeben. Auf CDs und USB-Sticks, teilweise sogar noch auf Floppy-Disks. Auf diesen Datenträger finden sich die Abrechnungsdaten der niedergelassenen Ärzte.

Fast 60 Mrd. rechnet der niedergelassene Bereich jährlich ab. Und das Gros der Abrechnung erfolgt auf Basis des xDT-Formats – wenn auch nur noch selten auf Floppy Disks.

Ich habe einen Artikel im Krankenhaus-IT-Journal geschrieben, der den Aufbau dieses xDT-Formats erklärt. Wahrscheinlich finden Sie keine kompaktere und verständlichere Beschreibung – es sei denn Sie erleben einen Tag des berufsbegleitenden Masterstudiums “IT im Gesundheitswesen”. Dort unterrichtet auch Jens Naumann, dessen medatiXX-Gruppe etwa 23.000 Praxen mit Software ausstattet, die dort auch zur Abrechnung genutzt wird. Kommen Sie einfach mal zu einem Schnuppertag vorbei.

Man gewöhnt sich nie daran: Konstanz, der See, die wundervolle Sicht auf die Alpen begeistern mich auch nach über 25 Jahren noch genauso wie am ersten Tag.

Kein Wunder, dass sich die Studierenden der berufsbegleitenden Masterstudiengänge hier wie im Urlaub fühlen. Kommen Sie doch mal für einen Tag vorbei und erleben Sie diese Atmosphäre (Kontakt).

Dass man etwas dokumentieren muss, mag für viele Entwickler schon genug der Zumutung sein. Dass man auch noch zwischen Dokumenten und Aufzeichnungen unterscheiden soll, geht aber dann doch zu weit. Oder?

Foto: iStockphoto

Viele Entwickler dokumentieren nicht gerne. Das weiß ich zu gut, auch wenn das nicht dafür spricht, dass diese Entwickler besonders gute sind. Die Unterscheidung zwischen Dokumenten und Aufzeichnungen sollte aber zumindest bekannt sein:

• Dokumente werden weiter entwickelt und haben deshalb eine Versionsnummer. Man spricht auch oft von Vorgabedokumenten. Beispiele dafür sind das QM-Handbuch oder Verfahrensanweisungen.
• Aufzeichnungen hingegen werden nur einmalig erstellt und müssen daher nicht versioniert sein. Die Auffindbarkeit und Lesbarkeit müssen Sie natürlich gewährleisten. Manche nennen Aufzeichnungen auch Nachweisdokumente. Beispiele hierfür sind Testaufzeichnungen, Auditberichte und Gesprächsnotizen.

Die Unterscheidung hat also v.a. etwas mit der Notwendigkeit der Versionierung zu tun.

Wenn Sie mehr über QM-Systeme und eine effektive (z.B. auditkonforme) und effiziente (ohne Overhead) Dokumentation wissen möchten, empfehle ich Ihnen die Teilnahme an unseren Seminaren, beispielsweise am

• Kompaktseminar medizinische Software am 15.5.
• CPMS-Seminar mit anschließender Zertifizierungsprüfung zum “Certified Professional for Medical Software” am 18.6.

Interview im Krankenhaus-IT-Journal zum Institutstag

Was gehört zu den wichtigsten Aufgaben eines Krankenhaus-Managers? Und was zu denen eines Managers eines Medizintechnikunternehmens?

Ich bin davon überzeugt, dass zu den wichtigsten Aufgaben dieser Manager zählt, zum Unternehmen passende Mitarbeiter zu finden und zu halten.

Wahrscheinlich werden die meisten Führungskräfte diese Aussage unterschreiben, nur konsequent handeln werden sie nicht. Und das wird zunehmend fatale Konsequenzen haben. Zunehmend, weil sich der Markt immer mehr zu einem Arbeitnehmermarkt wandelt – zumindest für die hochqualifizierten Mitarbeiter.

Wie Unternehmen auf diesen Wandel reagieren können, ist Thema des diesjährigen Institutstags (www.institutstag.de).

Vorab finden Sie ein Interview mit mir, das vom Krankenhaus-IT-Journal veröffentlich wurde. Lesen Sie es hier online.

PS (Wichtig): Da das Krankenhaus-IT-Journal auf den Institutstag aufmerksam macht, empfehle ich Ihnen, sich sehr bald anzumelden, wenn Sie das noch nicht getan haben. Wir werden dieses Jahr noch früher ausverkauft sein.

Meine Kunden sind erfinderisch: Offensichtlich begeistert von der IEC 62304 kam einer auf die Idee, die Funktionen (UI-Elemente) eines Medizingeräts, direkt mit Sicherheitsklassen in Verbindung zu setzen. Damit könne er direkt alle sicherheitskritischen Software-Teile identifizieren, entsprechend verifizieren und das alles tracen. Eine gute Idee?

Leider nein:

Bei Funktionen, d.h. Elementen eine Benutzerschnittstelle, unterscheidet man Elemente zu Eingabe, zur Auswahl und zur Anzeige. Das sind beispielsweise Schalter, Knöpfe, Drop-Down-Menüs, Grafiken, Texte oder Eingabefelder.

Es mag noch möglich sein, ohne Kenntnis der Architektur ein Risiko zuzuordnen. Beispielsweise lässt sich auch ohne Kenntnis des Innenlebens eines Geräts abschätzen, wie hoch und wie wahrscheinlich ein Schaden sein wird, wenn Daten für einen falschen Patienten angezeigt oder der Regler einer Infusionspumpe den Fluss einer Infusionslösung falsch entgegen nimmt.

Was man ohne Kenntnis der Architektur aber nicht abschätzen kann, ist der Beitrag, den die Software dazu liefert. Und mit Architektur meine ich Soft- und Hardwarearchitektur. Möglicherweise ist die Software gar nicht beteiligt oder ein Fehler in ihr würde durch eine Hardwarekontrollmaßnahme erkannt und beherrscht werden. Dann hätten wir ein hohes Risiko, aber Software der Klasse A.

In anderen Worten: Die Funktionen, also alle Arten von Elementen einer Benutzerschnittstelle, gleich ob diese in Hard- oder Software realisiert sind, lassen u.U. eine Korrelation mit dem Risiko, nicht aber mit einer Softwaresicherheitsklasse zu.

Mehr zur IEC 62304 und zur Risikoanalyse finden Sie im Institutsclub, für den es eine kostenlose, unverbindliche Probemitgliedschaft gibt.

Manchmal nerven mich meine Auditoren, auch wenn Sie formal Recht haben:

Ja ich weiß, die ISO 13485 erwartet eine Validierung der Messwerkzeuge. Und dazu zählen Unit-Test-Werkzeuge wie JUnit oder NUnit zweifelsfrei. Aber mal ehrlich: wie wahrscheinlich ist es, in JUnit bei einer Validierung einen Fehler zu finden? Und wie wahrscheinlich ist es, im eigenen Code, einen Fehler zu finden? Also: Auf was sollten wir die Prioritäten legen? Die Antwort ist klar, aber es hilft nichts, der Auditor besteht.

Zum Glück lässt sich so eine Validierung schnell lösen:

1. Kurze Testspezifikation schreiben: Diese enthält
   • Eine Beschreibung der Testumgebung, in meinem Fall Eclipse Indigo sowie die Version von JUnit
   • Eine Beschreibung des Testfalls: Ich wähle im Zorn möchte ich nur die assertEquals, die assertNotNull und die fail-Methode testen. Das schreibe ich in der Spezifikation und verweise auf die konkrete Java-Klasse als Testobjekt und den JUnit-Testfall. Die zu testende Klasse ist so geschrieben, dass jede JUnit-Method einmal true und einmal false zurückliefern muss.
   • Eine Beschreibung, wie die Ergebnisse dokumentiert werden. Ich entscheide mich für JUnitReport als Werkzeug.
2. Test durchführen, Testergebnisse bewerten (große Ãœberraschung: JUnit enthält keinen Fehler) und Testergebnisse dokumentieren (JUnitReport mit meiner Bewertung “erfolgreich”)
3. Testumgebung, Testspezifikation und Testergebnisse zippen und das ganze unter Versionsverwaltung stellen.

Fertig ist die Validierung. In diesem Fall war’s nervig. Bei einem anderen (kommerziellen) Werkzeug hingegen wertvoll: Ich hatte es falsch parametriert. Mein Auditor hat doch ein wenig Recht.

Benötigen Sie Hilfe beim Validieren Ihre Softwarewerkzeuge oder Ihrer Software selbst? Melden Sie sich, ich habe Freude daran, Sie zu unterstützen.

Zu meinem ersten Blog-Beitrag zur Frage, welche Sprachen in Gebrauchsanweisungen erlaubt sind, möchte ich noch einige Ergänzungen liefern.

In Deutschland ist die Sache ziemlich genau geregelt:

“(2) Medizinprodukte dürfen nur an den Anwender abgegeben werden, wenn die für ihn bestimmten Informationen in deutscher Sprache abgefasst sind. In begründeten Fällen kann eine andere für den Anwender des Medizinproduktes leicht verständliche Sprache vorgesehen oder die Unterrichtung des Anwenders durch andere Maßnahmen gewährleistet werden. Dabei müssen jedoch die sicherheitsbezogenen Informationen in deutscher Sprache oder in der Sprache des Anwenders vorliegen.” (MPG §11 Abschnitt 2)

Auch für die anderen Länder gibt es eine wunderbare Aufstellung der Notified Bodies, welches Land welche Sprache(n) verlangt/erlaubt. Diese Aufstellung können Sie sich von deren Seite direkt herunterladen (als Word-Datei!).

Wohlgemerkt, mit diesem Beitrag diskutieren wir nur die Sprache, nicht den Inhalt solcher Gebrauchsanweisungen.

Wie Sie diese IEC 62366 konform erstellen, können Sie in meinem Seminar zur medizinischen Software am 15.5. erfahren.

Danke an meinen Partner Sven Wittorf für wertvolle Informationen

Im Rahmen eines Reviews einer Risikomanagementakte stoße ich auf die berühmte Matrix, in der die Risiken analysiert und die Maßnahmen zu deren Beherrschung zugeordnet sind.

Was meinen Sie, was ist die am häufigsten genannte Maßnahme? Der Titel dieses Beitrags lässt Sie die Antwort vermuten: Testen. Testen als Maßnahme zum Reduzieren von Risiken. Geht das?

Dazu müssen wir zuerst einen Blick in die Definition des Begriffs Risiko werfen: Ein Risiko ist laut ISO 14971 definiert als

Kombination der Wahrscheinlichkeit des Auftretens eines SCHADENS und des SCHWEREGRADES dieses SCHADENS

Ändert Testen nun etwas an der Wahrscheinlichkeit oder am Schweregrad? Da man am Produkt durch das Testen nichts ändert, ändert man weder Wahrscheinlichkeit noch Schweregrad von Schäden, die aus einem fehlerhaften Produkt rühren würde.

Das einzige, was das Testen rechtfertigt, ist eine Annahme über eine Wahrscheinlichkeit. Hat man beispielsweise umfangreich getestet (wobei der Grad dieses Umfangs über Code Coverage zu quantifizieren wäre), kann man argumentieren, dass die Wahrscheinlichkeit für diesen Fehler entsprechend gering ist. Die Wahrscheinlichkeit war aber bereits vor dem Testen so gering, man hatte nur keine Berechtigung, dies anzunehmen.

Testen ist aber keine Maßnahme, die geeignet ist, ein Risiko zu reduzieren. Diese Maßnahmen sind nach MDD nämlich:

• Inhärente Sicherheit
• Schutzmaßnahme
• Hinweise auf Risiken.

Das Testen stellt keine dieser Optionen dar.

Dass Sie dennoch intensiv testen sollten, versteht sich von selbst. Dass Sie damit mit geringeren Wahrscheinlichkeiten argumentieren dürfen, ist noch besser. Vielleicht führen diese geringen Wahrscheinlichkeiten sogar dazu, dass Sie akzeptable Risiken haben, die gar keiner Maßnahmen bedürfen.

Noch mehr zum Thema Risikomanagement lernen Sie anhand von konkreten Fallstudien in meinem Seminar “medizinische Software” am 15. Mai, das allerdings fast ausgebucht ist.