Ein Perfusor gibt Medikamente kontinuierlich ab. Für seine Vorbereitung braucht es möglicherweise eine Verordnung, eine Ausgangslösung, eine Verdünnung, eine Endkonzentration und eine Laufrate. Jeder Wert hat eine Einheit. Die Rechnung auf dem Papier kann kurz sein; bei der Übergabe zwischen Verordnung, Zubereitung und Pumpeneinstellung gibt es trotzdem mehrere Stellen, an denen Fehler entstehen können.
Doseframe ist ein Projekt, das ich während meines Informatik-Masterstudiums entwickle. Die Idee entstand aus Gesprächen mit Ärzten der Neonatologie über die Vorbereitung von Perfusoren und den Arbeitsablauf darum herum. Ihre Rückmeldungen haben den Entwurf verändert: Die Übergabe einer mündlichen Verordnung ist wichtig, die eingegebene Dosis muss deutlich zu sehen sein, und die Pflegenden, die Spritzen aufziehen, müssen den geplanten Ablauf noch selbst erproben. Doseframe ist zurzeit ein Entwurf mit Prototyp, kein für die Patientenversorgung freigegebener Rechner.
Die Weltgesundheitsorganisation beschreibt Risiken bei der Medikamentengabe als Zusammenspiel von Arzneimitteln, Menschen und Arbeitsbedingungen. Das ist auch für Doseframe ein hilfreicher Blickwinkel. Rechnen ist wichtig. Ebenso wichtig sind die Herkunft eines Protokolls, eine verständliche Anzeige und die Gelegenheit, eine Abweichung zu erkennen, bevor jemand die Pumpe einstellt.
Was das Werkzeug leisten soll#
Der geplante Ablauf beginnt mit einer bereits ärztlich verordneten Dosis und einem von der Klinik freigegebenen Zubereitungsprotokoll. Doseframe soll die zu entnehmende Menge, die Endkonzentration und die dazugehörige Laufrate berechnen. Eingaben, Einheiten und Rechenweg sollen gemeinsam sichtbar sein. Bei einer Rückwärtsprüfung sollen eine vorhandene Zubereitung und eine eingestellte Rate die daraus rechnerisch folgende Dosis ergeben.
„Rechnerisch“ ist hier wichtig. Eine Berechnung aus eingegebenen Werten misst nicht, was beim Patienten ankommt. Gerät, Leitungen, Zubereitung und tatsächliche Situation brauchen eigene Prüfungen. Doseframe soll weder eine Therapie verordnen noch eine Pumpe steuern.
Der erste vollständige Entwurf umfasst zwei Zubereitungsarten: eine Standardkonzentration und eine gewichtsbezogene Zubereitung. Spätere klinische Rückmeldungen nahmen eine zweistufige Zubereitung aus einer Stammlösung in die geplante erste Version auf. Für Insulin sind eigene Protokollfragen offen; seine Rechnung lässt sich nicht einfach von einem anderen Wirkstoff übernehmen. Das sind Anforderungen in Prüfung und keine Sammlung freigegebener Arzneimittelanweisungen. Historische Kliniktabellen bleiben Forschungsmaterial, bis das verantwortliche Team aktuelle Fassungen bestätigt.
Warum ein Framework?#
Mein Studiengang verlangt ein wiederverwendbares Framework und eine darauf aufbauende Anwendung. Das passt zur Aufgabe. Einige Regeln sollen in jeder Klinik gelten: Größen brauchen eindeutige Einheiten, ein zurückgezogenes Protokoll darf kein scheinbar gültiges Ergebnis liefern, und eine geänderte Eingabe muss das alte Ergebnis ungültig machen. Andere Teile sind lokal: welche Zubereitungen verwendet werden, wer ein Protokoll freigibt, wie gerundet wird und welche Geräte vorhanden sind.
Deshalb trennt der Entwurf einen gemeinsamen Kern für Berechnung und Protokolle von einer klinikspezifischen Anwendung. Verschiedene Zubereitungsarten und Rundungsregeln werden zu ausdrücklichen Bausteinen. Das ist aufwendiger als ein Formular mit vielen Sonderfällen, macht die Entscheidungen aber sichtbar und prüfbar. Eine Änderung für einen Wirkstoff soll nicht unbemerkt die Rechnung für einen anderen verändern.
Die geplante Python-Anwendung im Backend rechnet; eine Weboberfläche zeigt die Ergebnisse. Eine klickbare Demo verwendet derzeit fiktive Daten und besitzt noch kein Rechen-Backend. Ärzte und Pflegekräfte können damit Reihenfolge und Formulierungen beurteilen. Die Demo kann weder die Arithmetik validieren noch eine klinische Eignung belegen.
Welche Fragen offen sind#
In der Projektdokumentation stehen bereits Rückmeldungen von Ärzten, darunter ein Oberarzt. Mit den Pflegenden, die Spritzen aufziehen und Pumpen einstellen, wurde der Ablauf noch nicht erprobt. Ihre Sicht ist unverzichtbar: Eine Anzeige, die dem Entwickler klar erscheint, kann ausgerechnet die Zahl verstecken, die bei der Übergabe gebraucht wird.
Andere Entscheidungen liegen bei den Fachleuten der Einrichtung. Die aktuelle Quelle und Freigabe eines Protokolls, Rundungsregeln, Grenzen von Pumpe und Spritze sowie das Vorgehen bei einem Netzwerkausfall lassen sich weder aus alten Dokumenten ableiten noch vom Entwickler bestimmen. Auch die Verantwortung für die Software und ihre Bewertung für einen klinischen Einsatz müssen geklärt werden. Die europäische Leitlinie zu Medizinsoftware stellt die medizinische Zweckbestimmung in den Mittelpunkt der Einordnung. Ein gelungener Studienprototyp beantwortet diese Frage nicht.
Als Nächstes möchte ich den Menschen, die damit arbeiten würden, eine kleine Aufgabe mit fiktiven Daten geben, Stolperstellen beobachten und einen Zubereitungsweg anhand unabhängig geprüfter Referenzfälle verbessern. Hilft der Ablauf nicht, muss sich der Entwurf ändern. Ziel ist eine Rechnung, die im entscheidenden Moment nachvollziehbar ist, ohne eine Sicherheit zu behaupten, die das Projekt noch nicht belegt hat.
In einem zweiten Beitrag beschreibe ich, warum Einheit, Protokollversion und Rückwärtsrechnung gemeinsam zu dieser Nachvollziehbarkeit gehören.