{"id":362,"count":29,"description":"Hersteller m\u00fcssen f\u00fcr Medizinprodukte-Software fast immer eine Software-Architektur<\/strong> entwerfen und diese verifizieren.\r\n
\r\n\r\nInhalt<\/strong>\r\n\r\nDiese Seite verschafft Ihnen einen schnellen \u00dcberblick und verlinkt zu weiterf\u00fchrenden Artikeln.\r\n
    \r\n \t
  1. Grundlagen<\/li>\r\n \t
  2. Software-Architektur im Produktlebenszyklus<\/li>\r\n \t
  3. Regulatorische Anforderungen<\/li>\r\n \t
  4. F\u00fcnf Praxistipps<\/li>\r\n \t
  5. Unterst\u00fctzung<\/li>\r\n<\/ol>\r\n<\/div>\r\n

    1. Grundlagen<\/h2>\r\n

    a) Ziel<\/h3>\r\nDie Software-Architektur dient dem Software-Entwicklungsteam als Input, um die Software wie geplant (Zeit, Geld, Qualit\u00e4t) entwickeln zu k\u00f6nnen. Sie soll damit Entwicklungsrisiken minimieren und sicherstellen, dass die Software die Software-Anforderungen<\/a> erf\u00fcllt.\r\n

    b) Definition<\/h3>\r\nUnter Software-Architektur versteht man sowohl eine Phase mit einem Satz an Aktivit\u00e4ten als auch das Ergebnis dieser Aktivit\u00e4ten. Die meisten Definitionen zielen auf das letztere.\r\n
    \r\n
    <\/i> Definition:\u00a0 Software-Architektur<\/dfn><\/div>\r\nDie Software-Architektur ist die Zerlegung eines Software-Systems in Komponenten und die Spezifikation der Schnittstellen zwischen diesen Komponenten.\r\n
    Quelle: Johner Institut, angelehnt an IEEE<\/div>\r\n<\/div>\r\nEine anschauliche Definition stammt von Martin Fowler:\r\n
    \r\n
    <\/i> Definition: \u00a0Software-Architektur<\/dfn><\/div>\r\nDie Menge aller wichtigen und schwer \u00e4nderbaren Entscheidungen\r\n
    Quelle: Martin Fowler<\/a><\/div>\r\n<\/div>\r\n

    2. Software-Architektur im Entwicklungslebenszyklus<\/h2>\r\n

    a) Standalone-Software (Software as a Medical Device)<\/h3>\r\nBei Standalone-Software<\/a> ist die Software-Architektur der \u201eBauplan\u201c, der vorgibt, wie die Software-Anforderungen (der Input) in Software umgesetzt werden soll (s. Abb. 1). Als Output entsteht in dieser Phase die dokumentierte Software-Architektur<\/a>. Dazu z\u00e4hlen die Software-Komponenten<\/a> und die Anforderungen daran.\r\n\r\n[caption id=\"attachment_5371942\" align=\"alignnone\" width=\"1200\"]\"Bild<\/a> Abb. 1: Die Phase \"Software-Architektur\" hat als Input die Software-Anforderungen und als Output die dokumentierte Software-Architektur.[\/caption]\r\n\r\nDie Abbildung 1 erinnert an ein V-Modell<\/a>. Sie ist aber eher als Dokumentationsmodell f\u00fcr die Software-Entwicklung<\/a> zu verstehen und nicht als Prozessmodell.\r\n

    b) Software als Teil eines Produkts (Software in a Medical Device)<\/h3>\r\nAuch bei Software, die Teil eines Produkts ist, dienen die Software-Anforderungen als Input f\u00fcr die Software-Architektur. Sie entsprechen aber nicht den System- bzw. Produktanforderungen<\/a> (s. Abb. 2 und Tipp 1).\r\n\r\n[caption id=\"attachment_5371941\" align=\"alignnone\" width=\"1200\"]\"Bild<\/a> Abb. 2: Auch bei Software, die Teil eines Produkts ist, hat die Phase \"Software-Architektur\" als Input die Software-Anforderungen und als Output die dokumentierte Software-Architektur.[\/caption]\r\n\r\nDer Output ist auch hier die dokumentierte Software-Architektur, einschlie\u00dflich der Anforderungen an die Komponenten.\r\n
    \r\n
    <\/i> Hinweis<\/div>\r\nDie IEC 62304 legt zwar fest, dass der Entwicklungsplan die Vorgaben f\u00fcr Werkzeuge, Methoden und Kodierrichtlinien machen soll. Oft sind diese Festlegungen aber erst sinnvoll m\u00f6glich, wenn die Software-Architektur steht.\r\n\r\n<\/div>\r\n

    c) Zusammenspiel mit dem Risikomanagement<\/h3>\r\nBei Medizinprodukten m\u00fcssen die Software-Architektur und das Software-Risikomanagement<\/a> Hand in Hand arbeiten. Das betrifft insbesondere die Risikoanalyse bei Software<\/a>, beispielsweise mithilfe einer Software-FMEA<\/a> oder des Threat Modelings<\/a>.\r\n\r\nIn dieser Phase sollten auch risikominimierende Ma\u00dfnahmen<\/a> wie die Segregation<\/a> von Komponenten festgelegt werden.\r\n

    d) Abgrenzung (Baucharchitektur)<\/h3>\r\nBauarchitekten erstellen im Gegensatz zu Software-Architekten nicht nur den Bauplan. Sie ermitteln (gemeinsam mit dem Bauherrn) auch die Stakeholder-Anforderungen<\/a>.\r\n\r\nDie Software-Architekten sollten nur den Bauplan (die Software-Architektur) erstellen. Die Anforderungen zu erheben, ist Aufgabe des Requirements-<\/a>Engineering.\r\n

    Regulatorische Anforderungen<\/h2>\r\n

    Europa<\/h3>\r\n

    MDR, IVDR<\/h4>\r\nDie MDR<\/a> und IVDR verlangen Software-Lebenszyklus-Prozesse nach Stand der Technik<\/a> (s. MDR, Anhang I<\/a>, Abschnitt 17.2) und die \u201eBeschreibung des Software-Designs\u201c (s. Anhang II<\/a>, Abschnitt 6.1.b).\r\n

    IEC 62304<\/h4>\r\nDie f\u00fcr diese EU-Verordnungen harmonisierte Norm IEC 62304<\/a> schreibt in den Kapitel 5.3 und 5.4 eine Software-Architektur und ein detailliertes Software-Design<\/a> vor. Dazu m\u00fcssen die Hersteller die Software-Komponenten und Software-Einheiten<\/a> identifizieren und die entsprechenden Schnittstellen<\/a> spezifizieren.\r\n\r\nFalls die Hersteller Off-the-shelf-Software (SOUP)<\/a> verwenden, m\u00fcssen sie auch daf\u00fcr die Anforderungen spezifizieren und die Voraussetzungen f\u00fcr deren Einsatz dokumentieren und gew\u00e4hrleisten.\r\n\r\nDie Norm verpflichtet die Hersteller dazu, die Software-Architektur zu verifizieren, ob beispielsweise alle Anforderungen ber\u00fccksichtigt und Ma\u00dfnahmen zur Risikobeherrschung<\/a> umgesetzt sind.\r\n

    USA<\/h3>\r\nDie FDA<\/a> erkennt die IEC 62304 als \u201erecognized standard\u201c an. Aber die relevantesten Vorgaben an die Software-Architektur formuliert die Beh\u00f6rde in ihrer Leitlinie General Principles of Software Validation<\/a>.\r\n\r\nZudem gibt die Leitlinie Content of the premarket submission<\/a>\u00a0 vor, welche Unterlagen Hersteller einreichen m\u00fcssen. Darin macht die FDA auch Vorgaben f\u00fcr die \u201eSoftware Architecture\u201c und das \u201eSoftware Detailed Design\u201c.\r\n

    Praxistipps<\/h2>\r\n

    Tipp 1: Das Software-System nicht als die Gesamtheit der Software festlegen<\/h3>\r\nMedizinisch-elektrische Ger\u00e4te k\u00f6nnen mehr als eine CPU und damit mehr als eine \u201eSoftware\u201c enthalten (s. Abb. 3). Hersteller sollten nicht die Gesamtheit aller Software als das Software-System definieren. Vielmehr sollte die Software f\u00fcr jede Prozessoreinheit (kann mehrere Kerne enthalten) als eigenes Software-System z\u00e4hlen.\r\n\r\n[caption id=\"attachment_5371943\" align=\"alignnone\" width=\"1200\"]\"Grafik<\/a> Abb. 1: Ein Medizinprodukt besteht aus Komponenten. Diese wiederum enthalten Software.[\/caption]\r\n\r\nDamit vermeiden Hersteller Schichtenarchitekturen<\/a> und\u00a0 Produkte, die gedanklich nach Gewerken in die Schichten Mechanik, Elektronik und Software unterteilt sind. Sie sollten Produkte nach funktionalen \u00dcberlegungen unterteilen.\r\n

    Tipp 2: Den richtigen Zeitpunkt w\u00e4hlen<\/h3>\r\nEs ist weder sinnvoll noch gesetzeskonform, die Software-Architektur erst nach der Software-Entwicklung zu spezifizieren und dokumentieren.\r\n\r\nBei der agilen Software-Entwicklung<\/a> ist ein kontinuierliches Refactoring m\u00f6glich und \u00fcblich. Die Erfahrung zeigt jedoch, dass die meisten Hersteller mit einer pr\u00e4zisen und tragf\u00e4higen Upfront-Architektur sehr gefordert sind. Die konzeptionelle Integrit\u00e4t einer Architektur in einer agilen Entwicklung zu bewahren, klappt nur in wenigen F\u00e4llen.\r\n\r\nDaher ist es hilfreich, die wesentlichen Design-Entscheidungen fr\u00fch und auf Basis stabiler Anforderungen zu treffen.\r\n

    Tipp 3: Definierte Notation verwenden<\/h3>\r\nManche Entwickler dokumentieren die Software-Architektur mithilfe von K\u00e4stchen und Pfeilen in PowerPoint. Bei so einem Pfeil muss allerdings klar sein, was dieser bezeichnet. Eine\r\n