“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!

Morgen ist es soweit, das erste CPMS-Seminar startet. Vier Tage werden Matthias, Sven und ich die Teilnehmer auf die Zertifizierungsprüfung vorbereiten.

Die Teilnehmer werden mit diesem Zertifikat Fachwissen bescheinigt bekommen über

• die regulatorischen Grundlagen,
• die normenkonforme Software-Entwicklung und IEC 62304,
• das Risikomanagement nach ISO 14971,
• das Usability Engineering nach IEC 62366,
• die Medizinische Informatik und
• Querschnittsthemen wie QM und Dokumentenmanagement.

Natürlich sind wir riesig gespannt, wir freuen uns darüber, dass die Initiative “Certified Professional for Medical Software” das alles geleistet hat:

• Einen Verein gegründet.
• Curricula geschrieben.
• Prüfungsfragen entwickelt.
• Akkreditierungsregeln erarbeitet.
• Trainingsanbieter akkreditiert. Das ist Institut ist übrigens der erste!
• Die erste Prüfungsorganisation akkreditiert, die am Freitag die Prüfung abnehmen wird.

Kommen Sie zu den CPMS-Seminaren am Institut, werden Sie Mitglied unseres Vereins.

Eins der wichtigsten Mittel, um die Fehlerrate in meinem Team signifikant einbrechen zu lassen, waren Code-Reviews. Und zwar konsequent bei allem Code.

Das klappt aber nur, wenn man das richtig macht und ein paar Regeln einhält:

1. Ein Code-Review sollte nicht länger als 30 Minuten dauern.
2. Ein Code-Review sollte den Code einschließlich der Einhaltung vorher (automatisch) bestimmter Metriken und Kodierrichtlinien prüfen.
3. Ein Code-Review sollte den Test-Code (einschließlich Code-Coverage) berücksichtigen.
4. Ein Code-Review sollte reverse durchgeführt werden. Was heißt das?

Beim Reverse-Code-Review erklärt nicht der Autor dem Reviewer seinen Code, sondern umgekehrt. Der Reviewer erklärt, was er zu verstehen glaubt. Das hat große Vorteile:

1. Der Reviewer ist konzentriert, denn er muss den Code ja dem Autor erklären.
2. Der Autor ist die angebliche Begriffsstutzigkeit des Reviewers bald leid und schreibt künftig Code, den sogar der Reviewer versteht. Das führt zu verständlichem und damit wartbarem Code.
3. Der Chef kann sicher sein, dass es eine zweite Person gibt, die den Code auch versteht. Das reduziert die Abhängigkeit von einem Entwickler.

Vier Augen sehen mehr als zwei. Machen auch Sie Code-Reviews. Am besten reverse!

PS: Mit Reviews können Sie Konformität mit der IEC 62304 Kapitel 5.5 erreichen.

PPS: Wenn Sie noch mehr Tipps zur Entwicklung medizinischer Software wünschen, dann treten Sie doch dem Institutsclub bei. Nutzen Sie die kostenlose vierwöchige und unverbindliche (und sich nicht selbständig verlängernde) Probemitgliedschaft!

Heute bin ich auf eine Grafik der Barmer gestoßen, die der Bundesverband der medizintechnischen Industrie verschickt hat. Sie gibt die Wahrscheinlichkeit an, im Lauf des Lebens pflegebedürftig zu werden:

Meine statistischen Chancen stehen bei 50 Prozent. Tendenz stark steigend. Wenn ich eine Frau wäre, läge die Wahrscheinlichkeit bei 72%. Prozent stark steigend.

Wir reden alle vom demografischen Wandel. Immer und immer wieder. Was das aber bedeutet, werden wir wohl erst so richtig verstehen, wenn wir uns im hohen Alter niemanden leisten können, der uns pflegt. Weil es einfach nicht genügend junge Menschen gäbe, dies zu tun.

Ambient assisted living und viele weitere Schlagworte waren eine Zeit lang ziemlich hype. Jetzt ist das wieder ein wenig in der Versenkung verschwunden. Um hoffentlich rechtzeitig den Weg in die Praxis zu finden, bevor wir keine Alternativen dazu haben.

Wenn man in einer Schulung über Softwareentwicklung etwas gelehrt bekommt, ist es das V-Modell. Immer und immer wieder. Es ist auch ein wunderbares Modell, um vieles zu erklären.

Doch wie versteht die IEC 60601-1 dieses V-Modell?

Quelle: IEC 60601-1 bzw. IEC 62304.

Laut dieser Norm (siehe Abbildung) werden aus Anwenderbedürfnissen Anforderungen an ein programmierbares elektrisches medizinisches System, kurz PEMS, abgeleitet. Also Systemanforderungen.

Das erste, was ich mich frage ist, was die Norm unter Anwenderbedürfnissen versteht. Hört sich irgendwie nach Toilette an. Es handelt sich um einen nicht definierten Begriff. Wahrscheinlich verstanden die Autoren darunter ein nicht näher verstandenes Mischmasch aus Erfordernissen, Wünschen, Nutzungsanforderungen und direkt formulierten Systemanforderungen. Wer so unpräzise mit den Begrifflichkeiten umgeht, wird nachher auch unpräzise Ergebnisse erzielen.

Wohin diese mangelnde Präzision führt, erkennen Sie selbst: Die Norm glaubt die Erfüllung von PEMS-Anforderungen, also Systemanforderungen, validieren zu können. Systemanforderungen kann man (im Systemtest) verifizieren, aber nicht validieren. Validieren kann man definitionsgemäß hingegen Nutzungsanforderungen. Doch die tauchen wie eben diskutiert überhaupt nicht in dem Bild auf, sondern gehen im Nebel der Anwenderbedürfnisse unter.

Wem diese Unterschiede nicht gleich einleuchten, dem empfehle ich das (zumindest für mich) wegweisende Seminar von Thomas Geis. Es heißt “Usability, Requirements und IEC 62366″. Thomas Geis ist sehr streng mit den Begrifflichkeiten. Und das macht seine Ergebnisse so sensationell. Wenn Sie eine Innovationsmaschine erleben wollen, besuchen Sie das Seminar – oder buchen Sie ihn am besten gleich. Mach ich auch so…

Die ISO 9126 mag ich eigentlich. Denn Sie dient als sehr gute Checkliste. Sowohl beim Schreiben der funktionalen Spezifikation (oft Software Requirements Specification genannt) also auch beim Spezifizieren von Testfällen. Die meisten stürzen sich nämlich nur auf die Funktionalität.

Dass es mehr Aspekte der Softwarequalität gibt, hat übrigens auch die IEC 62304 erkannt. Sie übernimmt beispielsweise im Kapitel 5.1. mit den Softwareanforderungen ziemlich dreist die Inhalte der ISO 9126. Zugegeben, sie verweist zumindest auf die ISO 9126, es ist also kein echtes Guttenbergen.

Nur mit einer Sache tue ich mir schwer: Dem Ast mit der Gebrauchstauglichkeit bzw. Benutzbarkeit:

Die ISO 9241 oder in ähnlicher Weise die IEC 62366 definiert den Begriff Gebrauchstauglichkeit als:

“Das Ausmaß, in dem ein interaktives System durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.”

Nun wird man sich fragen, wie man mit einem funktional fehlerhaften System seine Ziele überhaupt erreichen kann. Das geht natürlich nicht.

Würde das bedeuten, dass die Funktionalität ein Unteraspekt der Gebrauchstauglichkeit ist? Die ISO 9126 also falsch ist? Im Sinn der ISO 9241 schon, nicht aber im Sinn der ISO 9126. Denn sie meint eigentlich gar nicht die Gebrauchstauglichkeit, sondern nur die Benutzbarkeit. Dieser Ast zielt also auf die Effizienz und nicht die Effektivität ab. Gebrauchstauglichkeit umfasst alles.

Hört sich ziemlich kleinlich an, was ich schreibe? Was soll’s, die ISO 9126 ist sowieso dem Tod geweiht. Ihr Nachfolger, die ISO 25010, ist bereits in Kraft.

Wie die die Sache sieht, verrate ich in einem anderen Blogbeitrag.

“Kann ich Ihr Architekturdokument lesen?” frage ich den Entwicklungsleiter. Ich soll seine Firma dabei unterstützen, durchs nächste Audit zu kommen. “Damit sind wir noch nicht fertig” lautet seine Antwort.

Seltsam denke ich, der Code ist schon weitgehend implementiert. Als ob er meine Gedanken lesen könnte, ergänzt der Entwicklungsleiter: “Wir schreiben die Architektur sozusagen parallel mit dem Code”.

Aha. Das ist also so, als würde man den Bauplan für das Eigenheim mit jedem Stockwerk mitentwickeln. Am besten, wenn das jeweilige Stockwerk fertig gestellt ist.

“Wie machen Sie das mit der Hardware?” provoziere ich mit einem Augenzwinkern, “entwerfen Sie die Schaltpläne auch während des Bestückens der Platine?” Ertappt grinst der Entwicklungsleiter.

Dies Schizophrenie begegnet mir aber fast täglich.

<== wir kennen uns nicht ==>

Es ist mir unbegreiflich, weshalb man das, was man bei der Hardwareentwicklung als richtig und vernünftig erachtet, bei der Softwareentwicklung so konsequent ignoriert. Nur weil das Ausbessern der Fehler scheinbar schneller möglich ist.

Wohlgemerkt “scheinbar”. Denn Denken durch “trail & error” zu ersetzen, spart zwar das Denken, aber weder Zeit noch Geld”.

PS: Habe ich erwähnt, dass die IEC 62304 die Architektur auch nicht als rückwirkende Beschreibung des angerichteten Chaos versteht?

PPS: Habe ich erwähnt, dass Sie beim Seminar “Certified Professional for Medical Software” lernen, wie man das richtig macht?

Lächerliche 1-2 Prozent geben deutsche Krankenhäuser für die IT aus. Zum Vergleich: In den USA sind das etwa 7%, so die Zahlen, die die Zeitschrift kma in ihrer Novemberausgabe zitiert (S. 16ff KB: Danke für den Lesetipp).

Offensichtlich ist man sogar stolz auf diese niedrigen Ausgaben. Angeblich hat die Aussage, dass die IT nicht zur Kernkompetenz von Krankenhäuser zählen würde, Beifall bei einer Versammlung von Krankenhausdirektoren bekommen.

Wer mit diesem Verständnis für die IT agiert, tut vielleicht sogar gut daran, nicht mehr dafür auszugeben. Denn das Geld würde wahrscheinlich wirkungslos verbrannt werden.

Das Problem ist also nicht das Budget selbst, sondern die Leute, die darüber entscheiden, und die Leute, die es ausgeben – die Krankenhaus-IT-Leiter. Ja, ich nenne das ein Problem. Denn an vielen Krankenhaus-IT-Leitern sparen die Chefs ebenfalls. Und auch hier gilt “you get what you pay for”.

Was kann man als Krankenhaus IT-ler machen? Letzlich bleibt der Wechsel zu einem anderen Arbeitgeber, sei es zu einer anderen Klinik oder in die Industrie. Das bedingt natürlich konkretes Fachwissen und eine Methodenkompetenz. Aber wo man all dies erwirbt, wissen Sie ja.

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.

Vielleicht klingt es nach Eigenwerbung, wenn ich sage, dass die Rückmeldungen zu unserem Buch “Basiswissen medizinische Software” ausnahmslos hervorragend sind. Das Buch sei gut verständlich, schnell zu lesen, gäbe praxisnahe Tipps und würde sich auf das Wesentliche konzentrieren.

Soweit so gut: Doch ein Feedback fiel aus der Reihe. Ein Leser – offensichtlich entweder ein Entwicklungsleiter oder jemand aus der Qualitätssicherung – meinte:

“Das Buch gefällt mir sehr gut, nur der Einband ist schlecht – er sollte aus Blei sein, damit ich es meinen Entwicklern an den Kopf werfen kann”.

Wir prüfen derzeit, ob das Buch doch unter das Kriegswaffenkontrollgesetz fällt. Falls Sie noch ein Exemplar ergattern wollen, bevor es nur noch auf zweifelhaften Handelsplätzen in ehemaligen sowjetischen Teilrepubliken zu überhöhten Preisen erhältlich ist, empfehle ich Ihnen eine Notfallbestellung über unsere Webseite: Auf Wunsch auch mit einer Unbedenklichkeitserklärung oder persönlichen Widmung.