Interne und externe Schnittstellen bei Medizinprodukten

Mittwoch 17. Dezember 2014 von Christian Johner

Spezifikationen sollten das spezifizierte Objekt als Blackbox d.h. über dessen Schnittstellen beschreiben. Das gilt für Objekte die Systeme sind (z.B. PEMS oder Software-System) oder Komponenten (PESS oder Softwarekomponente).

Zerlegt man das Objekt in (Sub-)Komponenten, gilt es im nächsten Schritt diese Subkomponenten zu spezifizieren. Und auch dieses Mal sollten die Schnittstellen beschrieben sein. Dabei kann und muss es vorkommen, dass die Schnittstellen der äußeren Komponente gleichzeitig die der inneren Komponenten sind.

Komponenten-interne-externe-Schnittstellen

Abb 1.: Externe Schnittstellen sind immer auch interne Schnittstellen (hier mit orangenen Kreisen markiert). Umgekehrt haben interne Schnittstellen nicht immer ein externes Pendant.

Den ganzen Beitrag lesen »

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

ISO 9126, ISO 25010 und IEC 62304: Das Zusammenspiel

Dienstag 16. Dezember 2014 von Christian Johner

Ein Mitglied im Auditgarant fragt: “Ist die ISO 9126 noch aktuell? Falls ja, muss ich sie einhalten? Und wie steht diese in Beziehung zur IEC 62304?”

Zur Erinnerung: Die ISO 9126 ist eine Norm, welche eine Taxonomie von Softwarequalitätseigenschaften beschreibt.

Die ISO 9126 ist keine harmonisierte Norm. Genauso wenig ist das deren neuer Nachfolger die ISO 25010.

 

Damit sind beide Normen nicht geeignet, um beim Audit die Erfüllung einer grundlegenden Anforderung vermuten zu lassen.

Aber beide Normen sind als Checkliste geeignet, um die Vollständigkeit der Softwaresystemanforderungen und die der Softwaresystemtests zu prüfen. Es gibt keine formale/normative Beziehung zur IEC 62304, aber die Aspekte, die in deren Kapitel 5.2 (Software-Systemanforderungen) und 5.6/5.7 (Integrations- bzw. Systemtest) genannt werden gehen genau in diese Richtung.

Die Software-Anforderungen (Software Requirements Specification) sollen die Software anhand ihres Verhaltens über deren Schnittstellen beschreiben. Software kennt drei Schnittstellentypen:

  1. Nutzer-System-Schnittstellen (UI)
  2. System-System-Schnittstellen (Datenschnittstellen)
  3. Laufzeitschnittstelle (also zu Hardware, Betriebssystem usw.)

Prüfen Sie Ihre Software-Anforderungen gemäß dieser  ISO 25010 Aspekte wie folgt:

ISO 25010-Aspekt (G)UI: Nutzer-
Schnittstelle
System-
Schnittstellen
Laufzeit-
umgebung
Funktionalität (Functionality)  x  x x
Zuverlässigkeit (Reliability)  x  x  x
Gebrauchstauglichkeit (Usability)  x
(IT-)Sicherheit (Security)  x  x  x
Effizienz (Efficiency)  x  x  x
Wartbarkeit (Maintainability)
Portabilität (Portability)  x
Kompatibilität (Compatibility)  x

Es fällt auf, dass die Wartbarkeit über keine der Schnittstellen erfahrbar ist. Genau deshalb ist sie auch kein Gegenstand der Software-Anforderungen.

Cover-EBook-Checklist-Software-Requirements-Shadow-small

Eine gute Checkliste für Software-Anforderungen habe ich Ihnen bereits vorbereitet.

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

Was macht eigentlich ein Produktmanager? Müssen die uns leidtun?

Montag 15. Dezember 2014 von Christian Johner

Aufgaben von Produktmanagern in der Praxis

Wissen Sie, wie ich Produktmanager erlebe? Das sind Menschen, die den ganzen Tag mit den Kunden reden, von denen hunderte 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.

Produktmanager

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?

Produktmanager in der Wahrnehmung der Kollegen

Viele Produktmanager haben das Gefühl, für all das zuständig zu sein, was andere Rollen nicht abdecken. Ein wenig Projektleitung, ein wenig Marketing, Input für die Entwicklung liefern, Kommunikations-Hub spielen usw.. Eine klare Rollendefinition und Erwartungshaltung fehlt. Eine wirkliche Entscheidungshoheit billigt man Ihnen nicht zu.

Die Entwickler nehmen die Produktmanager oft nicht ernst, sprechen ihnen die Kompetenz ab, beispielsweise Anforderungen vollständig, widerspruchsfrei und stabil zu erheben. Manche Entwickler qualifizieren die Produktmanager gar als “Marketiers” ab.

Aufgaben und Chancen der Produktmanager

Falls Ihnen das bekannt vorkommt, wissen Sie, dass Ihre Firma zumindest noch Effizienzpotenziale steckt. 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 (und weitere Stakeholder-Anforderungen) 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 als Produktmanager dieses Verfahren beherrschen,

  • können Sie die wirklichen Anforderungen Ihrer Kunden entschlüsseln und Ihre Erkenntnisse der Entwicklung “mundgerecht” verfügbar machen,
  • werden Sie als systematisch arbeitender Kollege mit einer eigenen kompetenten Rolle wahrgenommen (der etwas kann, was die anderen nicht können)
  • werden Sie wirklich innovativ sein und durch “sehr gute” Ideen auffallen, die für das Unternehmen eine Lizenz zum Gelddrucken bedeuten können.

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.

Auf was Entwickler in Firmen ohne wirkliche Produktmanager achten sollten

Doch was macht man, wenn es keine Requirements Engineers und Usability-Experten gibt und dafür nicht ausgebildete Produktmanager den Entwicklern nur relativ unspezifische Anforderungen über den Zaun werfen?

Ich beobachte zwei mögliche Konsequenzen:

  1. Die Entwickler entwickeln einfach so, die Spezifikation existiert nur implizit in Form des entwickelten Produkts. Die Konsequenzen im Audit sind klar.
  2. Die Entwickler spezifizieren Fehlendes nach und entwickeln dann die von Ihnen selbst spezifizierte Lösung.

Entwickler sollten jedoch nicht dem Irrtum erliegen, Sie könnten Produktmanger einfach ersetzen: Denn wem gibt man dann die Schuld, wenn das Entwicklungsergebnis nicht den Erwartungen entspricht? Klar, den Entwicklern, denn schließlich haben sie sich so ein Produkt ausgedacht. „Typisch Entwickler…“.

Mein Tipp für Sie Entwickler lautet daher: Die Spezifikation des Produkts ist Ihr Wareneingang. Prüfen Sie dieses Eingangsdokument sorgfältig und lassen Sie nichts „rein“, was unvollständig oder unpräzise ist. Sonst haben Sie nicht nur die Arbeit, sondern auch noch die Schuld. Diese Spezifikation

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

BfArM-Meldungen zu Risiken durch Software

Freitag 12. Dezember 2014 von Christian Johner

Aktueller Zwischenfall: Tod durch Dezimaltrenner

Einmal mehr veröffentlicht das BfArM eine Meldung eines Medizinproduktherstellers, bei der die Wahl der Spracheinstellungen fatale Folgen haben kann:

„Wenn Dosis- oder Bestrahlungsdaten von diesem Problem betroffen sind, könnte dies zu einer massiven Überdosierung des Patienten und in der Folge möglicherweise zum Tod führen.“

In diesem Fall tritt das Problem auf, wenn die in der Software gewählten Spracheinstellungen nicht mit der des Betriebssystems übereinstimmen.

Eine Lektion für alle Hersteller von standalone Software muss daher sicher lauten: Behandlen Sie im Risikomanagement den Fall, dass Ihre Software

  1. nicht auf dem Betriebssystem mit der erwarteten Sprache installiert wird,
  2. das Betriebssystem zwar in der richtigen Sprache installiert aber nicht mit den erwarteten „regional Settings“ („Ländereinstellungen“) genutzt wird und
  3. die Spracheinstellungen in der eigenen Software in jeder Kombination von 1. und 2. funktionieren.

Wer glaubt, dass nur US-amerikanische Firmen sich nicht bewusst sind, dass es verschiedene Dezimaltrenner gibt, täuscht sich. Nicht einmal in Konstanz ist den meisten bewusst, dass es in weniger als 500m Entfernung (der Schweiz) einen Dezimalpunkt gibt.

 

Mit Dank an Jürgen Kraft-Kivikoski

Anzahl von Fehlern in medizinischer Software

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.

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

Anforderungen: Das große Missverständnis

Donnerstag 11. Dezember 2014 von Christian Johner

Laut Standish Chaos Report sind die meisten Projekte verspätet, überteuert, erfüllen nicht die Erwartungen oder scheitern insgesamt. Der Hauptgrund für dieses Scheitern sind unpräzise oder unvollständig erhobene Anforderungen. Doch was sind nun Anforderungen – sei es an Medizinprodukte oder andere Produkte?

Genau genommen gibt es drei verschiedene Typen:

  1. Business-Anforderungen
  2. Stakeholder-Anforderungen insbesondere Nutzungsanforderungen
  3. System-Anforderungen

Diese drei müssen Sie trennen, idealerweise sogar auf verschiedene Dokumente aufteilen, und dann aufeinander zurückführen können (–> Traceability).Den ganzen Beitrag lesen »

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

Weshalb Sie keine große Karriere machen werden

Mittwoch 10. Dezember 2014 von Christian Johner

Mein wichtigstes Anliegen bei den berufsbegleitenden Masterstudiengängen besteht darin, dass die Teilnehmer ihre beruflichen und persönlichen Ziele erreichen. Welche behindernden Glaubenssätze dabei zu überwinden sind, zeigt Professor Larry Smith in einem bemerkenswerten Vortrag.

Wir sind sehr erfolgreich, diese eigenen Grenzen zu überwinden: 75% der Absolventen haben bereits ein Jahr nach Studienabschluss den nächsten Karriereschritt geschafft.

Möchten auch Sie sich weiterentwickeln? Ihr Potenzial nutzen und Ihr Leben auf ein nächstes Niveau bringen? Dann nehmen Sie mit mir Kontakt auf (Kontaktformular).

Kategorie: Lernen & Karriere
Keine Kommentare »

Was Restaurants von Krankenhäusern unterscheidet

Dienstag 9. Dezember 2014 von Christian Johner

Es ist schon erstaunlich, dass man in den Momenten, wo man am meisten drauf angewiesen wäre, nämlich wenn es einem wirklich schlecht geht, den schlechtesten Service bekommt.

Falls Ihnen das Video gefällt, dann schauen Sie noch hier rein: http://www.youtube.com/watch?v=5J67xJKpB6c

Danke an Ludger Seidel

Kategorie: Gesundheitswesen
Tags:
Keine Kommentare »

Was eine SW-SOP zum automatisierten Testen bei embedded Software regeln könnte

Montag 8. Dezember 2014 von Christian Johner

Wir können bei uns nicht automatisiert testen, weil wir sehr Hardware-nah programmieren, antwortet mir mein Kunde auf meine Anregung, durch die Automatisierung gleichzeitig Zeit zu sparen und die Güte der embedded Software zu erhöhen. Und außerdem würde das die IEC 62304 auch nicht verlangen.

Sicher trifft es zu, dass die IEC 62304 keine Automatisierung verlangt. Es ist auch zutreffend, dass bei sehr Hardware-nahe embedded Software die Hardware vorhanden sein muss, um diese Software zu testen. Dennoch: Den ganzen Beitrag lesen »

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

23andMe DNA Test und die FDA

Sonntag 7. Dezember 2014 von Christian Johner

23andMe: jetzt mit CE-Zeichen (Dezember 2014)

Offensichtlich hat sich 23andMe davon überzeugen lassen, dass ihre Produkte doch Medizinprodukte sind. Nach dem FDA-Warning Letter hat die Firma nun sogar ein CE-Zeichen erhalten, wie “SmartBrief” berichtet:

23andMe-CE-mark

Mich würde ja die technische Dokumentation sehr interessieren, v.a. der Teil klinische Bewertung und Risikomanagement.

Wenn es wirklich darauf ankommt (konkret, wenn ich eine Krebserkrankung zu bekämpfen hätte), würde ich mich aber eher den Diensten der Firma Molecular Health anvertrauen. Die WELT berichtet über diese vorbildliche Firma. Ich weiß, über was ich spreche.

Danke an Peter Müllner

23andMe in Trouble (Dezember 2013)

Über die Firma 23andMe habe ich mehrfach berichtet; beispielsweise darüber, dass ich deren Dienstleistungen nutzte und welche Ergebnisse ich bekam. Aber auch darüber, dass 23andMe offensichtlich mehrfach fehlerhafte Berichte erstellte.

Nun hat die FDA einen Warning-Letter an die Firma geschickt, der es in sich hat. Der Firma wird vorgeworfen, dass sie ein Medizinprodukt in Verkehr bringe und aktiv bewerbe, das offensichtlich keine FDA Clearance hat. Diese Abmahnung dürfte für die Firma nicht überraschend kommen, denn die Diskussionen mit der FDA scheinen bereits Jahre anzudauern, ohne dass die Firma es geschafft hätte, den gesetzlichen Anforderungen nachzukommen.

Noch ist die Webseite online, noch kann man die Kits kaufen. Aber die 15 Tagefrist der FDA dürfte kaum ausreichen, das Problem ausreichend zu adressieren.

So sehr ich es bedauern würde, dass Gentests nicht mehr so einfach und preisgünstig verfügbar sind, so nachvollziehbar finde ich die Argumentation Den ganzen Beitrag lesen »

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

Beta-Tests

Freitag 5. Dezember 2014 von Christian Johner

“Darf oder muss ich gar einen Beta-Test für mein Medizinprodukt machen?” So eine aktuelle Frage in meiner kostenlosen Auditsprechstunde.

Ein “öffentlicher” Beta-Test setzt ein CE-Zeichen voraus!

Ein öffentlicher Beta-Test ist eine Inverkehrbringung. Eine Inverkehrbringung ist ohne CE-Zeichen verboten! Ein CE-Zeichen setzt wiederum ein erfolgreich durchlaufenes Konformitätsbewertungsverfahren voraus und dieses wiederum eine klinische Bewertung und eine Usability-Validierung. Beide sind aber keine Beta-Tests!

Beta-Test

Unterscheiden Sie beides präzise und verteilen Sie nicht Ihr Produkt „einfach so“ an Ihre Kunden, auch nicht zum Beta-Testen. Das wäre eine Inverkehrbringung, denn die Frage, ob Sie das Produkt kostenlos abgegeben haben, ist irrelevant.

Beta-Tests ungleich klinische Prüfung

Kennzeichnen Sie Produkte, die Sie für die klinische Prüfung benötigen, explizit. Lassen Sie die Ärzte wissen, dass das Produkt noch nicht „zugelassen“ ist. Holen Sie sich das Votum der Ethikkommission und des BfArMs ein.

Sie können und müssen nach der Inverkehrbringung Ihr Produkt im Markt weiter beobachten. Ob Sie dies dann Feldtests oder Beta-Tests nennen, bleibt Ihnen überlassen. Aber ein nicht CE-gekennzeichnetes Produkt hat bei einem Beta-Test nichts verloren!

In meiner kostenlosen Auditsprechstunde verrate ich Ihnen gerne mehr dazu

  • wie Sie Ihre Produkte gesetzeskonform testen,
  • was Sie bei einer klinischen Bewertung bzw. Prüfung tun müssen und
  • wie Sie am schnellsten zum CE-Zeichen für Ihr Medizinprodukt kommen.

PS: Wussten Sie, dass nicht nur viele Medizinproduktehersteller (Kundenliste), sondern auch benannte Stellen unsere Auditsprechstunde nutzen?

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