… oder wie das Internet insgesamt ausfiel

Schon wieder eine neue EU Verordnung, denken Sie jetzt vielleicht. Braucht es das wirklich?

Genau diese Frage stelle ich mir auch. Doch der Reihe nach: Um was geht es?

Die EU Richtlinie 207/2012 erlaubt, dass man unter Umständen durchaus die Gebrauchsanweisung statt auf Papier auch elektronisch vorlegen darf. Ich wundere mich, ob jetzt alles erst explizit erlaubt sein muss. Unser Rechtssystem funktioniert eigentlich anders herum. Doch sehen wir die gute Seite: Es gibt ein wenig mehr Rechtssicherheit.

Die elektronische Gebrauchsanweisung ist beispielsweise für eigenständige Software oder für Medizinprodukte, “in die ein System zur Anzeige der Gebrauchsanweisung eingebaut ist”, erlaubt, solange man damit ausschließlich professionelle Nutzer adressiert.

Wenn man die elektronische Gebrauchsanweisung statt einer Gebrauchsanweisung in Papierform zur Verfügung stellt, muss aber eine dokumentierte Risikobewertung durchführen. Das ist ja per se nichts Neues. Neu sind hingegen die Aspekte, die dabei beachtet werden sollen, beispielsweise die “Auswirkungen eines zeitweisen Ausfalls [...] des Internets insgesamt [...]“.

Jetzt haben wir es: Das Internet kann insgesamt ausfallen! Beispielsweise durch einen globalen Stromausfall. Oder durch eine Abschaltung durch den US Gemeindienst. Das hätte ich doch glatt in meiner Risikoanalyse vergessen. Danke EU!

Wo wir gerade bei konspirativen Veränderungen von Gebrauchsanweisungen sind: “Die Website ist gegen unerlaubtes Eindringen durch Hard- oder Software geschützt.” Ist gemeint, dass Hard- oder Software eindringen? Das ergäbe keinen Sinn. Oder ist gemeint, dass man die Webseite durch Hard- oder Software schützen muss? Durch was sonst? Einen Türsteher?

Und wenn wir gerade am Lästern sind: Die nächste Forderung “die Website ist so eingerichtet, dass so selten wie möglich Server-Ausfälle und Anzeigefehler auftreten” lässt mich auch wundern. Hat jemand von Ihnen Server im Betrieb, die häufiger als so selten wie möglich ausfallen?

Ich bin mir nicht ganz sicher, ob uns die EU einen Gefallen bereitet hat, uns diese Richtlinie zu bescheren. Vielleicht gibt es bald eine neue Gilde der 207/2012-Berater. Im Sinne einer Arbeitsplatzbeschaffungsmaßnahme wäre die Richtlinie dann ein Segen

Danke Sven für einen zynischen Aufschlag zu diesem Artikel

Die Frage, was eine technische Dokumentation, das berühmte “Technical File”, alles enthalten sollte, hat die Firma MedCert, wie ich finde, auf ihrer Webseite sehr gut zusammengefasst.

Ich habe Ihnen die notwendigen Dokumente in eine Mindmap übertragen:

Sie können sich die Mindmap hier in voller Größe herunterladen.

Ebenfalls für wichtig halte ich das auf der Webseite von MedCert erwähnte Dokument NB-MED/2.5.1/Rec.5 rev.4 (Technical Documentation).

Ein zumindest bei stand-alone Software häufig eingesetzter Architekturstil ist die Schichtenarchitektur: Man zerlegt das ganze System in eine Dialog-, Präsentations-, Geschäftslogik-, Datenzugriffs- und Persistenzschicht.

Dabei ist die Architektur nur dann eine gute, wenn sie diese Schichten bestmöglich getrennt hält (also wirklich komponentenorientiert ist) und wenn Sie geeignet ist, die Systemspezifikation zu erfüllen.

Zumindest letzteres können Sie beim Architektur-Review mit einem Rollenspiel wirkungsvoll prüfen:

Eine Person spielt beispielweise die GUI (also Dialog- und/oder Präsentationsschicht), eine andere Person die Geschäftslogik. Dann geht die GUI stückweise ihre Bildschirmmasken durch und schaut, was sie an Nutzungsobjekten hat. Wenn es beispielsweise eine Tabelle gibt, die alle weiblichen Patienten über 65 mit eine Nephropathie und mit einem Hämoglobinwert unter 10mg/dl und mit einer bestimmten EPO-Dosis anzeigt, dann bittet der “GUI-Schauspieler” seinen Geschäftslogik-Kollegen, genau diese Daten zu besorgen und dazu im UML-Diagramm zu erklären, welche Methodenkaskade genau diese Daten berechnet und zurückliefert.

Sie gehen dieses Spiel nicht nur für alle Nutzungsobjekte, sondern auch für alle Werkzeuge durch. Die GUI-Vertreter bittet z.B. den Geschäftslogik-Vertreter zu beschreiben, wie die Architektur auf das Klicken des Speichern-Buttons reagiert. Bei einem Ultra-Thin-Client müsste es für jedes Nutzungsobjekt und jedes Werkzeug eine Methode im Backend geben.

Das Ziel der Person, die die Rolle der GUI vertritt, besteht darin, der Architektur nachzuweisen, dass sie nicht in der Lage ist, alle notwendigen Daten zu besorgen oder abzuspeichern. Nach einer Weile – das wäre mein Tipp – sollten die beiden “Schauspieler” die Rolle wechseln. Glauben Sie mir, intensiver lässt sich eine Architektur kaum prüfen. Das bedingt natürlich, dass Sie Ihre Architektur modelliert haben.

Benötigen Sie noch Hilfe beim Modellieren oder Prüfen (“Reviewen”) Ihrer Architektur? Dann melden Sie sich doch bei mir, ich helfe gerne.

Dass sich die EU auf ihrer Webseite die Mühe gibt, mit einem Video zu erklären, wann ein Konformitätsbewertungsverfahren notwendig wird, wie es abläuft und wie man zum CE-Zeichen kommt, finde ich wirklich gut. Aber die Umsetzung lässt mich schaudern!

Über das Aussehen der Protagonisten kann man ja noch streiten. Auch wenn ich als benannte Stelle nicht gerne so dargestellt würde, wie hier zu sehen:

 

Das erinnert mich eher an Frankenstein.

Viel bedauerlicher finde ich es, dass man ein kleines bisschen die Chance verpasst, ein wirklich verständliches und lehrreiches Video zu produzieren. Es gibt zu viel unnötige und unkonkrete Information. Am Ende weiß man dann doch nicht, was man nun tun soll. Mit 10 Sätzen hätte man das prägnanter ausdrücken können. Schade, da wäre mehr drin gewesen.

Schauen Sie sich vielleicht eines meiner webbased Trainings im Institutsclub an (geht dank Probemitgliedschaft kostenlos und unverbindlich) und vergleichen Sie dann. Ich bin an Ihrer Meinung interessiert.

PS: @EU: Lassen Sie mich wissen, wenn ich Sie unterstützen kann, noch bessere Lehrmaterialien zu erstellen.

Im Juni tritt die siebte Version des MED-DEV Dokuments MEDDEV 2.12/1 in Kraft. Darin sind Richtlinien für Meldesysteme beschrieben.

Interessant finde ich im Anhang 1 die Beispiele für meldepflichtige Vorkommnisse. Zwar finden sich keine für stand-alone Software, aber doch einige, die einen Bezug zu Softwarefehlern vermuten lassen.

Beispielsweise ist eine falsche Zuordnung von Patienten zu Untersuchungsergebnissen meldepflichtig. Dass Bugs in Herzschrittmachern gemeldet werden müssen, überrascht kaum. Auch solche, die “nur” mit ausgebliebenen Hinweisen auf einen fälligen Austausch des Geräts in Zusammenhangen stehen.

Ãœbrigens: Wenn Sie wissen wollen, wie man schnell und normenkonform ein Meldesystem aufbaut, empfehle ich Ihnen,

• mich direkt zu kontaktieren. Gerne antworte ich schnell und kostenlos.
• an meinem Kompaktseminar “Medizinische Software“  am 15.5. oder am Seminar “Certified Professional for Medical Software” vom 18.-21.06. teilzunehmen.
• im Institutsclub die webbased Trainings zur nachgelagerten Phase anzusehen. Dank vierwöchiger Probemitgliedschaft geht das kostenlos und unverbindlich.

Ich gestehe, dass ich die Frage bewusst etwas unscharf stelle, v.a. mit einem nicht normierten Begriff, der “Gefährlichkeit” hantiere. Dennoch erscheint mir die Diskussion als interessant.

Die Faustregel, die mir meine benannte Stelle immer wieder nennt, lautet bei aktiven therapeutischen Produkten: Wenn das Ding den Patienten töten oder schwer verletzten kann, ist es tendenziell Klasse IIb, sonst IIa.

Das erscheint auch nachvollziehbar, wenn man sich das entsprechende MED-DEV Dokument (MED DEV 2.4/1) durchliest:

Sobald die Sache “in a potentially hazordous way” geschieht, sind wir bei IIb.

Soweit so gut. Aber wie sieht es beispielsweise mit einer stand-alone Software für die Medikamententherapie aus? Also einer Software, die Kontraindikationen, Wechselwirkungen oder Dosen z.B. auf Basis des Körpergewichts oder anderer individueller Patientenmerkmale wie einer Diagnose berechnet?

Keine der oben genannten Regeln greift, so dass wir mit Regel 12 enden: Klasse I. Obwohl wir uns alle über die potenziellen Folgen eines falschen Medikaments oder einer falschen Dosierung im Klaren sind.

Was meinen Sie?

Eine Konferenz, extra für uns Entwickler medizinischer Software? Ja, so ist es.

Neben der MedConf geht auch die MED.Software an den Start. Ganz überrascht bin ich darüber natürlich nicht, denn mein Partner Sven Wittorf ist der Tagungsleiter.

Er hat das Programm entlang des Lebenszyklus medizinischer Software aufgebaut:

Tag 1

• SESSION 1: Software: Medizinprodukt ja oder nein?
• SESSION 2: Von der Idee zum Projekt: Ableitung der Anforderungen an Software, Engineering und Risikomanagement
• SESSION 3: Konstruktiver Entwicklungsprozess: Architektur, Rückverfolgbarkeit, Prozessaktivitäten

Tag 2

• SESSION 4: Validieren und Testen medizinischer Software
• SESSION 5: Inverkehrbringen: Dokumentation, Klinische Bewertung, Einbindung
• SESSION 6: Marktbeobachtung & Betrieb: Vernetzung von Systemen

Das hört sich doch spannend an, oder? Sehen wir uns dort?

Mehr Informationen finden Sie übrigens unter www.medsoftware-tagung.de.

In einem meiner letzten Blogbeiträge habe ich mich verwundert darüber gezeigt, wie viele Firmen überrascht erscheinen, dass die Ãœbergangsfrist für “2nd edition” der IEC 60601-1 in wenigen Wochen abläuft.

Während einige nun eifrig dabei sind, die Deltas zu identifizieren und zu versuchen, diese umzusetzen, liegen die Hürden für andere Firmen etwas höher: Sie verkaufen Produkte in Märkte, in denen die “2nd edition” weiterhin verbindlich bleibt. Eine Ãœbersicht über diese Länder finden Sie hier.

Das hatte ich nicht bedacht – die “2nd edition” ist teilweise noch Stand der Technik.

Vielen Dank für diesen Hinweis an Thomas Speck

Die Schlampereien in vielen Krankenhäusern haben Konsequenzen. Nachdem gravierende Hygienemängel auftreten, Krankenhäuser systematisch Risiken mit Medizinprodukten nicht melden und regelmäßig gegen die Medizinproduktebetreiberverordnung verstoßen, hat nun der Gesetzgeber reagiert:

Er hat das getan, was er tun kann, nämlich ein neues Gesetz, präziser eine neue Verordnung erlassen. Allgemeine Verwaltungsvorschrift zur Durchführung des Medizinproduktegesetzes (Medizinprodukte-Durchführungsvorschrift – MPGVwV).

Was bedeutet das für die Krankenhäuser (aber auch für die Hersteller)?

Die Behörden werden künftig (unangemeldete) Inspektionen durchführen und dabei (u.a.) prüfen ob die Voraussetzungen für die Inbetriebnahme, die Wartung und den Betrieb der Medizinprodukte gegeben sind.

Interessanterweise sind auch die Behörden verpflichtet, ein QM-System zu etablieren und die Sachkenntnis der beauftragten Personen sicher zu stellen.

Ich bin mal gespannt, was die Behörden konkret prüfen werden – und wie die Krankenhäuser reagieren. Am 1. Januar 2013 geht es los.

Mein Blogbeitrag neulich zu den angeblich zertifizierten Betriebssystemen (z.B. RTOS) hat doch einige Gemüter erregt.

So fragt mich ein Kunde, ob er denn einen Vorteil von solch IEC 62304 zertifizierten Systemen habe.

Wie bereits geschrieben: Zuerst glaube ich nicht, dass es überhaupt Betriebssysteme gibt, die 62304-zertifiziert sind. Das geht meines Erachtens aus mehreren Gründen nicht, die ich in meinem Blog bereits diskutiert habe.

Wenn man die Unterlagen im Sinne von Testberichten und Architektur von Hersteller dieser RTOS ausgehändigt bekäme – was ich aber nicht glaube – könnte man im Risikomanagement noch genauere Aussagen machen. Für die Zertifizierung der Medizinprodukte sind diese “Selbst-Zertifizierungen” meist nicht hilfreich:

Letztlich hat man ja keine andere Chance, als dem Hersteller zu vertrauen – oder (und das finde ich das wichtigere) die Statistik sprechen lassen. Insofern tendiere ich eher zu häufig eingesetzten Betriebssystemen als zu angeblich zertifizierten: Umso häufiger eines eingesetzt wird, je wahrscheinlicher werden Fehler gefunden und bekannt, so dass man darauf reagieren kann.

In anderen Worten: Letztlich ist die Wahrscheinlichkeit entscheidend, mit der ein Betriebssystem einen für das eigene Produkt relevanten Fehler hat. Dass sich diese Wahrscheinlichkeiten bei zertifizierten und häufig eingesetzten Produkten um Größenordnungen unterscheiden, glaube ich nicht. Und genauer als auf Größenordnungen kann man im Risikomanagement eh nicht schätzen.

Solange man nicht die komplette Dokumentation einschließlich Code des OS hat, ist und bleibt das RTOS eine SOUP.