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:
4 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 »

Unit-Tests zur Qualitätssicherung nach IEC 62304?

Mittwoch 17. September 2014 von Christian Johner

+++ Update +++

“Reicht es, die Unit-Tests als PDF zu speichern?”, werde ich in meiner kostenlosen Auditsprechstunde gefragt.

Ich sehe nicht einmal die Notwendigkeit, die Unit-Tests in PDF zu konvertieren. Allerdings würde ich die Ergebnisse – das sind ja oft HTML-Dateien – unter Versionskontrolle stellen, um sie einer eindeutigen Software-Version zuordnen zu können.

Eine Bewertung und Freigabe der (Unit-)Testergebnisse sollten Sie auch haben. Das lässt sich oft bequem im Rahmen des Software-Release formell erreichen. Falls Sie – was ich nicht unbedingt empfehlen würde – „manuell“, d.h. nicht automatisierte Unit-Tests fahren, wird man wahrscheinlich eher auf Papier dokumentieren. Hier können Sie unterschreiben und sollten neben den Ergebnissen auch die Bewertung dieser Ergebnisse nicht vergessen.

Vor vielen Jahren hatte ich mir selbst eine “Minor Non-Conformity” “eingefangen”, weil ich zwar die Ergebnisse meiner Unit-Tests dokumentierte aber vergessen hatte, explizit zu bewerten, ob die Akzeptanzkriterien erfüllt waren.

Nochmals zur Automatisierung: Ich empfehle diese auch, um der Forderung nach Regressionsprüfung zu erfüllen.

+++ Ende Update +++

 

Halten Sie Unit-Tests für ein wirkungsvolles Instrument, um die Qualität Ihrer Software zu sichern? Halten Sie sie für eine Best Practice? Ich hoffe inständig, dass Sie als Leser meines Blogs diese Fragen eindeutig mit “ja” beantworten.

Und was sagt die IEC 62304 zu diesem Thema?

Für Software(komponenten) der Klasse A verlangt sie überhaupt keine Verifikation.

Für Software(komponenten) der Klasse B schlägt sie vor,

  • die Umsetzung der Risikokontrollmaßnahmen zu prüfen,
  • zu prüfen, ob man die Software so entwickelt hat, wie das im Design geplant wurde und
  • zu prüfen, ob Kodierrichtlinien eingehalten wurden.

Wie würden Sie all dies tun? Durch ein Code-Review bzw. mit Werkzeugen zur statischen Code-Analyse.

In anderen Worten: Für Software(komponenten) der Sicherheitsklasse B müssen Sie den Code nicht einmal ausführen. Unit-Tests sind also für diese Sicherheitsklasse nicht einmal vorgeschrieben.

Und genau darauf berufen sich manche Hersteller. Das erinnert mich ein wenig an:

Die IEC 62304 ist schließlich eine Norm, die Minimalanforderungen an die Softwareentwicklung nennt – und keine Best Practicse Norm!

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

Wie sorgfältig arbeiten die Behörden und benannten Stellen? [Update]

Dienstag 16. September 2014 von Christian Johner

+++ Update zum Zulassungsverfahren für Medizinprodukte +++

“Staatliche Zulassungs- und Bewertungsverfahren für Medizinprodukte sind für die Koalition der falsche Weg. Die Grünen sehen darin eine verpasste Chance, den Patientenschutz zu stärken.” titelt das Ärzteblatt am 09.09.2014.

Während die Gesundheitsweisen diese staatliche Zulassung empfohlen hatten, hält die Bundesregierung im Wesentlichen am bisherigen System fest, bei dem die benannten Stellen an der Konformitätsbewertung der Hersteller beteiligt sind. Sie sagt, es lägen keine Erkenntnisse vor, die die Annahme rechtfertigen, dass die Zulassung (also eher ein FDA-vergleichbares System) die Patientensicherheit erhöhen würde.

Zu diesem Ergebnis kommt auch eine Studie, die das FDA und das EU-System verglich. Dass dennoch Handlungsbedarf besteht, halte ich für unbestritten (siehe unten).

+++ Ende Update +++Den ganzen Beitrag lesen »

Kategorie: Allgemein
Tags: , ,
Keine Kommentare »

Cloud-Computing im Gesundheitswesen [Update]

Montag 15. September 2014 von Christian Johner

+++ Update Beginn 15.09.14 +++

Erneut ist Philips Healthcare zumindest indirekt in den Fokus der Datenschutzbeauftragten geraten. Der bayerische Datenschutzbeauftragte hat in einem Schreiben an das Ministerium gerügt, dass Krankenhäuser die Radiologiedaten in der Cloud, genau in den Rechenzentren von Philips in den Niederlanden speichern würden. Weil die Daten dort unverschlüsselt liegen, könnten  Unbefugte darauf zugreifen.

Der Datenschutzbeauftragte bittet das Ministerium zu prüfen, welche aufsichtsrechtlichen Möglichkeiten bestehen um sicherzustellen, dass der Datenschutz eingehalten wird.

Es ist stark zu vermuten, dass weder nur ein Krankenhaus das Cloud-Computing-Angebot von Philips Healthcare nutzt, noch dass Philips Healthcare die einzige Firma ist, die vergleichbare Dienste anbietet. Daher stehen wahrscheinlich einige Krankenhäuser und einige Firmen vor der Aufgabe, bestehende Vereinbarungen und Lösungen zu prüfen und anzupassen.

Leiter besteht nicht nur die Gefahr, dass Mitarbeiter des Dienstleisters auf unverschlüsselte Daten zugreifen können, sondern auch dass im ungünstigsten Fall Hacker Zugriff bekommen. Das haben ja leider einige Promis diese Tage leidvoll mit der iCloud erfahren müssen.

Nachtrag:

Der bayr. DSB hat konkret bemängelt, dass es keine Ende-zu-Ende Verschlüsselung der Patientendaten gibt. Bisher war das Verfahren so, dass die Daten zwar in einem verschlüsselten Tunnel übertragen wurden, jedoch erst im RZ in Holland verschlüsselt wurden. Damit hat faktisch Philips die Kontrolle über die gespeicherten Daten, da der Schlüssel nicht in der Hand der Klinik liegt und zudem ein kurzer Moment existiert, in dem die Daten zwischen Tunnel und Verschlüsselung unverschlüsselt vorliegen.

Dies wird bis 2015 geändert. Bis dahin werden die Backups wieder vor Ort gespeichert.

+++ Update Ende +++

Den ganzen Beitrag lesen »

Kategorie: Gesundheitswesen, Med. Informatik
Tags:
2 Kommentare »

Code-Prüfungen im Audit

Freitag 12. September 2014 von Christian Johner

Kann man durch eine „geeignete Wahl“ der Software-Sicherheitsklasse Code-Prüfungen im Audit vermeiden?

Diese für mich überraschende Frage hat mich über meine kostenlose Auditsprechstunde erreicht.

Es gab zwei Befürchtungen, die mit dieser Frage verbunden waren:

  1. Der Auditor sieht unseren Code und erfährt dadurch Firmengeheimnisse.
  2. Der Auditor findet Fehler in unserem Code.

Beide Befürchtungen möchte ich ein wenig relativieren. Den ganzen Beitrag lesen »

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

Software-Schnittstellen: Beschreibung konform IEC 62304

Donnerstag 11. September 2014 von Christian Johner

Die IEC 62304 verlangt in Kapitel 5.3.2, dass die Hersteller die Schnittstellen zwischen den Software-Komponenten dokumentieren. Doch können sie das elegant erreichen?

Ich habe Ihnen einen Artikel erstellt, in dem Sie lernen

  • wie Sie Schnittstellen normen-konform und effizient dokumentieren
  • auf was Sie achten sollten, wenn Sie die Schnittstellen von SOUPs beschreiben
  • welche UML-Diagramme Ihnen helfen
  • wie Sie bereits an der Beschreibung der Schnittstelle Rückschlüsse auf die Güte Ihrer Architektur ziehen können.

Normenkonformität hat auch bei der Spezifikation von Software-Schnittstellen nichts mit Overhead zu tun. Lernen Sie in diesem Artikel, wie das schnell und einfach gelingt.

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

Gedanken von Christian Johner

Mittwoch 10. September 2014 von Christian Johner

Digitale Wegwerfkultur

Vieles, was für klinische Informationssysteme und Medizingeräte-Software wichtig ist, scheint bei App-Entwicklern nicht relevant zu sein:

Bei ersteren werden durch die Wahl der Technologie und der Architektur die Weichen für viele Jahre, manchmal Jahrzehnte gestellt. Eine gute Architektur wird dem Team über Jahre helfen, das Produkt ohne unnötigen Aufwand zu warten und weiter zu entwickeln. An Technologien wie Frameworks, Betriebssystemen und Bibliotheken halten Medizinproduktehersteller über Jahre fest – oder müssen daran festhalten. Nur so können sie den regulatorischen Aufwand und Patientenrisiken durch Änderungen der Software begrenzen.

Ganz anderes ticken viele App-Entwickler, auch solche von Medical Apps. Den ganzen Beitrag lesen »

Kategorie: Allgemein
1 Kommentar »