wird sich der Mitarbeiter der Uniklinik Freiburg denken. Stimmt. Kleine Änderung, große Wirkung. Und die besteht darin, dass auf einmal streng vertrauliche Laborwerte wildfremder Menschen im Briefkasten von Thomas S., einem Patienten dieser Uniklinik, landen.

Wenn die privatärztliche Verrechnungsstelle nicht so ungeschickt auf die Beschwerde von Thomas S. reagiert und dieser daraufhin nicht den Landesdatenschutzbeauftragten eingeschaltet hätte, wäre der Fall wohl nie an die Öffentlichkeit, sprich in die Badische Zeitung gelangt (hier geht’s zum Artikel).

Der Programmierfehler stört mich nicht. Ich frage mich vielmehr:

• Wie kann es sein, dass eine einzelne Person (ohne Code Review) solche Änderungen machen darf?
• Von wie vielen dieser Fehler erfahren wir nicht?
• Welche dieser Fehler führen nicht nur zu einer Verletzung des Datenschutzes sondern zur Verletzung oder dem Tod von Patienten?

Zugegeben, die Systeme und ihre Vernetzung sind so komplex geworden, dass man sie kaum noch durchschauen und vollständig beherrschen kann. Aber ein paar “Best Practices” könnte man schon einhalten.

Ãœbrigens: Software-Entwickler können diese Best-Practices bei mir lernen. Beispielsweise im Rahmen der Ausbildung zum “Certified Professional for Medical Software”.

Danke SM für den Lesetipp

Was schief gehen kann, geht schief. Das ist eine Binsenweisheit. Was mir aber einer meiner Master-Studenten am Institut über die KIS-Migration in einer Schwesterklinik erzählt, überrascht dann doch:

Die Kurzzusammenfassung wäre: Das Projekt war kein voller Erfolg. Die etwas längere Version ist:

• Die Phase Anforderungsanalyse hat man großzügig übersprungen.
• Man baute kein ganzheitliches Projektmanagement auf.
• Kommunikationswege waren nicht geregelt.
• Man hoffe, ein Projektplanungswerkzeug würde ausreichen. Dieses Werkzeug nutzte nur niemand.
• Die Ärzte als Interessensgruppe “vergaß” man.
• Zusätzliche Ressourcen für dieses Projekt wurden keine bereitgestellt. Man lastete es den Mitarbeitern einfach noch zusätzlich auf.
• Die Person, die für die Schulung verantwortlich gewesen wäre, wechselte in ein anderes Projekt.
• Auch standen die Lieferanten bereits unmittelbar nach dem Start des Projekts nicht mehr zur Verfügung.
• Die Anpassung der Software an die Gegebenheiten der Klinik erfolgten ebenso wenig wie die Bereitstellung der dazu notwendigen Hardware.

Ich bin sicher: Hätte man diese Liste der Versäumnisse und Fehler den Beteiligten vor dem Projekt gezeigt, hätten sie es ausgeschlossen, dass ihnen so etwas passieren kann. Aber es passiert. In dieser Klinik und vielen anderen. Doch woran liegt das?

• Ignoranz?
• Unwichtigkeit des Projekts?
• Mangelndes Fachwissen und fehlende Kompetenzen?

Zumindest im letzteren Fall hätte das berufsbegleitende Masterstudium “IT im Gesundheitswesen” helfen können. Denn hier stehen Themen auf dem Stundenplan wie

• Kommunikation, Verhandlungsführung
• Projektmanagement
• Anforderungsanalyse/Requirements Engineering
• Rechenzentrumsbetrieb
• usw.

Ein Studium wäre wohl um Größenordnungen günstiger gewesen als die Scherben dieses Projekts zu beseitigen. Vom Frust, den man sich hätte sparen können, ganz zu schweigen.

Interessiert? Dann melden Sie sich doch einfach bei mir.

“Lernen Sie bei IT-Problem souverän zu agieren! Erweitern Sie Ihre Karriereoptionen!”

Die beiden Masterstudiengänge, der MSc und der MBA, sind und bleiben das Premiumprodukt des Instituts.

Aber manche wünschen sich etwas weniger als ein ganzes Studium, z.B. weil

• die eigenen Ziel – zumindest die Studieninhalte betreffend – nicht so hoch sind, als dass es eines Studiums bedürfte,
• die finanzielle Mittel noch nicht ausreichen,
• man sich die Zeit dafür nicht nehmen will oder
• das Vorwissen noch nicht ausreichend ist.

Falls Sie – besonders als Pflegekraft – sich für die IT im Gesundheitswesen interessieren, beispielsweise weil Sie

• Ihre pflegerische Kompetenz in IT-Projekte einbringen wollen,
• Ihre Karriere- und Berufsoptionen über die Pflege hinaus ausdehnen möchten, ohne die Pflege ganz verlassen zu müssen,
• bei IT-Problemen souverän reagieren und Ihre Kollegen dabei unterstützen wollen

empfehle ich Ihnen die Seminarreihe Pflegeinformatik.

Besuchen Sie die Webseite zu dieser Seminarreihe und fordern Sie weitere Informationen bei uns an!

Bei den Masterstudiengänge am Institut pflegen wir einen schönen Brauch: Die Kamingespräche, die zweimal wöchentlich stattfinden.

Dieses Mal wählen wir ein Thema, das auf den ersten Blick eher theoretisch anmutet: Die Modellierung klinischer Informationssysteme. Unser Referent arbeitet an der Uniklinik Leipzig, das Werkzeug, das er uns vorstellt, ist der 3LGM Baukasten.

Dass es sich hier um mehr als um eine Spielerei gelangweilter Wissenschaftler handelt, wird klar, als wir verstehen, dass die Leipziger ihre kompletten Informationssysteme damit dokumentieren. Diese Form der Dokumentation ist aber etwas klüger als die auf Papier:

• Schnell kann man interessante Ausschnitte auswählen und auf Detailebenen zoomen.
• Das Zusammenspiel der Systeme erlaubt vorherzusagen, wer vom Ausfall einer Komponente betroffen ist. Das dürfte sich nicht nur im Rahmen eines Risikomanagements nach IEC 80001/ISO 14971 als sehr hilfreich erweisen.
• Für jede Interessengruppe findet sich die angemesse Beschreibung: Für den Manager, dem der Ãœberblick genügt; für den Arzt, der verstehen will, wo welche Daten verarbeitet werden; für den IT-Mitarbeiter, der weiß, welche Hardwarekomponente mit welchem Software-System zusammenspielt.

Ein eindrucksvoller Abend – wie so oft am Institut. Studieren Sie doch einfach mal einen Tag mit, lernen Sie, tauschen Sie sich mit Studierenden aus, und erleben Sie, dass nicht nur die Abende einen Besuch wert sind.

Melden Sie bei mir, ich freue mich darauf.

Im Sammeln von (medizinischen) Daten sind wir ja inzwischen Weltklasse. Mit der Auswertung hapert es hingegen noch. Bin ich zu negativ, wenn ich unke, dass die meisten Auswertungen und Verarbeitungsschritte etwas mit der Abrechnung zu tun haben?

Dabei stecken in den Daten noch ungeahnte Mengen an Wissen. Wissen, das uns helfen könnte, Behandlungen patientenspezifischer und damit wirkungsvoller, schneller, preisgünstiger und mit weniger Nebenwirkungen durchzuführen.

Im Rahmen des MBA-Studiengangs haben wir gelernt, mit welchen Methoden diese Wissensschätze gehoben werden können. Clustering, Support Vector Machines, automatisch generierte Entscheidungsbäume und viele weitere Verfahren hat uns unser Dozent Manuel Stritt vorgestellt.

Hier gibt es noch viel Aufholbedarf. Doch die Mühen werden belohnt. Und nicht nur mit schönen Visualisierungen (hier des Clusterings):

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.

Wer die webbased Trainings im Institutsclub verfolgt (hier kostenlose und unverbindliche Probemitgliedschaft beantragen) weiß, dass LOINC das System ist, um Laborwerte (und viel mehr) zu kodieren.

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.

Das Anschreiben sagt, dass ich mich darüber freuen solle, dass mein Patent nun auch in Japan gelten würde.

Eigentlich eine super Sache. Nur mit dem Dokumentenreview tue ich mir schwer:

Halten Sie Unittests für ein wirkungsvolles Instrument, um die Qualität Ihrer Software zu sichern? Halten Sie sie für eine Best Practice? Ich hoffe inständig, dass Sie als Leser meines Blogs diese Fragen eindeutig mit “ja” beantworten.

Und was sagt die IEC 62304 zu diesem Thema?

Für Software(komponenten) der Klasse A verlangt sie überhaupt keine Verifikation.

Für Software(komponenten) der Klasse B schlägt Sie vor,

• die Umsetzung der Risikokontrollmaßnahmen zu prüfen,
• zu prüfen, ob man die Software so entwickelt hat, wie das im Design geplant wurde und
• zu prüfen, ob Kodierrichtlinien eingehalten wurden.

Wie würden Sie all dies tun? Durch ein Code-Review bzw. mit Werkzeugen zur statischen Code-Analyse.

In anderen Worten: Für Software(komponenten) der Sicherheitsklasse B müssen Sie den Code nicht einmal ausführen. Unittests sind also für diese Sicherheitsklasse nicht einmal vorgeschrieben.

Und genau darauf berufen sich manche Hersteller. Das erinnert mich ein wenig an:

Die IEC 62304 ist schließlich eine Norm, die Minimalanforderungen an die Softwareentwicklung nennt – und keine Best Practicse Norm!

Es bereitet mir wirklich Freude und macht mich stolz: Auch bei der nächsten conhIT darf ich in meiner Rolle als “Präsident der Akademie” (hört sich cool an, oder?) zum Gelingen der Akademie beitragen. Konkret

• war ich bereits an der Auswahl der für die Praxis relevanten Themen beteiligt,
• helfe bei der Suche nach den besten Referenten
• und unterstütze diese beim Formulieren von Lernzielen sowie
• beim Erstellen und Umsetzen eines mediendidaktischen Fahrplans.

• Im nächsten Jahr werden wir mit neuen Gesichtern überraschen – und nicht den “üblichen Verdächtigen”.
• Wir haben Themen aufgenommen, die bisher eindeutig zu kurz kamen.
• Die Lernziele bestehen künftig weniger im Wissen, sondern mehr im Können.
• Bereits während der Vorbereitungsphase haben wir mehrere Qualitätssicherungsstufen eingebaut.