Wir entwickeln eine Diagnoseanwendung mit Java, Spring, Hibernate und einigen anderen Standardbibliotheken. Gemäß den Richtlinien der FDA (und einem Beratungsunternehmen) sollten Open-Source-Bibliotheken White-Box-getestet sein (da wir den Quellcode für sie haben), wenn sie sich im kritischen Pfad der Anwendung befinden.
Wenn ich eine Datenbanktabellenzeile lesen muss, dauert es 100s von API-Aufrufen, um die einzelne Zeile von db zu erhalten, weil die Transaktion hibernate hql-sql, jdbc api in den Prozess involviert ist.
Bedeutet dies, dass ich jeden einzelnen dieser API-Aufrufe validieren muss?
Sollten wir Java auch mit einer Drittanbieter-Bibliothek behandeln und jeden einzelnen API-Aufruf, den wir in unserer Anwendung verwenden, validieren?
Reicht es nicht aus, diese Bibliotheken in einer Black Box zu testen?
Gibt es medizinische Geräte / Diagnose- / Krankenhaus-Software, die Spring / Hibernate und andere Open-Source-Bibliotheken verwenden?
Ich bin sehr daran interessiert, zu wissen, ob einige von euch diese Situation kennengelernt haben und wie Sie das gelöst haben?
Schätzen Sie Ihre Zeit! Danke.
Ich bin kein Experte in Bezug auf die FDA-Anforderungen und habe mich seit fünf Jahren überhaupt nicht mit ihnen beschäftigt. Aber ...
Erstens, wenn ich mich nicht irre und die Dinge sich nicht geändert haben, sagt die FDA nichts über "kritischen Pfad" - sie sprechen über Dinge, die "sicherheitskritisch" sind - Dinge, die, wenn sie scheitern, können zu Verletzungen oder zum Tod führen. Wenn Sie einen Weg finden, "das Risiko zu mindern" - um sicherzustellen, dass dies nicht geschieht, unabhängig davon, wie Hibernate versagt, denke ich, Sie sind aus dem Schneider. Es ist wahrscheinlich die Zeit wert, sehr, sehr intensiv darüber nachzudenken, wie Sie dies erreichen könnten.
Wenn zum Beispiel das System einfach nichts macht sicher ist (im Gegensatz zur falschen Sache ), dann können Sie vielleicht einen Nachrichten-Digest mit schreiben jeder Datensatz, der den Schlüssel enthält, mit dem Sie den Datensatz finden. Wenn Sie nachweisen können, dass ein Fehler beim korrekten Schreiben oder Lesen des Datensatzes erkannt wurde, können Sie für eine bestimmte Anzahl von Tests nicht mehr verwenden. Ich weiß nicht, wie Sie Hibernate verwenden - das würde wahrscheinlich nicht alles abdecken. Ich meine es nur, um dir zu helfen, den richtigen Weg zu finden.
In den meisten Fällen umfasst dies einige redundante Daten, mit denen Sie überprüfen können, was Sie abgerufen haben, und redundante Lesevorgänge, um sicherzustellen, dass Sie das geschrieben haben, was Sie Ihrer Meinung nach geschrieben haben. Dies beinhaltet oft eine Menge kontraintuitives Design - stellen Sie Ihre Vorsätze von Best Practices beiseite und lassen Sie sich von den Anforderungen an sicherheitskritisches Design leiten. Verwechseln Sie Zuverlässigkeit nicht mit Sicherheit. Sie sind anders; manchmal streiten sie sich sogar.
Es kann möglich sein, dass Sie die Überprüfung mithilfe der Hibernate-Einheit und Integrationstests durchführen. Ich weiß es nicht. Ich vermute, dass dies eine Menge Reverse-Engineering und Dokumentation erfordern würde, um den Bedarf zu decken.
Wenn Sie wirklich nur eine kleine Teilmenge einer großen komplexen Bibliothek verwenden und Sie keine Möglichkeit finden, Sicherheits-Kritikalität abzuschwächen, ist es in der Tat der richtige Weg, dies zu tun. Machen Sie eine ehrliche Kosten-Nutzen-Analyse.
Für einige Softwareprodukte, die häufig in sicherheitskritischen Systemen verwendet werden, können Sie Validierungs-Suites kaufen, die für diesen Zweck vorgesehen sind. Wahrscheinlich nicht Hibernate, aber es lohnt sich zu überprüfen. Selbst in diesem Fall denke ich, dass Sie eine angemessene Menge an Due Diligence durchführen müssen.
Wenn Sie vorhaben, weiterhin medizinische Software zu schreiben, lohnt es sich, etwas zu lesen und sich etwas zu üben.
Ich glaube, dass Allgemeine Prinzipien der Software-Validierung immer noch eine wichtige FDA-Richtlinie ist. Auch und direkt am Punkt, siehe Anleitung ... zur Verwendung von Standardsoftware in medizinischen Geräten . Sie werden eine Menge Dinge lesen, die vage oder unerwartet sind. Verwenden Sie Ihre Berater zur Klärung. Diese sind immer noch aktuell (denke ich), aber wirklich alt, so dass sich die wirklichen Erwartungen der FDA entwickelt haben.
Ich denke auch, dass es sich lohnt zu untersuchen, wie Systeme, die als sicher geplant sind, in der realen Welt versagen. Ich prüfe Dinge wie Challenger, die Ölpest im Golf von Mexiko, Fukushima und Flugzeugabstürze, bei denen es um Avionik und / oder Pilotenfehler geht. Ein gutes Buch zum Auschecken, obwohl es veraltet ist, ist Safeware . Ein Grund ist, deinen Respekt für Murphy und sein Gesetz zu verstärken. Eine weitere Möglichkeit besteht darin, zu verstehen, wie Organisationen unter dem Druck ihrer Sicherheitsversprechen scheitern. Sie werden wahrscheinlich auf die eine oder andere Weise in schwierige Entscheidungen verwickelt sein. Holen Sie sich etwas aus zweiter Hand in was nicht zu tun ist.
Schließlich - Ignorieren Sie alle Ratschläge, die Sie von Leuten bekommen, die nicht mit den Anforderungen der FDA Medizinprodukte-Software vertraut sind, und auch keine Erfahrung mit dem Schreiben von Sicherheit haben -kritische Software mit regulatorischen Anforderungen (Avionik-Erfahrung könnte relevant sein). Es ist anders.
Tags und Links java hibernate spring medical safety-critical