Bildungssysteme: USA versus Deutschland

Mittwoch 1. Oktober 2014 von Christian Johner

Wir Deutschen sind meist sehr stolz auf unser Bildungssystem. Aus dieser Hybris lassen wir uns auch durch die Ergebnisse von PISA-Studien nicht herausreisen. Während der Stanford-Woche mit meinem MBA-Studiengang bin nicht nur ich sehr ins Grübeln gekommen.

Stanford-MBA-Johner-Institut

Dr. Weiler ist Professor (emeritus) sowohl der Stanford University als auch deutscher Universitäten. Professor Weiler ist sowohl Deutscher als auch Amerikaner. Er hat uns auf einige Aspekte aufmerksam gemacht, die zur Leistungsfähigkeit US-amerikanischer Universitäten beitragen:

Den ganzen Beitrag lesen »

Kategorie: Johner Institut, Lernen & Karriere, Stanford University
Tags: ,
2 Kommentare »

Interne Audits: Die Wahrheit verheimlichen?

Dienstag 30. September 2014 von Christian Johner

Dürfen Benannte Stellen interne Auditberichte einsehen? Das würde doch im Widerspruch zu einem gründlichen Auditansatz stehen, fragt man mich. Schließlich möchte man sich als interner Auditor nur ungerne selbst diskreditieren. So würde die Motivation untergraben, ein gründliches internes Audit zu machen, so der Gedanke des Fragenden.

ISO 13485 konformes QM-System

Zumindest wenn Sie Ihr Produkt nach Anhang II in Verkehr bringen, müssen Sie über ein ISO 13485 zertifiziert QM-System verfügen. Die ISO 13485 fordert interne Audits. Also muss der Auditor das prüfen. Anders kann er die Normenkonformität nicht feststellen. Sie benötigen also interne Auditberichte. Doch in welcher Offenheit?

Meine Tipps zu internen Audits

Ich verstehe völlig den Impuls, dass man die selbst gefundenen Fehler nicht offenbaren will. Mit diesen Fehlern hat aber ein Auditor kein Problem, solange Sie zeigen, dass Sie diese Fehler konsequent und zeitnah angehen.

Ich würde sogar einen Schritt weiter gehen: Wenn Ihr Auditor Findings hat, die Sie selbst hätten finden können, haben Sie ein doppeltes Problem: Weder haben Sie die gefundene Normenforderung erfüllt, noch scheint Ihr internes Audit wirkungsvoll zu sein. Die benannten Stellen sind ja in Europa — im Gegensatz zur FDA — auch eher Partner als Feinde.

Transparenz habe ich diesbezüglich noch nie als Nachteil erlebt.

Kategorie: IEC 62304 & Co.
Tags: , ,
Keine Kommentare »

Integrationstest gemäß IEC 62304

Montag 29. September 2014 von Christian Johner

Die Formulierungen der IEC 62304 zu den Integrationsprüfungen bzw. Integrationstests sind manchmal etwas unglücklich und werfen Fragen auf, wie und was denn bei den Integrationstests nun konkret gemacht werden solle. Was die Autoren die IEC 62304 im Kapitel 5.6 zu den Integrationstests gemeint haben, lässt sich am ehesten aus dem Anhang B.5.6 ableiten:

Bei der Korrektheit geht es darum, dass zum einen das bzw. die richtigen “Verfahren” gewählt wurden und zum anderen dass man diese auch richtig angewendet hat. Der Begriff Verfahren umschließt dabei

  1. die Verfahren, um die Reihenfolge zu bestimmen, mit denen die Komponenten integriert werden (-> Integrationsstrategie),
  2. die Verfahren, mit denen die Testfälle abgeleitet werden (-> typische White- und Blackbox-Verfahren wie Äquivalenzklassen-, Entscheidungstabellen, Fehler-basierte Testverfahren).

Ein wesentliches Ziel von Integrationstests besteht darin sicherzustellen, dass die Schnittstellen der Komponenten zueinander passen. Denn genau das lässt sich mit Komponenten-/Unit-Tests nicht prüfen. Denken Sie an die eine abgestürzte Raumsonde, bei der ein Modul (eine Komponente) SI-Einheiten nutzte, ein zweites “imperial units”. Die Modul-/Komponententests konnten keine Fehler finden, Integrationsprüfungen hätten das hingegen leisten können.

Die Norm wünscht nur, dass man sich Gedanken macht, ob die gewählten Verfahren überhaupt geeignet sind, Fehler zu finden, wobei ein besonderer Wert auf Fehler zu legen ist, die sicherheitskritische Folgen nach sich ziehen können.

Mehr zu den Software-Tests lernen Sie im Auditgarant.

Videotrainings des Auditgarants ansehen

Kategorie: IEC 62304 & Co.
Tags: ,
Keine Kommentare »

Usability Trainings: Helfen Sie mir? Dauert nur 30 Sekunden!

Freitag 26. September 2014 von Christian Johner

Ich möchte Ihnen mit Videotrainings, Beispielunterlagen und Antworten auf Ihre Fragen helfen, dass Sie nicht nur für Patienten und Anwender sichere Medizinprodukte entwickeln und „auditsicher“ dokumentieren können, sondern dass Sie mit einem professionellen Usability und Requirements Engineering Ihre Entwicklungszeiten massiv reduzieren, Reibereien zwischen Produktmanagement und Entwicklung vermeiden und im Markt mit Ihren Produkten super erfolgreich zu sein.

Damit ich Ihnen bestmöglich helfen kann, würde ich Sie bitten, mich wissen zu lassen,

  • was Sie am Thema Usability und Requirements Engineering am meisten interessiert
  • auf welche Probleme Sie dabei stoßen
  • was Ihnen noch unklar ist und welche Fragen Sie dazu haben.

Ich habe dazu zwei Fragen an Sie, mit deren Beantwortung Sie mir einen riesigen Gefallen machen und mir sehr viel weiter helfen würden:

http://bit.ly/1ms1X6W

Kategorie: IEC 62304 & Co., Lernen & Karriere
Tags: ,
Keine Kommentare »

Change Requests

Donnerstag 25. September 2014 von Christian Johner

Einer der Lieblingsansatzpunkte in Audits sind die Change Requests. Entsprechend häufig bekomme ich die Frage gestellt, weshalb und wie man diese dokumentieren müsse.

Hier ein paar Gedanken zu den Change Requests:

  1. Zum einen geht es bei den Change Requests um das reine Erfassen von Information, die Sie benötigen
    • für die Entwickler, was das zu lösende Problem ist. Das hat etwas mit Punkt 3. weiter unten zu tun.
    • für die Trendanalyse z.B. mit Hinblick auf den Problemlösungsprozess der IEC 62304 und das Kapitel 8 (Messung und Verbesserung) der ISO 13485
    • für die nachgelagerte Phase und das Risikomanagement (Kapitel 9 der ISO 14971): Sind Risiken richtig eingeschätzt oder gar bisher nicht bekannte gefunden worden?
  2. Dann geht es bei den Change Requests um die Freigabe, dass überhaupt etwas geändert werden darf. Die IEC 62304 spricht hier nicht von Change Requests sondern vom Konfigurationsmanagementprozess.
  3. Und schließlich benötigen Sie alle Informationen, die einer Software-Anforderung / Spezifikation (bzw. einer Änderung derer) entsprechen. Hier geht es um die Änderungen der Blackbox Software. Vielleicht sind Ihnen hier die kostenlosen Videotrainings auf http://www.johner-institut.de/auditgarant hilfreich.

Sie sehen, wenn Sie mit den Change Requests sauber umgehen, haben Sie die Forderungen von gleich drei Normen (IEC 62304, ISO 13485 und ISO 14971) berücksichtigt. Falls nicht, verlieren Sie die Konformität mit gleich drei Normen. Also Vorsicht!

Kategorie: IEC 62304 & Co.
Tags: , , ,
Keine Kommentare »

Usability und Requirements Engineering und IEC 62366

Mittwoch 24. September 2014 von Christian Johner

Usability und Requirements Engineering: Was Sie damit alles erreichen können

Ich weiß nicht ob es das warme und sonnige Klima, einfach der Ortswechsel oder die vielen Menschen im Silicon Valley sind, die mich inspirieren. Sicher aber auch die vielen Gespräche mit Thomas Geis zum Thema Usability und Requirements Engineering. Kein Wunder, seit Wochen arbeiten wir an einem Buch zur Usability und IEC 62366.

Kein anderes Thema halte ich für so wichtig, weil Sie nur mit einem präzisen Usability und Requirements Engineering …

  • für Patienten und Anwender sichere Medizinprodukte herstellen werden,
  • die Forderungen der IEC 62366 und FDA erfüllen und so Probleme in Audits und bei Einreichungen vermeiden,
  • sich das den sich scheinbar ständig ändernden Kundenanforderungen Hinterheriterieren sparen können (und damit völlig überteuerte und verzögerte Entwicklungsprojekte vermeiden) und
  • endlich die Chance haben, mit wirklich innovativen Produkten den Markt aufzurollen.

Wie Sie dieses zugegeben hohe Versprechen eingelöst bekommen, das möchte ich in den nächsten Wochen adressieren. Doch hören Sie selbst, auf was Sie sich im Kontext Usability und Requirements Engineering sowie IEC 62366 freuen dürfen:

Kategorie: IEC 62304 & Co., Stanford University
Tags: , , ,
Keine Kommentare »

Ausgelagerte Entwicklung

Dienstag 23. September 2014 von Christian Johner

Frage: Was ist bzgl. der Dokumentation zu beachten, wenn die SW-Entwicklung ausgelagert ist? Requirements und Systemtests werden vom Hersteller erstellt bzw. durchgeführt; die Implementierung und Unit-Tests vom Service-Partner.

Antwort: Das ist eine nicht ganz ungefährliche Sache. Generell gibt es zwei Szenarien:

  1. Im ersten Szenario hat der Partner eine ISO 13485. Dann genügt der Austausch der Dokumentation. Ein Audit bei Ihnen würde sich auf die Prüfung dieser Dokumentation und des ISO 13485 Zertifikates des Partners beschränken.
  2. Im zweiten Szenario arbeitet der Partner nach IHREM QM-System. Dann sollten Sie nicht nur die Dokumente prüfen, sondern auch den Prozess, d.h. idealerweise auch ein „Supplier Audit“ machen. Wenn Sie selbst auditiert werden, kann es sein, dass das Audit auf Ihren Supplier durchschlägt. D.h. Ihr Auditor möchte Ihren Supplier besuchen. Genau deshalb wählt man meist lieber ISO 13485 zertifizierte Entwicklungspartner, also Variante 1.

Kategorie: IEC 62304 & Co.
Tags:
6 Kommentare »

MBA in Stanford

Montag 22. September 2014 von Christian Johner

MBA: Die Stanford-Woche beginnt

Wieder in Stanford, an meiner alten Wirkungsstätte. Ein wunderbares Erlebnis, wenn gleich mit nur zwei Wochen ein viel zu kurzes. Mit meinem MBA-Kurs werde ich eine Woche das Silicon Valley unsicher machen, über das amerikanische Gesundheitssystem lernen, in die Welt von Ontologien und ICD 11 abtauchen, verstehen, wie Gesundheitsorganisationen neue Verfahren und Therapien ausprobieren und natürlich auch den kalifornischen Spätsommer genießen. Doch überzeugen Sie sich selbst:

Vorbereitungen für die MBA Woche

Die Vorfreude ist groß: Diese Woche habe ich die Reise ins Silicon Valley gebucht: Flüge, Mietwagen und Hotel, wobei Hotel nicht ganz der richtige Ausdruck ist: Ich werde mit meinen MBA-Studierenden wieder im Stanford Guesthouse sein.

Stanford Guesthouse

Wir können uns im September wie immer auf traumhaftes Wetter freuen. Ein echter “Schön-Wetter-MBA” :-). Momentan zerfließt aber Stanford noch etwas im Selbstmitleid und postet Bilder zu „Reflections of winter at Stanford“. Die ärmsten leiden: unter Regen. Wie schrecklich ;-)!

Kategorie: Lernen & Karriere, Stanford University
Tags:
Keine Kommentare »

Kapselung von Software-Komponenten erfolgreich zerstören

Freitag 19. September 2014 von Christian Johner

Eines der zentralen Architektur-Paradigmen lautet: „Weak coupling and strong cohesion“. Es sollte also eine schwache Kopplung zwischen den Komponenten und ein starker Zusammenhalt innerhalb einer Komponente bestehen.

Die Architekturen mancher Medizinproduktehersteller verkörpern genau das Gegenteil. Daher möchte ich Ihnen ein paar Tipps geben, wie auch Sie die Kapselung Ihrer Komponenten schnell und erfolgreich zerstören können :-):

  1. Am besten Sie bilden gar keine Komponenten. Vielmehr malen Sie in Powerpoint um eine willkürliche Auswahl an Klassen einen Rahmen und nennen diesen „Komponente“.
  2. Nutzen Sie bei Ihren Klassen bzw. Methoden/Funktionen möglichst oft das Schlüsselwort „public“. Schließlich soll doch jeder auf die großartigen Funktionen zugreifen können.
  3. Achten Sie darauf, dass Ihre Methoden möglichst viele Übergabeparameter haben. Es ist doch super praktisch, eine Klasse Patient mit allen Angaben wie Vorname, Nachname, Geburtsname, Geburtsdatum, Wohnort, Postleitzahl, Straße, Land, Name Versicherung, Versicherungsstatus, Versicherungsnummer usw. zu instanzieren. Oder?
  4. Zu den Klassikern zählen möglichst viele globale Variable. Nur so können Sie von überall auf deren Werte zugreifen.
  5. Sehr bewährt hat es sich bei objektorientierten Sprachen über Komponentengrenzen hinweg zu erben. Damit können auch andere Komponenten von den raffinierten Funktionalitäten einer Super-Komponente profitieren.
  6. Ebenso zielführend ist es, Fehler über Komponentengrenzen zu werfen.

Apropos Objektorientierung: Wer hat sich eigentlich diesen Quatsch ausgedacht?

In diesem Sinn wünsche ich viel Freude beim Einreißen von (Komponenten-) Grenzen :-)!

PS: In diesem Sinn völlig kontraproduktive Hinweise zum IEC 62304 konformen Erstellen und Dokumentieren Ihrer Software-Architektur geben Ihnen die Videotrainings des Auditgarants.

Kategorie: IEC 62304 & Co.
Tags: ,
Keine Kommentare »

Request ungleich Requirement

Donnerstag 18. September 2014 von Christian Johner

Mit der englischen Sprache ist das so eine Sache. Sie ist oft etwas präziser als die deutsche. Bei uns sind ja Bugs, errors, failures und faults alles Fehler. Security und Safety immer Sicherheit.

Und genauso sorglos gehen wir mit dem Begriffspaar Request und Requirement um. Regelmäßig höre ich in Firmen, dass ein “customer requirement” zu erfüllen sei. Wenn ich mir dann ansehe, was das ist, handelt es sich aber gar nicht um ein customer requirement, sondern schlicht um eine Kundenanfrage oder einen Kundenwunsch. Und eben nicht um ein Requirement.

Customer-Request-Customer-Requirement

Den ganzen Beitrag lesen »

Kategorie: IEC 62304 & Co.
Tags: , , ,
1 Kommentar »