Haben Sie die grundlegenden Anforderungen der Medizinprodukterichtlinie noch präsent? Zu diesen Anforderungen zählt auch die Reihenfolge/Priorität, mit der versucht werden soll, identifizierte Risiken zu beherrschen:
Inhärente Sicherheit anstreben
Schutzmaßnahmen implementieren
Ãœber verbleibende Risiken informieren
Falls Ihn dies und andere Forderungen nicht mehr ganz geläufig sind oder falls Ihnen gerade keine passenden Beispiele einfallen, dann melden Sie sich gleich im Institutsclub an. Dort finden Sie all dies als hochwertige Videotrainings aufbereitet (hier kostenlose vierwöchige Probemitgliedschaft beantragen).
Mit diesem Wissen ausgestattet können Sie auch folgende Meldung des BfArM einschätzen. Es geht dabei um einen Fehler bei einem Bestrahlungsgerät, bei dem “der Anzeigewert der Winkelposition des Kollimators durch den Kunden umgekehrt kalibriert werden kann.” Was die Folgen eines falsch ausgerichteten Kollimators bei einem Bestrahlungsgerät sein können, bedarf wohl keiner Erläuterung. Die Maßnahme, die der Hersteller trifft, hingegen schon:
Das soll eine Lösung für das Problem sein? Ich warte schon auf die nächste Maßnahme des Herstellers, die dann vielleicht lautet: “Weil einige Anwender die Anweisung zur Kalibrierung nicht beachteten, wird die Gebrauchsanweisung nochmals überarbeitet”.
Zugegeben, das ist etwas zynisch, aber Probleme mit der Gebrauchstauglichkeit löst man nicht in Referenzhandbüchern oder Gebrauchsanweisungen. Teilnehmer des Seminars “Usability, Requirements und IEC 62366″ wissen das. Sie wissen übrigens auch, wie man solche Probleme von vornhinein hätte vermeiden können…
Mir geht es nicht darum, Fehler per se zu brandmarken. Die passieren. Aber zwei Sachen halte ich doch für bemerkens- und erwähnenswert:
Auch die deutschen Hersteller haben den Mut, Apps als Medizinprodukt in Verkehr zu bringen. Die Risikoanalyse dafür würde ich gerne sehen. Es wäre hilfreich, wenn man sich zusammenschließen könnte, um gewisse Fehlerursachen und Wahrscheinlichkeiten in größerem Kreis besprechen würde. Natürlich ist das letztliche Risiko vom einzelnen Produkt abhängig.
Viele Firmen – ich weiß nicht, ob das bei Pfizer auch so ist – nutzen für die Entwicklung mobiler Anwendungen Firmen, die auf die Entwicklung mobiler Anwendungen spezialisiert sind (das ist noch gut) – aber keinen Schimmer haben von einer MPG-konformen Softwareentwicklung (und das ist schlecht).
An einem sehr einfachen Beispiel möchte ich die These meines letzten Blogs klar machen, dass man die Probleme im Modell und nicht im Code lösen sollte.
Unsere Datenschutzbestimmungen sind streng. Nicht jeder Arzt und jede Pflegekraft darf alle Daten eines Patienten einsehen. Beispielsweise besteht keine Notwendigkeit, dass ein Krankenhausarzt, der einen Patient wegen eines Blinddarms behandelt, auch die Diagnosen aus einem zurückliegenden psychiatrischen Fall kennt.
Nun gibt es zwei Möglichkeiten, diese Forderungen zu erfüllen. Entweder Sie schreiben Code, der die Diagnosen filtert, die der jeweilige Arzt sehen darf. D.h. Sie lösen das Problem im Code mit aufwendigen Abfragen und Bedingungen. Dies wäre notwendig, wenn Sie die Diagnosen in eine 1:n Beziehung zum Patienten setzen.
Oder Sie lösen das Problem im Modell, indem die Diagnosen den Fällen zugeordnet sind:
Natürlich hat auch diese Lösung Nachteile: Wenn Sie alle Diagnosen anzeigen wollen, müssen Sie über alle Fälle iterieren. Und das wäre wieder Code.
Das ist aber ein Interessenskonflikt zwischen vollständiger Anzeige der Daten und Datenschutz, der sich nur im Modell widerspiegelt.
Kommen Sie nur nicht auf den Gedanken, ein “Best of” zu modellieren, in dem Sie in der zweiten Variante noch eine 1:n Beziehung von Patient zur Diagnose einfügen. Dann kommen Sie in die Problematik inkonsistenter “Collections”.
Wenn Sie wünschen, dass jemand Ihr Architekturdokument prüft oder Ihnen hilft, ein gutes (und IEC 62304-konformes) zu erstellen, dann wenden Sie sich an mich.
Ich habe eine harte Schule durchlaufen: Wie entscheidend die Software-Architektur für den Erfolg eines Produkts ist, musste ich gleich zweimal lernen.
Das erste Mal, als im Lauf der Jahre meine Software immer unwartbarer und undurchschaubarer wurde und jede Änderung im Code zu zumindest überraschenden Ergebnissen geführt hat. Ich glaubte, ohne explizite Architektur auszukommen. Eine teure Lehre!
Das zweite Mal hatte ich einen strengen Lehrmeister: die Software-Architekten von IBM in Rochester, MN. Ihre Botschaft war eindeutig: “Christian solve your problems in the model”. Und wenn ich mich daran nicht halten würde, würden sie die Zusammenarbeit beenden. Klare Botschaft oder?
Aber die IBM Jungs hatten Recht. Die eigentliche Entwicklung und Wertschöpfung findet beim Entwerfen der Architektur statt – und (hoffentlich) nicht beim Programmieren. Wer das nicht verstehen will, bezahlt gleich doppelt:
Er benötigt länger, denn Iterationen und Nachbesserungen gelingen in einem Dokument oder auf einem Flipchart um Größenordnungen schneller als im Code.
Eine saubere, einfach zu verstehende und konsistente Architektur ist eine zwingende Voraussetzung für eine wartbare Software. “Historisch gewachsen” zähle ich zu den Unworten in diesem Kontext.
Also, machen Sie es gleich richtig, lösen Sie Ihre “Probleme” (=> Requirements) in der Architektur und nicht während des Kodierens. Genau das verlangt auch die IEC 62304.
Sie sind unsicher wie das geht? Sie benötigen jemanden, der Sie dabei antreibt oder Ihnen bei Vorgesetzten Gehör schafft?
Wie heise Online bzw. Technology Review berichten, setzen Forscher in Chicago eine virtuelle Krankenschwester überraschend erfolgreich ein, um Patienten zu informieren und zu betreuen. In der nächsten Version sollen ihr die Patienten ihre Schmerzen melden können.
(Bildquelle: heise Online)
Was meinen Sie, ist die Software ein Medizinprodukt? Dient sie dem Ãœberwachen und Behandeln von Krankheiten?
Wahrscheinlich noch nicht. Aber die “Konvergenz” von Mensch und Maschine lässt mich einige spannnende Diskussionen zur Klassifzierung von Software als Medizinprodukt erwarten.
Haben Sie schon einmal die Forderungen der FDA zum Qualitätsmanagementsystem, konkret den 21 CFR part 820 gelesen? Ich gestehe, das ist nicht jedermans Sache, sich durch diesen Text zu kämpfen.
Weil dieses Gesetz aber wichtig ist, möchte ich Ihnen helfen zu verstehen, ob Sie es befolgen müssen und falls ja wie.
Am einfachsten Sie sehen sich das neuste webbased Training dazu an. Ich hoffe, dass es mir wieder gelungen ist, den Stoff lebendig und interessant zu vermitteln und auf das Wesentliche zu konzentrieren.
Sie wissen ja, dass Sie sich über eine Probemitgliedschaft vier Wochen kostenlos Zugang zum Institutsclub verschaffen können. Im Institutsclub finden Sie über 50 weitere webbased Trainings, darunter auch weitere zur FDA.
Für die anderen habe ich den 21 CFR part 820 noch als interaktive Mindmap umgestaltet. So orientiert man sich ein wenig schneller als im originalen Fließtext.
Damit ist zumindest für den Laborbereich alles geregelt, dachte ich – bis wir diese Woche das Glück hatten, den IT-Leiter des MVZ Labor Dr. Gärtner am Institut begrüßen zu dürfen.
Was sich in der Theorie gut anhört, ist in der Praxis oft so nicht umsetzbar. Beispielsweise die Geschwindigkeit, mit der das Regenstrief Institut neue Codes vergibt und diese Änderungen kommuniziert werden. Man spricht hier von Monaten. Für ein großes Facharztlabor für klinische Chemie und Mikrobiologie, das wöchentlich neue Messverfahren anbietet, ist das eine nicht praktikable Zeitspanne. Doch damit nicht genug.
Auch die Art, wie die einzelnen Laborwerte modelliert sind, stellt ein Problem dar. Beispielsweise gibt es Dutzende Hämoglobin-Werte. Das ergibt auf den ersten Blick Sinn, denn ein Hämoglobin im Blut ist nun mal nicht das gleiche wie ein Hämoglobin im Urin. Und der Hämoglobin-Wert, der mit einem Absorptionsmessverfahren gemessen wird, ist nicht notwendigerweise gleich dem Hämoglobin-Wert, der mit einem Zählverfahren bestimmt wurde.
Dieses „kartesische Ausmultiplizieren“ der Achsen von LOINC führt aber zu einer nicht mehr überblickbaren Anzahl an Werten. 10.000e umfasst der Katalog. Man bräuchte ein Datenmodell für die Laborwerte, bei dem das Verfahren eine Eigenschaft des jeweiligen Werts ist. Wie komplex diese Datenpflege ist, wurde mir erst klar, als ich einen Einblick in die hochkomplexe Logik – das Labor spricht von der Präanalytik – eines Clients zum Beauftragen von Laborwerten bekam. Die Dinge sind meist nicht so trivial, wie sie auf den ersten Blick erscheinen.
Ich bin Herrn Ganguly, dem IT-Leiter des MVZ Labor Dr. Gärtner, jedenfalls sehr dankbar für dieses neue Verständnis. Zum Glück gibt es die Kamingespräche am Institut.
Wissen ist die eine Sache, Können eine andere. Genau deshalb arbeiten wir an einem großen Trainingssystem, auf dem Krankenhaus-Informationssysteme, Laborinformationssysteme, Integrationsserver u.v.m installiert sind.
Wir nennen dieses Trainingssystem den “Spielplatz”.
Seit dieser Woche ist der Spielplatz um eine entscheidende Komponente reicher geworden: Wir sind stolzer “Besitzer” des Krankenhaus-Informationssystem MCC von Meierhofer. Jetzt können wir noch besser Patientenpfade simulieren, verstehen, wie eine OP-Planung funktioniert und die Integration mit anderen Systemen üben.
Möchten Sie die Studierenden am Institut mal einen Tag begleiten? Einen Einblick bekommen, wie das berufsbegleitende Studium “IT im Gesundheitswesen” abläuft? Verstehen, wie auch Sie und Ihre berufliche Entwicklung davon profitieren können? Dann melden Sie sich doch einfach bei mir und vereinbaren Sie einen Termin für einen Schnuppertag.
Dass am Institut nur höchstkarätige Dozenten wie Jens Naumann auftreten, wissen Sie wahrscheinlich. Jens Naumann war lange Zeit der Vorsitzende des Verbands der IT-Hersteller für das Gesundheitswesen. Er leitet auch die medatixx-Gruppe, deren Arztpraxissysteme wie DocExpert in 10.000en (keine Übertreibung) Praxen installiert sind.
Was Sie vielleicht nicht kennen, ist eine unserer Lernmethoden:
Am Ende jedes Studientags fassen die Teilnehmer das Gelernte zusammen, in dem sie 10-15 Prüfungsfragen formulieren. Diese Fragen beantworten die Referenten im Anschluss direkt – auf MP3. Diese Aufzeichnungen dienen dann dem Lernen, sei es bei der Fahrt zur Arbeit oder beim Joggen. Dadurch, dass wir die Fragen selbst formulieren und von unseren Dozenten direkt beantworten lassen, haben wir einen ganz persönlichen Bezug dazu. Und genau das schafft den emotionalen Anker, der beim Lernen so wunderbar hilft. Das ist modernes Lernen.
Wollen Sie mal mit dabei sein? Melden Sie sich einfach bei mir, um einen Termin für einen Schnuppertag zu vereinbaren. Unsere Dozenten wie Jens Naumann sind ein Erlebnis!
Wer behauptet, es gäbe keine attraktiven Stellen mehr in Deutschland? Ich habe gleich vier Stück anzubieten – vier Professoren für unseren neuen Studiengang Gesundheitsinformatik:
Professur für Gesundheitsinformatik, Schwerpunkt Softwareentwicklung (der Bewerber sollte so richtig was von Softwareentwicklung medizinischer Systeme verstehen)
Professur für Gesundheitsinformatik, Schwerpunkt Gesundheitsökonomie (der Bewerber sollte das Gesundheitswesen kennen mit seinen ökonmischen Besonderheiten, den Prozessen z.B. im Krankenhaus usw. Er/sie könnte ggf. ein Arzt mit MBA sein)
Professur für Gesundheitsinformatik, Schwerpunkt IT-Management (der Bewerber sollte aus eigener Erfahrung wissen, wie man IT-Infrastrukturen im Gesundheitswesen betreibt)
