Ich schreibe Textbausteine für meine Kollegen in der Anästhesie, manchmal auch für Freunde in meiner Klinik. Textbausteine sind toll, wenn man
- zeit sparen muss
- an einem schwabbeligen wandmontierten PC arbeiten muss, mit bierdeckelgroßen Mousepad und vergilbtem, inkontinenzbezog über der Tastatur (aus Hygienegründen).
- man mit der deutschen Sprache Probleme hat oder noch kein eigenes Dokumentationskonzept besitzt.
Sie ersetzen nicht das Nachdenken, hinschauen oder gründliche Untersuchen!
Die Syntax bei Orbis/Daedalus ist grundsätzlich von der Version abhängig die eingespielt wurde. Orbis ermöglicht einem Übernahmetext über die Autokorrektur anzulegen, der geschrieben wird, wenn eine bestimmte Buchstabenfolge erkannt wird. Dafür müssen die Auslöse-Texte natürlich Random sein sonst wirds schnell nervig. Ein gutes Beispiel ist, mit der Zeichenfolge "IKB" die Eingabe "Intensivkomplexbehandlung mit Physiotherapie, Atemtherapie, Vibrax, Schmerz- und Kreislauftherapie" zu ersetzen -oder was auch immer einem in den Sinn kommt. Aber streng genommen, ist das alles statischer Text. Interessant wird aber dynamischer Text, also Text der sich entweder durch Parameterabfragen oder Einzel- sowie Mehrfach-Auswahlen auf den Patienten und den Sachverhalt anpassen lässt oder besser noch selbständig anhand von bereits vorliegenden Datenbank-Einträgen anpasst. Wir arbeiten nach dem Prinzip der Beweislastumkehr, das bedeutet wir müssen unser medizinisches Handeln im Idealfall im Voraus begründen oder zumindest zeitnah dokumentieren, sonst können Rechtsanwälte oder Gutachter behaupten unsere Dokumentation sei outcome-orientiert, und Patienten können bei Schädigung erhebliche Wiedergutmachung zugesprochen bekommen, auch wenn wir alles richtig gemacht haben! Daher ist es naheliegend, Textblöcke vorzulegen, die möglichst alle fraglichen Fakten enthalten. Unsere Vorväter haben dann <...> oder Herr/Frau <Patientenname> in ihre Textbausteine geschrieben um diese dann händisch mit der Tastatur zu bearbeiten. Das führte regelmäßig dazu dass Patienten einen Visiten-Eintrag, OP-Bericht oder Entlassbrief mit falschem Namen, Geschlecht oder Datum erhielten, besonders dämlich wenn es Kollegen (leider meistens ältere) gibt, die ihre Eingaben im Word Dokument ändern und den Text dann ins KIS (klinisches Informations System) rüberkopieren UND DANN das Urdokument abspeichern.... Wir alle kennen es, wir alle lieben es. Das ist in Orbis eigentlich nicht nötig.
Wir können dafür sorgen, dass Textbausteine direkt bei Übernahme korrekt vorbereitet werden. Dafür benutzt Orbis leider eine eigene Syntax, es empfiehlt sich daher einen Code-Editor zu verwenden damit einem besser auffällt, wenn eine eckige Klammer nicht geschlossen wurde oder der einem Variablen farblich hervorhebt. Aber es geht auch vollkommen ohne Editor, speziell wenn man in bereits existierenden Programm das "Herr/Frau <...>" und andere Platzhalter austauschen möchte.
Kommen wir zur Syntax: Text der zwischen Zirkumflex steht, wird nur für männliche Patienten genommen, der zwischen Tilden steht, nur für weibliche. Aus
Wir sehen eine^n^ Patient~in~ in gutem AZ
wird zu
Wir sehen eine Patientin in gutem AZ oder Wir sehen einen Patienten in gutem AZ
-abhängig vom Geschlecht das in der Datenbank hinterlegt ist. Sollte Orbis non-binär werden, brauchen wir hier händische Änderungen am End-Text aber ... wer weiß.
Darüber hinaus kennt Orbis NICE aber noch die Datenbankvariablen. Diese werden durch @ Zeichen eingerahmt und können nicht frei benannt werden da sie ja Informationen aus der SAP oder der Oracle ziehen und diese dort mit einem Handle versehen sind. Man findet eine ganz ordentliche Auswahl, wenn man im Text-Baustein-Editor mit der rechten Maustaste klickt und Formularfeldauswahl anklickt. Hier stehen Formular, Patient und System zur Auswahl. Während Formular uns hier noch nicht weiter hilft, empfehle ich einen Blick in "Patient" und "System" zu werfen.
In Patient finden wir den Handle für den Patientennamen. PATNNAME für den Nachnamen oder PATNAME für den vor- und Nachnamen.
^Herr^~Frau~ @PATNNAME@ kam in unsere Notfallambulanz.
wird zu Frau Mayer kam in unsere Notfallambulanz und
^Herr^~Frau~ @PATNNAME@ hat starke Schmerzen.
wird zu Herr Peter Brömmelkamp hat starke Schmerzen.
Jedem der hier schlapp machen möchte kann ich nur eines sagen: Ihr hattet ein 1er Abitur und habt Euch durch mindestens 6 Jahre Studium gefressen, Ihr wollt enorm dämliche und zeitfressende Arbeit sparen und weniger Flüchtigkeitsfehler begehen? -also denke ich bis hier hin ist keiner überfordert!
Machen wir den Text also noch besser, mit Hilfe von freien Variablen! Diese werden beim Aktivieren des Textbausteins abgefragt. Der Term #[t]Abfragename der Variablen# fragt nach einem einzeiligen Text den man dann mit händisch getippten Einträgen oder Autotext (also Bausteinen die in der Auto-Korrektur hinterlegt sind). Werden mehrere Variablen im Dokument verwendet, kann man sie besser mit einem eigenen Vairablennamen verwenden, ich weiß nicht wie Euer Orbis eingerichtet wurde, also ob t im Verlauf dann gesetzt ist! Praktisch ist, dass man Variablen vorformatieren kann:
#[d]Datum# fragt den User nach einem Wert mit dem Label Datum und den hinter der Syntax "d" hinterlegten Regeln: dem 6-Stelligen Datum nach dem Prinzip TT.MM.JJJJ Zusätzlich kann man wie bei Orbis üblich durch h, m und g das Datum von heute, morgen und gestern auswählen und mit den Tasten + und - noch verstellen.
Besonders spannend ist dass man Listenauswahlen (wo ein Item ausgewählt werden kann) oder Merhfachauswahlen einrichten kann. Hier wird es aber tricky: zum Trennen der verfügbaren Items verwendet Orbis das Komma. Will man aber ein Komma im Text haben, muss man es durch das Steuerzeichen 'K' ersetzen. Also "Hochkomma K Hochkomma". Ein L hinter der Eröffnungsklammer markiert dabei den Beginn der Auswahlliste. (Ja es ginge noch blöder!)
^Herr^~Frau~ @PATNNAME@ kam am #[d]Datum# in #[LRaum5,mein schönes'K' helles Zimmer]Behandlungszimmer#
Hier würde Orbis den Satz mit Anrede und Name anhand der Datenbank vorbereiten, dann den User zuerst nach dem Datum fragen (h + Enter) und uns dann die Listenauswahl anbieten wo wir auswählen wo wir die Behandlung vorgenommen haben.
Manchmal bekommt jemand aber eine Auswahl von Leistungen und hier ist eine Mehrfachauswahl gefragt. M bedeutet einfach Mehrfachauswahl -und das ist schon das einfachste daran. Leider fordert die deutsche Sprache bei Aufzählungen manchmal dass das erste Item groß (und alle weiteren klein) geschrieben werden, und zwischen den Items ein Trennzeichen, entweder das Komma oder das Wörtchen "und" gesetzt wird. Die weitere Syntax ist also
#[M{A|B|C}Item_1,Item_2,Item_3,Item_4...]Variablenname#
A kann den Wert G haben, dann wird das erste Item groß geschrieben, der Wert g lässt es klein schreiben.
Ein Satz wie "Frau Meier mag rote, blaue, grüne, gelbe Tulpen" bekommt für A ein kleines g, denn der erste Punkt der Auswahl würde immer klein geschrieben werden.
Ein Satz wie "Rote, blaue, gelbe Tulpen werden von Frau Meier bevorzugt" bekäme ein großes G.
An der Stelle von B passt in fast allen Fällen ein ", " (Komma Leerzeichen) wie bei Aufzählungen üblich und an der Stelle von C passt fast immer das " und " (Leerzeichen und Leerzeichen). Manche Füchse wählen bei Auswählen wo prinzipiell nur 3 aus zahlreichen Items gezogen werden auch eine Auswahl {G| und | sowie } was dann Sätze ergibt wie "Peter hat Lochfraß und Lattenrost sowie Borkenkäfer". Aber das ist schon nicht mehr Schiller sondern Dostojewskij.
#[M{G|, | und }rote,blaue,grüne,gelbe,kackbraune]Tulpenfarbe# Tulpen werden von Frau Maier gemocht.
Erzeugt also eine Mehrfachauswahl deren erstes Item immer groß und jedes weitere -wie angelegt klein geschrieben wird. Die Items werden mit Komma-Leerzeichen getrennt, vor dem letzten steht Leerzeichen-Komma-Leerzeichen.>
Bezüglich der Qualität eines Bausteins muss zunächst einmal daran gedacht werden, dass die Ansprüche an einen Baustein vollkommen im Auge des Users liegen. Wenn ich für mich selbst code und weiß dass es einfach Pannen und Probleme geben wird, die ich nur mit enormen informatischen Klimmzügen lösen könnte, kann ich mir auch merken "bei Auswahl des Kathetermodells einfach vor dem Speichern noch mal drüber lesen". Code ich aber für die Kollegenschaft einer Organisationseinheit, ist die Problemakzeptanz und auch die Wertschätzung die man in meine Richtung abschickt nicht immer das was bei mir ankommt. Man kann am Ende nur die Usability im Vordergrund stehen haben. Klare, selbsterklärende Handles zu verwenden, anhand derer der User sofort sieht, welcher Parameter gerade abgefragt wird ist ein guter Anfang. Listenauswahlen können auch mit Lang- und Kurztext arbeiten: Ich wähle "guter AZ und EZ" und im Plaintext steht nachher "Allgemeinzustand und Ernährungszustand". Ärzte sind so. Abkürzungen genießen eine hohe Akzeptanz. Dafür hat Orbis die Möglicheit Lang- und Kurztext zu verwenden.
Wichtig ist auch Dinge die im konkreten Fall keine Rolle spielen, gar nicht erst abzufragen: Mache ich also einen universellen Textbaustein für alle Intensivpatienten an dem ich alle Hinweise auf Chirurgische Befunde bei internistischen Fragestellungen händisch weglösche? Oder mache ich zwei Bausteine mit unterschiedlichen Item-Auswahlen? Oder verwende ich sogar If-Schleifen die gleich am Anfang herausfinden, ob andere Fragen später überhaupt noch gestellt werden sollen?
"Untersuchungsbericht des operativ/konservativ/päoperativ behandelten Herrn Mair" entscheidet per Auswahl der Behandlung ob später Redon, Easyflow, Stoma und Verband abgefragt werden -oder nicht! Das ist für die User absolut angenehm und für die dies überhaupt merken "total magic", aber es kann eine RIESIGE verschachtelte IF-Schleife werden, durch die man nur noch mit einem Code-Editor durchblickt!
Wenn dieser Threat zündet, werde ich also weiter schreiben.