↓Zum Hauptinhalt springen
  1. Digitale Odyssee/

Doseframe: Eine Rechnung ist nur so verlässlich wie ihre Eingaben

·830 Wörter·4 min·
Digitale Odyssee Doseframe Medizinsoftware Patientensicherheit Softwarearchitektur Gebrauchstauglichkeit
Simon Bernbeck
Autor
Simon Bernbeck
Software-Ingenieur und Masterstudent in Informatik an der PUC Rio de Janeiro, ursprünglich aus Deutschland. Ich schreibe über das, was ich lerne, wo ich hinreise und was es wert ist, weitergegeben zu werden.
Inhaltsverzeichnis

Als ich Doseframe zunächst als Perfusorrechner beschrieb, schien die Formel das naheliegende technische Problem. Inzwischen widmet die Projektdokumentation den Angaben um die Formel mindestens ebenso viel Aufmerksamkeit. Welche Zubereitung enthält die Spritze? Steht die Konzentration in Milligramm oder Mikrogramm pro Milliliter? Welche Fassung des Klinikprotokolls ist freigegeben? Wurde das Gewicht geändert, nachdem das Ergebnis erschien?

Die geplante Anwendung muss diese Fragen beantworten, bevor sie eine verwendbare Zahl zeigt. Doseframe ist weiterhin ein Entwurf mit Prototyp. Rechnungen und Protokolle sind nicht für die Versorgung von Patienten validiert. Dieser Beitrag erklärt die technischen Entscheidungen, die das Projekt prüfen will; er enthält keine Anweisung zur Zubereitung oder Dosierung.

Einheiten gehören zur Rechnung
#

Eine Zahl ohne Einheit ist unvollständig. Dieselbe Ziffer kann eine Wirkstoffmenge, ein Volumen, ein Gewicht oder eine Laufrate bezeichnen. Dazu kommt die Zeit: Eine Verordnung pro Minute und eine Pumpeneinstellung pro Stunde lassen sich erst nach Umrechnung vergleichen. Auch der Faktor tausend zwischen Milligramm und Mikrogramm verschwindet leicht, wenn Software beides als bloße Zahl behandelt.

Doseframe soll solche Größen ausdrücklich darstellen und unvereinbare Kombinationen zurückweisen. Die Ergebnisansicht soll verordnete Dosis, Zubereitung, Endkonzentration und Laufrate gemeinsam zeigen, jeweils mit Einheit. So können Ärztinnen und Pflegende die Anzeige mit der ursprünglichen Verordnung und der vorhandenen Spritze vergleichen, statt nur einer groß gesetzten Zahl zu vertrauen.

Auch eine saubere Einheitenprüfung erkennt nicht jede falsche Eingabe. Wird ein Gewicht falsch, aber noch plausibel eingegeben, stimmt die Dimension weiterhin. Aus „die Rechnung ist formal konsistent“ darf die Oberfläche deshalb kein „die klinische Entscheidung ist sicher“ machen. Wo die Klinik freigegebene Grenzen liefert, kann das Programm Abweichungen anzeigen; die Grenzen muss das klinische Team festlegen.

Ein Protokoll hat eine Geschichte
#

Eine Zubereitungsregel braucht Quelle, Geltungsbereich, Version und Freigabestatus. Im vorgesehenen Ablauf wandert ein Protokoll vom Entwurf über die fachliche Prüfung zur Veröffentlichung. Ein zurückgezogenes Protokoll steht für neue Berechnungen nicht zur Verfügung. Eine Änderung an einer freigegebenen Fassung erzeugt einen neuen Entwurf, statt die geltende Regel still zu verändern. Wer rechnet, soll sehen können, welche Fassung das Ergebnis erzeugt hat.

Das ist besonders wichtig, weil das Projekt mit historischen Kliniktabellen begann. Ein Dokument kann wertvolle Auskunft über frühere Praxis geben, ohne heute eine gültige Anweisung zu sein. Widersprüche in alten Tabellen sind Fragen für die verantwortlichen Ärztinnen, Ärzte und die Apotheke. Ich kann sie nicht durch Vermutung „korrigieren“. Das erste echte Medikament wird erst nach Bestätigung des aktuellen Protokolls und fachlich geprüfter Rechenbeispiele umgesetzt.

Auch bei einer Störung braucht die Anwendung eine klare Antwort. Der gegenwärtige Entwurf gibt kein neues klinisch verwendbares Ergebnis aus, wenn er den erforderlichen Protokollstatus nicht prüfen kann. Das Ersatzverfahren bei einem Ausfall muss die Einrichtung festlegen. Ohne diese Entscheidung und ihre Prüfung wäre es verfrüht, die Webanwendung als Notfalllösung zu bezeichnen.

Die Rechnung in beide Richtungen lesen
#

Der Vorwärtsweg beginnt mit einer verordneten Dosis und einer freigegebenen Zubereitung. Er ergibt eine rechnerische Laufrate. Der Rückwärtsweg beginnt mit der tatsächlichen Zubereitung und einer bereits eingestellten Rate. Er ergibt die Dosis, die diese eingegebenen Werte rechnerisch bedeuten. Beide Wege auf einer Kontrollansicht können einer zweiten Person helfen, Verordnung, Spritze und Einstellung zu vergleichen.

Wie unabhängig diese Prüfung ist, entscheidet der Arbeitsablauf. Wenn zwei Menschen dieselbe Schaltfläche drücken, entdecken sie dadurch keinen gemeinsamen Softwarefehler. Der Entwurf nennt die Ansicht daher Gegenkontrolle, nicht unabhängige Verifikation. Noch muss das Team erfahren, welche Originalangaben jede Person tatsächlich zur Hand hat und wie die Klinik ihre Prüfung dokumentiert.

Die Anzeige muss außerdem ehrlich auf Änderungen reagieren. Ändert jemand Gewicht, Konzentration, Protokoll oder Rate, muss ein altes Ergebnis sofort seine Gültigkeit verlieren. Ein stehen gebliebenes Resultat ist besonders gefährlich, weil es durch seine Gestaltung aktuell wirken kann. Sichtbare Versionen und Eingaben gehören daher zur Sicherheit des Entwurfs und sind keine Dekoration.

Was der Prototyp prüfen kann
#

Die derzeitige klickbare Demo arbeitet mit fiktiven Werten und ohne Rechen-Backend. Mit ihr lässt sich untersuchen, ob die Beteiligten die wichtigen Felder finden, die Übergabe verstehen und eine geänderte Eingabe bemerken. Sie beweist nicht, dass der Rechenkern korrekt ist. Dafür braucht es unabhängig berechnete Referenzfälle, Prüfungen an Einheiten- und Gewichtsgrenzen und Tests, dass ein nicht freigegebenes Protokoll kein verwendbares Ergebnis liefert. Später muss ein Test auch die Browseranzeige mit der Berechnung im Backend vergleichen.

Ebenso wichtig sind Bedienversuche. Die WHO beschreibt Situationen mit hohem Medikationsrisiko als Zusammenspiel von Arzneimitteln, Menschen und Arbeitsbedingungen. Für Doseframe heißt das: Ärzte und Pflegekräfte sollen typische Aufgaben ohne Anleitung lösen; dabei werden übersehene Angaben und missverstandene Warnungen beobachtet. Ein selbstsicheres grünes „sicher“ würde mehr behaupten, als die Software belegen kann.

Soll aus dem Studienprototyp später eine klinische Anwendung werden, müssen Validierung, Verantwortung, Qualitätsverfahren und die Anforderungen an Medizinsoftware geklärt werden. Die europäische MDCG-Leitlinie ist eine Orientierung zur medizinischen Zweckbestimmung. Bestandene Einheitstests allein machen aus dem Entwurf kein klinisches Produkt.

Ich möchte eine bescheidene These prüfen: Eine Rechnung lässt sich leichter hinterfragen, wenn die Anwendung zeigt, woher jede Zahl stammt, welche Regel verwendet wurde und was sie nicht prüfen konnte. An diesem Maßstab müssen sich der nächste Prototyp und die Gespräche mit dem Klinikteam messen lassen.

Verwandte Artikel

Doseframe: Perfusorberechnungen nachvollziehbar machen
·707 Wörter·4 min
Digitale Odyssee Doseframe Medizinsoftware Softwareentwicklung Forschung Patientensicherheit
PrivDev: Warum ein Kryptografie-Befund Kontext braucht
·646 Wörter·4 min
Digitale Odyssee PrivDev Kryptografie Datenschutz IT-Sicherheit Forschung
PrivDev: Was ein Code-Scanner über Datenschutz aussagen kann
·772 Wörter·4 min
Digitale Odyssee Datenschutz Softwareentwicklung Forschung Kryptografie Wissensgraphen
PrivDev: Von statischer Analyse zu Privacy-Wissen
··591 Wörter·3 min
Digitale Odyssee Datenschutz KI Software-Engineering RAG Wissensgraphen DSGVO Forschung
Project Planning Pipeline: In Obsidian planen, mit KI unterstützt
··1598 Wörter·8 min
Digitale Odyssee Obsidian KI Projektplanung CLI Produktivität Wissensmanagement Guide