E-Health & Karriere

Im Januar soll es Orte in Deutschland mit nur vier Sonnenstunden gegeben haben. Ab in den Süden wird sich zurzeit mancher wünschen. Genau das werde ich nächste Woche tun. Allerdings nicht der Sonne wegen, sondern um unser Projekt „Healthcare IT for Africa“ voranzutreiben. Mit Thomas Erkert werde ich über eine Woche in Ghana arbeiten.

Daher bin ich vom 11.-18. Februar nicht erreichbar. Bitte ersparen Sie sich den Frust, und versuchen Sie nicht, mich in dieser Zeit zu kontaktieren. Weder per Telefon noch per E-Mail. In dieser Zeit empfangene E-Mails werde ich auch nicht abarbeiten können. Ab dem 19.02. bin ich wieder ganz für Sie da.

Meine Gelbfieber- und Hepatitisimpfungen habe ich bereits, Montag folgt dann die Malariaprophylaxe und ab Mittwochabend bin ich unterwegs. Ich halte Sie auf dem Laufenden…

Beste Grüße, Christian Johner

Einer meiner Lieblingskunden kam auf die Idee, seine Software im Feldtest zu validieren, um so die entsprechenden gesetzlichen Forderungen nach Validierung zu erfüllen. Dabei hätte er sich um ein Haar strafbar gemacht.
Doch wie kann man (medizinische) Software validieren? Schließlich fordern das alle relevanten regulatorischen Dokumente wie die Medizinprodukterichtlinie (93/42/EG), das MPG, die ISO 13485, die IES 60601-1 und die IEC 62366 (Usability). Lies den Rest des Artikels »

Mein letzter Beitrag war gerade mal 3h online, als ich ihn wieder entfernen musste. Darin hatte ich über das aktuelle Thema „Steuer-CD“ geschrieben und erklärt, wie DLP (Data Loss Prevention) funktioniert. Die Schilderung, wer mit welcher Bank welchen Ansatz fährt und welches Produkt wählt, war aber wohl zu präzise.

Interessanterweise haben nicht die Kliniken mit dem Artikel Bauchweh gehabt, sondern die Banken. Die Priorität, die viele Krankenhäuser und Klinikketten dem Thema DLP zuweisen, erscheint mir aber als das „heißere Eisen“. Die erste Erpressung durch die Veröffentlichung von Patientendaten steht uns offensichtlich erst noch bevor…

Mit besorgten Grüßen, Christian Johner

Danke für Ihre Kommentare zum letzten Blog! Sie haben völlig Recht, dass man bei Testwerkzeugen unterscheiden sollte, ob diese speziell entwickelt wurden oder ob es sich um “bewährte” Produkte handelt. Letztere hatte ich gemeint. Bei eigens entwickelter oder/und angepasster Software (“Customizing”) – und dazu zählen auch Testskipts – muss von der gleichen Wahrscheinlichkeit ausgegangen werden, dass die Testsoftware einen Fehler enthält, wie beim eigentlichen Produkt. Genau das sollte bei der Priorisierung der Aufwände für die Validierung der Testwerkzeuge berücksichtigt werden.

Einer meiner geschätzten Kunden hat mich gefragt, ob man Testwerkzeuge (z.B. JUnit, Winrunner, qfTest) und ALM-Tools (z.B. MedPack, JIRA, microTool, Visual Studio Team Foundation) validieren bzw. verifizieren muss. Und falls die Antwort ja wäre, müsste man dann die zu dieser Validierung bzw. Verifizierung eingesetzten Werkzeuge auch wieder prüfen? Da würde sich ja ein Teufelskreis auftun. Lies den Rest des Artikels »

Die Idee, die mein Beratungskunde hat, ist eigentlich nicht schlecht: Man klassifiziert die Software nach Sicherheitsklasse A und schon muss man die Software-Entwicklung kaum noch dokumentieren.
In der Tat, der Dokumentationsumfang kann stark an die Sicherheitsklasse angepasst werden. Die IEC 62304, die Norm zum Lebenszyklus medizinischer Software, kennt drei Klassen:

• Klasse A: Keine Verletzung oder Schädigung der Gesundheit ist möglich.
• Klasse B: Keine schwere Verletzung ist möglich.
• Klasse C: Tod oder schwere Verletzung ist möglich.

Abhängig von der Gefährdungsklasse müssen bestimmte Aktivitäten nicht dokumentiert werden:

Die Versuchung, die Software als Klasse A zu definieren, ist also sehr hoch. Doch ist das erlaubt? Lies den Rest des Artikels »

Warnung: Dieser Beitrag richtet sich nur an Personen, die für die Entwicklung oder Qualitätssicherung medizinischer Software verantwortlich sind

Irrtum, anomaler Gebrauch, Aufmerksamkeitsfehler, vernünftigerweise vorhersagbarer Erinnerungsfehler, vorhersagbarer Missbrauch. Die Liste möglicher (Fehl-) Handlungen, welche die Norm zum Risikomanagement (ISO 14971) und die Norm zur Gebrauchstauglichkeit (IEC 62366) kennen ist lang. Obwohl beide Normen aufs engste miteinander verzahnt sind, nutzen sie doch unterschiedliche Begriffe.

Abb.: Taxonomie der Handlungen nach IEC 62366 (zum Vergrößern klicken)

Die IEC 62366 unterscheidet vernünftigerweise vorhersagbaren und vernünftigerweise nicht vorhersagbaren Gebrauch. Der normale Gebrauch schließt Nutzungsfehler explizit mit ein. Doch was ist mit dem vorhersehbaren Missbrauch, der laut ISO 14971 bereits in der Zweckbestimmung zu dokumentieren ist (ISO 14971 Kapitel 4.2)? Die IEC 62366 berücksichtigt diesen vorhersagbaren Missbrauch nicht, geht auch im entsprechenden Kapitel zur Spezifikation der Anwendung (5.1) nicht darauf ein. Wie passt das zusammen? Lies den Rest des Artikels »

und damit beinahe den Betrieb eines Provinzkrankenhauses lahm.“ So beginnt die Fallstudie im Havard Business Manager, die Sie aktuell in der Online-Ausgabe des Manager Magazins nachlesen können. In meinem Blog im Oktober hatte ich auf solch ein Szenario schon hingewiesen. Lies den Rest des Artikels »

Der GAU ist eingetreten: Ihr Auditor erklärt Ihr Medizinprodukt als nicht konform mit den grundlegenden Anforderungen, konkret mit den Forderungen nach Gebrauchstauglichkeit. Der Schaden für Sie, Ihr Entwicklungsteam und Ihre Qualitätssicherung ist riesig, die finanziellen Folgen unabsehbar, die Rufschädigung immens. Dabei hätten Sie dieses Desaster vermeiden können.

Lies den Rest des Artikels »

Dass Software – auch stand-alone – ein Medizinprodukt sein kann, macht das überarbeite Medizinproduktegesetz nochmals unmissverständlich klar. Dabei kann Software alleine wenig ausrichten. Ohne Hardware ist sie nicht einmal lauffähig. Zudem nutzt man die Software sehr oft, um ein Medizingerät anzusteuern oder von diesem Daten zu holen.

So stellt sich vielen Herstellern die Frage, was nun das Medizinprodukt ist. Die Software alleine? Die Software und der PC, auf dem sie läuft? Oder gar die Software mit dem PC und einem anderen Medizingerät? Müssen gar die Netzwerkkomponenten wie Router, welche die Software mit dem anderen Medizingerät verbinden, selbst als Medizinprodukt klassifiziert werden?

Lies den Rest des Artikels »