Copyright © 1999-2002. Karsten Hilbert, Christian Heller, Roland Colberg, Peter Hahn et al.
Res Medicinae -- Information in Medicine -- <www.resmedicinae.org>
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.
Autoren:
Hinweis: Der Inhalt basiert auf Version 1.33 der früheren Textversion.
$RCSfile: analysis-de.sgml,v $
@version $Revision: 1.8 $ $Date: 2002/07/09 07:04:26 $ $Author: ncq $
Vereinfachte Modelle alltäglicher, realer Abläufe bilden und sie in Software umsetzen, um Zeit und Kosten zu sparen, die Qualität der Serviceleistungen zu verbessern und sich auch Arbeitserleichterungen zu Nutze zu machen.
This paper tries to document all aspects that a possible free software healthcare application should include. In other words, the requirements on such a system are analysed here.
We need your help! The more people help us, the better our free software will be for your use!
If you'd like to contribute, contact one of the project members of Res Medicinae under: http://www.resmedicinae.org
Schritt für Schritt kommt man dann zu einem sinnvollen Ganzen. Es sollte möglich sein, von einem herkömmlichen System nach und nach alles bis auf die eigentliche Abrechnung+Statistik zu ersetzen.
Um real zu starten (in den Arztpraxen) bräuchte man: das Abrechnungsmodul und den Formulardruck. Letzteres ist u.U. noch machbar. Ersteres muß m.E. von einem Anbieter beigesteuert werden (nicht kostenfrei natürlich !). Alles andere ist “irgendwie” bereits vorhanden, machbar, “anstrickbar”. Durch die Offenheit des gesamten Systems wäre dieses “Anstricken” auch kein Problem, da nach und nach alle Hacks durch ordentlich implementierte Module ersetzt werden können, ohne die Gesamtheit zu gefährden. Und die Offenheit vertuscht auch die noch vorhandenen Hacks nicht, sodaß man immer weiß, wo dringend Arbeit nötig ist.
http://www.mutt.org)
Die Konfiguration dient dazu, eine Software dem jeweiligen Benutzer und seiner Umgebung bestmöglich anzupassen. Es müssen aber andere Aspekte beachtet werden:
Es gibt mehrere Arten von Konfigurationsdaten:
Prinzipiell sollte man mit zwei Tabellen auskommen:
.---------------------------------------.
| Nutzer | Arbeitsplatz | Option | Wert |
`---------------------------------------'
.---------------------------------.
| Patientennummer | Option | Wert |
`---------------------------------'
Die Einstellung von Optionen sollte leicht sein. Alle Optionen sollten unter einem Programmpunkt zu finden sein. Zusätzlich ist es bequem, wenn alle Optionen eines Programmbereiches in diesem Programmbereich zugänglich sind.
Beim Fehlen von Einstellungen während des Programmablaufs sollten sofortige Einstellung per Direktverzweigung möglich sein. Man sollte dabei die Möglichkeit bekommen, Einstellungen für sich von anderen Arbeitsplätzen oder von anderen Kollegen übernehmen zu können. Eine schnelle Auswahl einer funktionsfähigen Voreinstellung muß möglich sein, um den reibungslosen Praxisablauf nicht zu bremsen.
Da eine zentrale Datenbank auf dem Server sowieso notwendig ist, sollten dort auch die Konfigurationsdaten gespeichert werden. Trotzdem ist es nützlich, die Konfiguration z.B. beim Ausloggen auch lokal zu speichern, um bei Nichterreichbarkeit der Datenbank und Zugriff auf eine alternative Datenbank die Konfiguration weitgehend übernehmen zu können.
Hier sollen typische, reale Abläufe in einer Arztpraxis und deren optimale Unterstützung durch eine Praxis-EDV beschrieben. Was wie optimal ist, hängt natürlich immer vom Betrachter ab.
Details anderer Art (gesetzlich, technisch, administrativ, konzeptionell), die nicht direkt die Funktionalität, wohl aber die Implementation betreffen, sind im Kapitel Technische Details unter dem jeweils betreffenden Bereich aufgeführt.
Hier soll beschrieben werden, wie die EDV effektiv den Ablauf vom Eintreffen eines Patienten in der Arztpraxis bis zum Zeitpunkt “Sie können jetzt Platz nehmen.” unterstützen soll.
Der Programmteil "Patient aufnehmen" wird aufgerufen. Es bietet sich an, am Arbeitsplatz an der Anmeldung zwei Varianten mit Kürzeln zu belegen: 1) Aufnehmen mit Chipkarte, 2) Aufnehmen ohne Chipkarte.
Die Liste der gegenwärtig eingelesenen, aber noch nicht übernommenen Chipkarten erscheint. Der Anwender wählt eine Chipkarte aus.
Alternativ sollte man auch die Patientennummer in eines dieser Felder tippen können. Während der Eingabe startet die Suche, deren Ergebnisliste sich mit jedem weiteren Buchstaben verkleinert.
Paßt nur noch eine vorhandene Person, wird beim nächsten getippten Buchstaben ein Signalton und ein Hinweis ausgegeben (ohne daß der Anwender diesen Hinweis bestätigen müßte). Dasselbe beim zweiten weitergetippten Buchstaben. Ab dem dritten Buchstaben (oder Wechsel in ein anderes Feld) wird angenommen, daß tatsächlich ein neuer Patient eingegeben werden soll. Die Maske erweitert sich zur Eingabemaske für neue Patienten.
In dieser Maske sollte höchstmögliche Intelligenz den Anwender unterstützen.
Nun liegen identische Zustände unabhängig von der Chipkarte vor.
Es werden jetzt Felder für weitere Eingaben angeboten, falls diese nicht schon gefüllt sind.
Aus dem Vornamen wird per Liste das Geschlecht ermittelt. Ist keine eindeutige Zuordnung möglich, so wird abgefragt.
Optional werden Telefonnummer, Beruf, Rezeptbefreiung, Hausarzt, Stockwerk, Wohnungsnummer und Kommentar erfragt.
Bei Privatpatienten wird nach dem Rechnungsempfänger gefragt. Die Daten des Patienten sind voreingestellt, können aber einfach durch Tippen überschrieben werden.
Ist es ein ...
Die "reason for encounter"/Beratungsursache aus Sicht des Patienten ("habe Rückenschmerzen", "bin umgeknickt") wird erfragt. Der Patient wird mit seiner Problembeschreibung in die Wartezimmerliste eingereiht.
In die Karteikarte wird die Angabe des Patienten zur Beratungsursache und der Zeitpunkt des Erscheinens in der Praxis eingetragen.
Im Sprechzimmer soll die Übersicht zu den Daten des Patienten (siehe Patientenübersicht) direkt auf den Schirm gebracht und der Aufruf in der Kartei mit Zeit vermerkt werden.
Eine Suche per Hand muß auch möglich sein. Dort muß man wahlweise Patientendaten (Name) oder die Patientennummer eintippen können. Der Suchalgorithmus muß fehlertolerant sein:
Falls diese normale Suche keine Ergebnisse bringt, sollte automatisch eine Suche nach dem Soundex-Algorithmus durchgeführt werden.
Die Suchergebnisse werden alphabetisch sortiert und per word wheel ist der gewünschte Patient aufrufbar. Zum Namen sollen Geburtsdatum, Straßenname und Wohnort (ohne PLZ) angezeigt werden.
Wenn der Patient z.B. an der Anmeldung in die Warteliste oder den Terminkalender gestellt wurde, kann man ihn von dort auswählen.
Externen Programmen sollte es möglich sein, per definierter Schnittstelle dem Programm einen Patientenaufruf mitzuteilen.
Man soll aus einer Patientenliste, die per Suche nach bestimmten Kriterien entstanden ist, direkt den Patienten aufrufen können. Dann sollte das Wechseln des Patienten nur über Zurückgehen in die Liste und Wahl eines anderen bzw. Verlassen der Listenwahl möglich sein. Solche Listen wären z.B: Fehlerliste KV-Prüflauf, Suche von Patienten mit bestimmten Eigenschaften (wie Diagnosen), etc.
Ich möchte beim Aufruf eines Patienten zunächst rasch einen Überblick über ***alle*** aktuell anstehenden Probleme bekommen. Dies müssen nicht nur medizinische Diagnosen nach ICD 10 sein, sondern natürlich auch Probleme im sozialen Umfeld, organisatorische Aufgaben usw. Dazu wäre es unter Qualitätsgesichtspunkten sehr sinnvoll, optional ein (Behandlungs-)ziel zuordnen zu können.
Davon abgesetzt sollten derzeit nicht aktive Probleme, Dauerdiagnosen wie z.B. eine gut eingestellte art. Hypertonie oder Z.n. Mamma-Ca auf dieser Übersicht erscheinen. Hier sollte sich aber gleich eine Verknüpfung zu einem flexiblen Recall-System erstellen lassen, z.B. für Nachsorgetermine (darunter verstehe ich, dass das System auch 3 Tage vor dem Recalltermin anspringt, wenn die Patientin zufällig vorbeikommt).
Die Diagnosen sollten sich wahlweise nach Priorität oder nach Kausalität sortiert anzeigen lassen.
Weiterhin sollte es möglich sein, über die medizinischen Diagnosen auf passende Befunddaten zugreifen zu können. So sollte ein Programm in der Lage sein, beispielsweise bei Mausklick auf die Diagnose KHK alle EKGs, Ergos, Coros und Echos aus der Datenbank zu holen, bei chronischer Pankreatitis alle Abdomensonos, Lipasewerte usw.
Diese Zuordnungen sollten über eine individuell konfigurierbare Datenbankdatei machbar sein.
Analog dazu möchte ich die laufenden “Prozeduren” wie Medikation (mit Dosierung), andere Behandlungen, Mitbehandlungen von Kollegen (!), Selbstbehandlungen im Überblick haben, wiederum abgesetzt von früheren / abgeschlossenen Behandlungen, OPs etc.
Auf Mausklick könnte hier z.B. eine Übersicht über die letzten Verordnungen des betr. Medikaments herausgesucht und eine Rezepterstellung ausgelöst werden, oder auch eine Berechnung des Medikamentenbestandes des Pat.
Mit einem solchen System würde man die unübersichtliche “elektronische Karteikarte” kaum mahr brauchen und würde die Möglichkeiten der EDV erst richtig nutzen. Gerade als Hausarzt arbeitet man oft an vielen Problemen gleichzeitig, daher wäre eine solche problemorientierte Dokumentation m.E. sehr sinnvoll.
Mit dem Komplex Abrechnung/Liquidation möchte ich mich übrigens erst im Anschluss an den Patientenkontakt befassen. Dies sollte in einer eigenen Maske geschehen, in der die “echten” Diagnosen aus o.g. Patientenübersicht wahlweise als im laufenden Quartal abrechnungsrelevant markiert werden können.
Ein Vorschlag zur Raumaufteilung meinerseits:
Nach Wahl des Patienten (per Suche, aus Warteliste, gesteuert von Fremdprogramm) wird eine definierbare Auswahl der Patientendaten angezeigt. In den meisten Fällen wird dies eine Übersicht zum Patienten sein. Diese soll der raschen Orientierung über den Patienten vor Anzeigen der Gesamtkartei dienen. Einige wenige limitierte Funktionen können direkt integriert sein (z.B. Wiederholungsrezept).
Ich möchte dort folgendes sehen (im Sprechzimmer, daher z.B. keine Anzeige, ob KVK vorhanden):
STRG-I zeigt Detailinfos
Tab erreichbar seinLeertaste und z.B. Strg-D erzeugt ein neues Rezept
Mit TAB kann man zwischen den Bereichen wandern. Mit Cursor-hoch/runter
ggf. in Listen in den Bereichen wandern. Mit STRG-I mehr Informationen
zum jeweiligen Eintrag in der Liste im Bereich aufrufen.
Von jedem Eintrag sollte man direkt in den kontextabhängigen ausführlichen Teil der Detaildaten verzweigen können. Es sollen hier also keine ausgebufften Änderungsmöglichkeiten vorhanden sein, wohl aber direkte Verzweigungen in den jeweiligen Bereich.
Von hier gelange ich per ENTER, F3, o.ä. in die elektronische Kartei.
Per F2 geht es in die Abrechnung. Per Strg-F zur Formularübersicht,
per Strg-B zum Befundarchiv, ...
Mittels ESC rotiert man durch die Abfolge Übersicht des aktuellen Patienten,
die Suchmaske für Patienten, den heutigen Terminkalender (falls aktiv) und
die Warteliste (falls diese aktiv und nicht leer ist).
Dr. Wilfried Behrendt schreibt:
Als Hausarzt habe ich grosses Interesse an einer Möglichkeit, patientenbezogene Daten aus der Praxis-EDV vor Ort greifbar zu haben. Dies könnte mittels eines Reportgenerators bewerkstelligt werden, der eine wählbare Selektion von Patientendaten entweder auf Papier ausdruckt oder per Schnittstelle (seriell,USB,IR o.ä.) an ein Notebook oder Pocket-PC überträgt. Stellt man sich diese Schnittstelle bidirektional vor, so wären vor Ort vorgenommene und erfasste Änderungen (Änderungen der Medikation, etc.) anschliessend wieder in die Praxis-EDV übertragbar. Was dringend zu beachten ist: die Mobilität beim Hausbesuch lässt nur kleine, leicht transportable Hardware zu. Selbst ein Laptop ist mir da schon zu unpraktisch, wohingegen die Pocket-Pcs dieses Problem nicht aufwerfen (dafür haben sie keine Tastatur!). Die Firma promedico hat wohl schon eine Windows-basierte Lösung entwickelt, aber es gibt ja bereits Linux für PDAs und da sollte sich doch etwas machen lassen.
Die Dokumentation von Hausbesuchen vor Ort und deren Übertragung ist wohl mit derzeitiger Technik nur sehr unvollkommen möglich. Da man keine EDV-Infrastruktur mit sich rumschleppen kann, gilt es handschriftliche Notizen, Rezepte, Überweisungen, Einweisungen u.s.w. in der Praxis manuell einzugeben. Dieser Daten-Rückfluss bleibt also zunächst noch unbefriedigend, aber die Möglichkeit aktuelle Informationen zum Hausbesuch mitnehmen zu können ist doch ein nützliches Feature.
Darüber hinaus lassen sich für o.a. Reportgenerator sicherlich noch jede Menge weiterer nützlicher Einsatzmöglichkeiten denken.
mfg, Dr. Behrendt
Es lassen sich folgende Kriterien ableiten :
Eine nützliche Minimallösung ist aber schon die Exportmöglichkeit der derzeit aktuellen Daten der Praxis zur Mitnahme zum Hausbesuch.
Es klingt sinnvoll, zunächst mit nicht zulassungspflichtigen Programmteilen anzufangen. Das wäre im Wesentlichen die medizinische Dokumentation.
Zeitdauer eines Gesundheitsproblems im Zustand “aktiv”
ein Arztbesuch wegen eines oder mehrerer Probleme
Bearbeitung eines Problems während eines Arztbesuches. In der el. Kartei durch mehrere Einträge dargestellt.
Eine physikalische Zeile mit Patientendaten in der elektronichen Kartei. Eine oder mehrere Zeilen bilden einen Eintrag.
Kleinste, nicht weiter ohne Sinnverlust teilbare Einheit von Daten in der elektronischen Kartei. Hat genau einen Typ nach SOAP (subjective, objective, assessment, plan) bzw. ABTDL (Ananmese, Befund, Therapie, Diagnose, Leistungsziffern). Kann mehrere Zeilen umfassen.
Longitudinal bilden also mehrere Teilkontakte eine Episode oder, anders gesagt, den zeitlichen Ablauf der Erkennung und Behandlung eines aktiven, akuten, gesundheitlichen Problems. Vertikal dazu bilden mehrere Teilkontakte einen Kontakt, also einen Arztbesuch. Die zeitliche Abfolge der Kontakte bildet die statistische Inanspruchnahme des Gesundheitswesens.
Die “Problemliste” des POMR (problem oriented medical record) ist ähnlich einer Sammlung von Episoden (also aktiven Problemen) plus inaktiven, aber wichtigen, Problemen (Anamnese von ...). Man kann die Problemliste auch etwas höher ansetzen: Mehrere Episoden gehören zum gleichen grundlegenden gesundheitlichen Problem, z.B. Problem insulinpflichtiger Diabetes Mellitus mit mehreren Episoden zur Kontrolle der Einstellung, einer etwas schwerwiegenderen Entgleisung durch einen “unvorsichtigen Urlaub” und eine Episode einer infizierten Wunde am Unterschenkel, dazu noch eine Episode “Vorstellung beim Augenarzt”.
Das SOAP-Modell (Subjective, Objective, Assessment, Plan) kann auf zwei Ebenen Anwendung finden: Zum einen strukturiert es den Teilkontakt, zum anderen findet man es ähnlich in der zeitlichen Abfolge der Teilkontakte einer Episode wieder.
Der Beitrag im DÄ über das Weed-System ist in der Tat interessant. Man sollte dem vielleicht hinzufügen, daß ein relationales Datenbanksystem die Trennung von Inhalt und Ansicht fördert, so man sich an gute Designkriterien hält (Normalisierung etc.). Das niederländische System, das klassische System, das Weed-System - das sind eigentlich nur Darstellungsweisen derselben Daten, vorausgesetzt, das zugrundeliegende Datenmodell ist wohldefiniert.
Die herkömmliche Kartei (also tabellarisch chronologisch) ist dann einfach: “Zeige ALLES von ANFANG bis ENDE”.
> Darüberhinaus sind die Systeme ausgesprochen abrechnungsorientiert: man kann
> z.T. nur Diagnosen eingeben, die auch “abgerechnet” werden können, die
> Diagnosen lassen sich nicht kausal oder nach Priorität sortieren, die
> aktuellen “Quartals”-Diagnosen werden beim Quartalswechsel gelöscht, als habe
> die KV-Abrechnung den Patienten geheilt. Welch ein Schwachsinn!!
Endlich spricht das mal jemand aus !! Sie nennen ja auch gleich den Grund: Abrechnungsorientiertheit. Hier wurde eben die Datenbank verkehrt herum definiert: Diagnoseinformationen in der Kartei zeigen auf echte Einträge bei der Abrechnung, anstelle daß für die Abrechnung bestimmmte Diagnosen in der Kartei markiert werden. Letztere Vorgehensweise steht ganz oben auf meiner Liste für GNUMed.
> Daher wundert es mich heute keineswegs, dass die Mehrzahl der Kollegen die
> Programme immer noch als komfortable Rezeptdruck- und Abrechenmaschinen=
> benutzt, die Dokumentation aber nach wie vor auf Papier durchführt.
IMHO sind die Eingabemedien (Tastatur, Maus) aber auch durch Papier und Stift immer noch relativ leicht zu schlagen. Es wird eben die Hard-/Software “Gehirn” wesentlich unmittelbarer und noch dazu mit den Rohdaten eines Patienten gefüttert. Eine EDV muß eigentlich immer erraten, was die Software im Gehirn als nächstes tun wird. Da ist es einfacher, einfach die Produkte (also z.B. Schrift oder Sprache) der Software im Gehirn aufzufangen und wiederzugeben. Immerhin geht das so langsam halbwegs ohne Störung durch Schreiben auf elektronischer Oberfläche (evtl. gleichzeitig auf Papier).
> Ich möchte beim Aufruf eines Patienten zunächst rasch einen Überblick über
> ***alle*** aktuell anstehenden Probleme bekommen. Dies müssen nicht nur
> medizinische Diagnosen nach ICD 10 sein, sondern natürlich auch Probleme im
> sozialen Umfeld, organisatorische Aufgaben usw.
Hier zeigt sich schon ein subtiles Problem, dem viele von uns verfallen sind: Was kümmert uns eigentlich der ICD (außer am Ende des Quartals auf dem Konto) aus medizinischer Sicht ? Natürlich nichts ! Eine solche Kodierung sollte m.E. (fast) völlig unsichtbar für den Anwender ablaufen und den Dokumentationsprozeß nicht beeinflussen. Im Gegenteil kann der Gedanke “ICD10” im Hinterkopf die Dokumentation sogar verfälschen.
Es soll möglich sein, zwischen beliebigen Patienten Beziehungen herzustellen und diese mit bestimmten Bezeichnungen zu versehen. Dabei sollen biologische und soziale Beziehungen möglich und abgrenzbar sein. Bei Vorliegen einer Beziehungsrichtung soll das Programm automatisch die Gegenrichtung erkennen und nutzen. Beziehungsbäume sollen grafisch darstellbar und in definiertem Textformat (XML ?) and Fremdprogramme übergebbar sein (z.b. Stammbaumanalyseprogramme). Als möglicherweise hilfreich erwiese sich eine Schnittstelle zu einer Datenbank mit Erbkrankheiten (“Mendelian Inheritance in Man” ?) mit Möglichkeit der der Darstellung der Erkrankungswahrscheinlichkeiten im Stammbaum.
Zugegebenermaßen ein durchaus altbackener Ansatz, aber dafür mit deftiger Intelligenz (sofern sie funktioniert). Entstanden aus dem täglichen Umgang mit TurboMed und MediStar.
Die elektronischen Kartei des selektierten Patienten ist aufgerufen.
Am Oberrand zeigen wenige Zeilen den Patienten, sein Alter, seine aktiven Probleme und seine laufende bzw. letzte Medikation.
Links steht das Datum der jeweiligen Einträge. Das Datum wird pro Tag nur einmal angezeigt. Ist der Zeitabstand zwischen aufeinanderfolgenden Eintragungen größer als 2 Stunden (konfigurierbar), dann wird unter dem Tagesdatum die Tageszeit angezeigt. Die Tageszeit wird vor jeder Eintragung angezeigt, die mehr als die genannten 2 Stunden Abstand zur vorhergehenden hat. Zusätzlich wird die Tageszeit vor der jeweils vorhergehenden Eintragung angezeigt. Optisch wird die Tageszeit unauffälliger als das Datum dargestellt. Durch Drücken der Tabulatortaste in der Datumsspalte oder längerem Schweben mit dem Mauszeiger über der Datumsspalte werden zugehörige Detailinformationen angezeigt:
Das Eingeben eines anderen Datums in der Datumsspalte funktioniert laut der Beschreibung für das Datumsfeld, die auf http://www.gnumed.org zu finden ist.
Mittels ENTER gelangt man von der Datumsspalte in die nächste Spalte. Von dort
gelangt man mittels POS1 wieder in die Datumsspalte, sofern man in der nächsten
Spalte bereits ganz links steht.
Die zweite Spalte von links zeigt für jede Eintragung eine der Markierungen
A, B, T. Jede Eintragung schließt, bezogen auf den Typ, mit dem Zeilenende ab.
Abrechnungsziffern werden nicht (oder doch: konfigurierbar, dann “L”)
angezeigt. Diagnosen haben keine eigene Gruppe. Weitere Gruppen können frei
definiert (z.B. X=Röntgen), sowie die genannten Markierungen umdefiniert werden.
Mit TAB erhält man wieder Detailinformationen:
Gibt es mehrere Zeilen desselben Typs, so werden diese untereinander angezeigt, wobei der Typ wie beim Datum nur einmal angezeigt wird. Fügt man der Kartei eine Zeile hinzu, wird diese als weitere Zeile dem internen Gesamtfeld für diesen Typ an diesem Tage hinzugefügt. Es muß freilich eine Möglichkeit geben, bei Mehrfachbehandlung am selben Tage, Zeilen gleichen Typs als nicht zusammenhängend zu definieren. Grob kann das über einen konfigurierbaren Zeitabstand erfolgen.
Die dritte Spalte enthält die eigentlichen Einträge. Hier steht freier oder
strukturierter Text, Querverweise oder Meßwerte. Per ALT-A/B/T wird der
Typ des Eintrags für die gesamte Zeile neu gewählt. Vorgewählt ist bei Aufruf
der Kartei die Episode des vorhergehenden Aufrufs. Per ALT-E wird die
Episode gewählt. Per word-wheel kann dann aus den bei diesem Patienten
vorhandenen Episoden und der arztbezogenen Diagnosenliste gewählt werden.
Eintragungen, die älter als 6 Monate (konfigurierbar) sind, werden
eingeklappt und nur das Datum und die Bezeichnung der Episode angezeigt.
Solche Einträge können per Doppelklick oder ENTER aufgeklappt
werden. Einträge der aktuell gewählten Episode werden jedoch für die
letzten 2 Jahre (konfigurierbar) aufgeklappt. Per Funktionstaste kann
man folgendes auf-/zuklappen:
... kann man mit der Maus oder mit SHIFT+Cursor-Links/Rechts, wobei
mit SHIFT+STRG+Cursor-L/R wortweises Markieren möglich ist. Per Maus
markiert Halten und Ziehen je nach Position. Doppelklicken markiert das
angezielte Wort. Dreifachklicken markiert die gesamte Zeile. SHIFT-EINFG
kopiert den markierten Texte in die Zwischenablage. SHIFT-ENTF verschiebt
in die Zwischenablage und löscht. STRG-EINFG fügt aus der Zwischenablage
ein. ENTF löscht markierten Text.
... kann man sich wie folgt: Cursor links/rechts - inneerhalb der Zeile.
Keine Wirkung am Zeilenanfang/-ende. Cursor rauf/runter nächste/voherigen
Zeile außer erste/letzte. Bild rauf/runter einen Bildschirm rauf/runter.
STRG+BILD rauf/runter oder STRG+POS1/ENDE - erste/letzte Zeile.
STRG+Cursor links/rechts springt wortweise in der Zeile. POS1 geht zum
Anfang der Zeile und von dort zum Anfang der jeweils vorhergehenden Spalte.
ENDE geht zum Ende der Zeile. Enter öffnet eine neue Zeile mit gleichem
Datum, neuer Zeit und gleichem Typ der vorhergehenden. Verlassen einer
leeren Zeile (keine Eintragung) löscht diese.
Markieren und Bewegung geht vergleichbar oder exakt so im gesamten Programm.
... ist (teilweise kontextabhängig) im gesamten Programm aktiv. Beim
Eintippen wird der getippte Anteil mit bereits jemals getippten Worten
(alphabetisch sortiert) verglichen (hier muß die Erfahrung zeigen, ob in
der Kartei eine Liste für alle Zeilentypen oder eine Liste je Zeilentyp
besser ist). Der getippte Text wird mit dem ersten Wort komplettiert, das
mit dem getippten Anteil beginnt. Die Komplettierung wird selektiert und
der Cursor bleibt hinter dem zuletzt getippten (also auf dem ersten
komplettierten) Buchstaben stehen. Weiteres Tippen verändert die
Komplettierung entsprechend dem jeweils getippten Anteil. Leertaste und
Interpunktionszeichen entfernen die Komplettierung und beenden das
getippte Wort. ENTER übernimmt den Komplettierungsvorschlag. Weitere
Komplettierungsvorschläge sind per word-wheel wählbar.
... sind natürlich hier, wie überall, aktiv. STRG-M oder STRG-ENTER
führen das soeben getippte Wort als Makro aus.
Je nach Typ des Eintrags sind verschiedene weitere Mechanismen aktiv. In der Kartei (z.B. bei Befund, Therapie und Röntgen, aber nicht in z.B. Anamnese-Zeilen) greift die ...
Bei Beenden eines Wortes (Leerzeichen, Interpunktions-
zeichen, Zeilenende) wird dieses einem Puffer hinzugefügt. Der Puffer wird
darauf geprüft, ob in der Liste bisher jemals eingegebener Diagnosen eine
Phrase beginnend mit dem Pufferinhalt enthalten ist. Bei einem Treffer
wird der Pufferinhalt aufgehoben. Findet sich _kein_ Treffer, wird
das soeben getippte Wort vom Pufferinhalt wieder entfernt und
der Pufferinhalt erneut geprüft. Gibt es jetzt einen Treffer,
wird der Anteil der Zeile, der dem Pufferinhalt entspricht, intern als
“Diagnose” erkannt und optisch markiert. Danach wird der Puffer mit dem
soeben getippten Wort neu begonnen. Gibt es auch ohne das soeben
getippte Wort keinen Treffer, wird das erste Wort des Puffers verworfen
und der Test (ohne/mit getipptem Wort) beginnt erneut. Per Tabulator
ist, sofern man auf einer Diagnose steht, Detailinformation abrufbar:
Man kann natürlich auch Teile des Textes markieren und per ALT-D
zur Diagnose erklären. Solche Diagnosen werden der Diagnosenliste
hinzugefügt. Dabei wird geprüft, ob durch Weglassen von Füllworten
(der, die, das, von, etc.), Ausklammern von Zahlen (_5._ Finger,
Jahresangaben), Übersetzen von Anteilen (“V.a.” <-> “Verdacht auf”,
“Z.n.” -> “Zustand nach”, “bds.” <-> “beidseits”) zu einer vorhan-
denen Diagnose mit ICD-Code gelangt werden kann.
In Zeilen vom Typ “Befund” greifen verschiedene Mechanismen der Befundungsunterstützung. Eine menügesteuerte, baumartige Befundung ist per Tastenkürzel aufrufbar. Eine topologische grafische Befundung (siehe dort für Details) ist ebenfalls so startbar. Von dieser wird ein textueller Kurzbefund zurückgeliefert. Dieser und ein Querverweis auf die Überlagerungsgrafik der Befundung werden gespeichert. Externe Befundungssoftware kann gestartet werden (AODT, MeDOC, o.ä.). Vordefinierte Schlüsselworte rufen Aktionen hervor:
Die Tilde “~” wirkt “magnetisch” auf den Cursor. Bei Einfügen von
Text mit Tilde wird der Cursor auf der Tilde positioniert, diese
gelöscht und getippter Text eingefügt. Enter springt zur nächsten
Tilde und von der letzten zum Ende des eingefügten Textes.
Mit F2 geht es zur Abrechnung. Je nach Stammdaten ist Kasse oder
privat voreingestellt. Weiteres Drücken von F2 rotiert durch die
Abrechnungsarten:
Mittels ALT-S (ALT-F ?) wird bei Kassenpatienten der jeweilige
Schein (Fall ?), also Notfallschein, Abrechnungsschein oder
Überweisungsschein, etc. gewählt. Per ALT-D kann man Diagnosen
aus der Kartei zuordnen, die dann auf Verschlüsselung geprüft werden.
Bei Fehlen wird sofortige Verschlüsselung per Suche/Zuordnung
ermöglicht. Man kann auch gleich weitere Diagnosen eingeben, die
dann auch in die Kartei wandern. Der Abrechnung zugeordnete Diagnosen
sollen mit angezeigt werden. Die Zeilen sollen nach Fallart und
dann chronologisch sortiert werden. Geht man auf eine bestimmte Zeile,
sollen die zum jeweiligen Tag gehörenden medizinischen Karteieinträge
eingeblendet werden. Das Gleiche für den aktuellen Tag bei Anlegen
einer neuen Zeile. Eingegebene Ziffern werden sofort _komplett_ auf
Regelverstöße geprüft.
Mit STRG-F geht es zur Gesamtauswahl der Formulare, wobei die
häufigsten (konfigurierbar) per (SHIFT+)F5/6/7 erreichbar sind
(jeweils Blanko/komplett - je nach Konfiguration).
Für mich auch der wichtigste Punkt! Aus leidvoller Erfahrung weiss ich wie wichtig es ist, bereits hier sorgfältig darüber nachzudenken, was Dokumentation bedeutet. Darüber gehen bekanntermassen die Meinungen sehr auseinander. Was soll dokumentiert werden und wie ?
Hier kommt auch die Frage: wie gebe ich ein, Kürzel, Autotext etc., können, müssen Schlüssel hinterlegt werden, wie finde ich bestimmte Dinge wieder?
Da ich sehr häufig wissenschaftlich arbeite, bin ich darauf angewiesen, aus meinen Patientendaten bestimmte Gruppen (Diagnosen, Prozeduren etc.) wiederzufinden. Das kann aber auch in der “normalen” Praxis nötig und sinnvoll sein. So kann die Kenntnis der Anzahl von z.B. insulinpflichtigen Diabetiker oder chronisch Kranken etc. manchmal vielleicht nützliche Argumentationshilfe gegenüber der KV sein.
Ich kenne prinzipiell drei Eingabemöglichkeiten:
1 Alle Daten kommen nach Datum und Uhrzeit sortiert in ein grosses Textfeld Ähnelt dann der klassischen Akte, und ist wie eine bessere Textverarbeitung.
2 Definierte Felder
Diagnose, Therapie, Medikamente, Befunde (Palpation,Bewegung...) usw. Hier habe ich das Problem, dass ich a priori Felder definieren muss (ich weiss man kann auch später wieder Felder dazufügen) und meine Eingabe ist dann in der Eingabe sehr starr und manchmal hinderlich. Ich untersuche einen Patienten auch nicht starr nach Schema F.
3 My favorite
Ich gebe Freitext mit gewissen Markern ein. Beim Abspeichern setzt das Programm die entsprechenden Passagen um und ordnet sie den Datenbankfeldern zu. Hierbei könnten Standards wie Diagnose, aktuelle Therapie, Röntgen, Sono etc. fest verankert, andere frei definierbar sein.
So würde ein Eintrag in der Akte :
$A Patient klagt seit 3 Tagen über Schmerzen in der re. Hand. Bekannte $DA rheumatoide Arthritis,Gicht,Herzinsuffizienz$DA $A $B DS über A1-Ringband 3 und 4 re $B $D TVS 3und 4 re$D $IM65.3$I $T Injektion mit Cortison und LA$T
zu folgenden Datenfeldern führen:
Patient klagt seit 3 Tagen über Schmerzen in der re. Hand. Bekannte rheumatoide Arthritis, Gicht, Herzinsuffizienz.
DS über A1-Ringband 3 und 4 re
TVS 3und 4 re
Injektion mit Cortison und LA
M65.3
Sicher gibt es da Möglichkeiten, die Eingabe noch einfacher zu gestalten. Man müsste sich nur an feste für alle akzeptable Konventionen halten. Sicher kommen da von den Programmieren noch andere Ideen.
Das Datenbankmodell sollte so offen sein, dass das nachträgliche Einfügen von Feldern möglich ist. Denn in zwei Jahren muss oder möchte ich sicher etwas anderes dokumentieren als ich es heute tue.
Entscheidend ist für mich die erste Zuordnung (Episoden), die es bisher bei Praxis-EDV noch nicht gibt. Diese ist unabhängig vom Datentyp und sollte daher auch getrennt erfolgen. Wer sie nicht braucht, bekommt einfach alle Einträge einem Default-Problem zugeordnet.
Aus meiner Praxis-Erfahrung heraus könnte ich mir z.B. folgende Benutzerschnittstelle vorstellen:
Der Benutzer sieht ein Text-Eingabefeld, z.B. tabellarisch aufgebaut wie die elektronische Karteikarte. Darüber befindet sich ein Aufklappmenue mit dem ersten Eintrag “alle”, danach “neues Problem”, danach die bislang bei dem Patienten definierten Probleme. Dieses Auswahlmenue sollte in den Einstellungen auch abschaltbar sein (dann wird alles default zugeordnet).
Man wählt nun das anstehende Problem und bekommt nur noch die entsprechenden Einträge angezeigt.
Anschließend gibt man seinen Text ein, den man per Tastenkürzel noch einem der Datentypen zuordnet.
Ein anderer Vorschlag wäre, in einer schmalen (abschaltbaren!) Spalte hinter oder vor den Befundeinträgen die Abrechnungsziffern einzugeben oder wenigstens anzuzeigen. Man könnte sich dadurch evtl. eine eigene Maske “Abrechnung” (F2) doch ersparen und sieht vor allem viel besser, ob alle Leistungen auch abgerechnet sind bzw. ob bei abgerechneten Leistungen evt. noch der Befund fehlt (Zuordnung Befund-Abrechung über Datenbank-Relation).
Wenn wir die episodenorientierte Dokumentation unterstützen wollen, sollte man vielleicht zwischen 2 grundsätzlichen Darstellungsarten umschalten können.
Zum einen chronologisch/althergebracht:
- 06.12.2001 - s Patient klagt über Luftnot bei Belastung, in letzter Zeit
zunehmend, kann nur noch 1/2 Etage Treppe steigen.
+ o HT rein, Pulmo frei, leichte US-Ödeme bds.
+ o RR 170/85 P 96
- o EKG: SR, f 88/min, Linkstyp,....
(Link auf Bilddatei)
+ a Rp HCT 25 Tbl. N1
+ s gestern selbst BZ 240 gemessen
+ o gluc 206
+ a Glibenclamid auf 2-0-1 erhöhen
- 12.12.2001 + s Belastbarkeit etwas besser
+ o gluc 160
+ o Beinödeme rückläufig
^
Kategorisierung nach SOAP-Modell (nur als Beipiel, man
könnte auch andere Einträge ermöglichen)
^ ^
2 Knotenebenen (+ und - : Baumknoten)
Zum anderen episoden-/problemorientiert:
- Diabetes mellitus Typ IIb
06.12.2001 + s gestern selbst BZ 240 gemessen
+ o gluc 183
+ a Glibenclamid auf 2-0-1 erhöhen
12.12.2001 + o gluc 160
- Herzinsuffizienz
06.12.2001 - s Patient klagt über Luftnot bei Belastung, in letzter Zeit
zunehmend, kann nur noch 1/2 Etage Treppe steigen.
+ o HT rein, Pulmo frei, leichte US-Ödeme bds.
+ o RR 170/85 P 96
+ o EKG: SR, f 88/min, Linkstyp,....
+ a Rp HCT 25 Tbl. N1
12.12.2001 + s Belastbarkeit etwas besser
+ o Beinödeme rückläufig
^ ^
2 Knotenebenen erforderlich, evtl. eine weitere für das Datum
(Ich glaube, mit diesem kleinen Beispiel wird der Vorteil der problemorientierten Dokumentation schon deutlich. Man stelle sich mal 5 gleichzeitig bestehende Probleme vor...)
Anzeige aller Datenkategorien des Behandlungstages Sortierte Anzeige Datenkategorien (z.B. nur Diagnosen) Auswahlanzeige (z.B. Anamnese., Befund, Dauertherapie) Die Daten der elektronischen Karteikarte sollten jederzeit über das Selektionsprogramm und über die Statistik ausgewertet werden können.
topologische Dokumentation
interaktive, schematische Zeichnungen der menschlichen Figur
Begrenzung auf klinische “Außenansicht”
verschiedene Körperbautypen
Säugling
Kleinkind
Kind
Erwachsener
Senior
Mann
Frau
Dysproportionierung aufgrund bestimmter Krankheiten
kachektisch
schlank
athletisch
adipös
Werkzeug “Vergrößerung”
nur in Stufen
Frontalansicht:
Gesicht
Auge
Werkzeug “Pupillengröße”
Werkzeug “Achsabweichung”
Mund
Nase
Ohr
Gebiß
Rachen
Thorax
Mamma
Abdomen
Inguinalregion
Perinealregion
männl./weibl. sekund. Geschlechtsorgane
Analregion
Werkzeug “Uhr” für das Einzeichen von Hämorrhoiden
Bein
Oberschenkel frontal
Knie frontal
Unterschenkel frontal
Fuß dorsal
Zehen
Arm
Schulter
Oberarm
Ellenbogen
Unterarm
Handgelenk
Hand
Daumen
Finger
Faust
Rückansicht
Nacken
Rücken
Wirbelsäule
Schulter
Lumbalregion
Glutealregion
Analregion
Seitansicht
Schulter
Hüfte
Sprunggelenk
Kopf von oben
Werkzeug “Drehen”
nur stufenweise in “Ansichten”
in jeder Vergrößerungsstufe
falls sinnvoll
bezogen auf jeweilige Region
Sicht von dorsal
Sicht von frontal
Sicht von lateral
Fechterstellung
Sicht von cranial auf Schädel
gynäkologische Sicht
Steinschnittlage (?)
Werkzeug “Ebenen”
in jeder Vergrößerung/Ansicht einblendbar
auch mehrere überlagerbar
nach Einblendung “Aktivierung” von Details möglich
innere Organe
z.B. Druckschmerz, Resistenz, Elastizität, Tastbarkeit, Größe
Muskeln
z.B. Schmerz, Kraftverlust
Gelenke
z.B. Entzündung
Werkzeug: Neutral-Null-Methode
Sehnen
z.B. Riß, Entzündung
Knochen
z.B. Fraktur, Tumor, Entzündung
Dermatome
z.B. Sensibilitätsausfälle
Hautspaltlinien
Fortleitungsorte (Organ <-> Schmerz auf Körperoberfläche)
Körperoberfläche
z.B. Berechnung für Verbrennungen durch Aktivierung
Schemata
altersgruppenabhängig
Lymphknotenstationen
z.B. LKS, Lymphome, etc.
Werkzeug “Notiz”
freie Notizen zu gewähltem Detail
pro Detail vordefinierte Textblöcke auswählbar
Werkzeug “Detail hinzufügen”
Naht
Narbe
reizlos
Keloid
Raumforderung
Entzündung
Schwellung
Rötung
Schmerz
Überwärmung
Hautveränderungen
Blase
Lichenifikation
Atrophie
Ulkus
Varizen
Tumor
Schmerz
Druckschmerz
Berührungsschmerz
auch über “Aktivierung” von Objekten in Ebenen eingebbar
aber auch freie Schmerzlokalisation notwendig
intestinales Stoma
per Zoom auf Teildarstellungen
Werkzeug “Befunderstellung”
XML-Format oder ASCII
generieren von Text aus visuell eingegebenem Befund und Notizen
genealogische Dokumentation
- Dokumentationen
Dokumentationsbedürftige Ziffern. Abfrage muß automatisch bei Ziffer
angezeigt und mit Inhalt vorgegeben werden
(Text, Bild, Video, Audio)
(US, Rö, Scans, EKGs, ...) - in Entwicklung
Zuordnung von Individualbriefen (Befundarchiv)
Dokumentendatenbank
sane (sourceforge) scannen
gocr (sourceforge) OCR
asynchrone Erkennung auf server
Wiedervorlage
wordbox
aspell
- Röntgennummer
Angabe der Röntgennummer und des Befundes
Zugriff auf Bildarchivierung (welche?).
- Bild-Archivierungsprogramm
Anbindung eines Praxisarchiv-Servers mit Scanner und
Datenübernahme verschiedener Bildquellen,
eingescannte Befunde der Kollegen, Röntgenbilder,
Video-Aufnahmen, Digitale Kamera etc. und Zuordnung
zum Patienten.
Diagnosen/ICD
Quartals- und Dauerdiagnosen beim Patienten
maskierbare Diagnosenteile ([xxx])
arbiträre Zuordnungsmöglichkeit von Diagnosentexten und ICD-Codes
keine Anwenderberührung mit ICD (außer Meldung fehlende Zuordnung Code <-> Diagnose)
- Diagnosen
Volltext-Eingabe mit ICD-Dateizugriff und -Übernahme. Eigene Diagnosenstammdatei hinterlegt mit möglichen Abrechnungsziffern und Medikamentenvorschlägen, ICD.
- Dauerdiagnosen
Automatische Zusteuerung zu jeder Abrechnung / quartalsübergreifend ; ICD (Handling wie Diagnosen).
- Diagnosendatei (ICD)
Fachrichtungsbezogene Diagnosendatei mit ICD-Eintrag.
Internat. Classif. of Deseases ICD-Schlüsseldatei.
- Stationäre Angaben: Behandlungsdauer, Krankenhaus, Inhalt KHS-Einweisungsschein etc...
- Therapie: Angaben zur verordneten Therapie / Dauertherapie / Therapiewechsel.
- Vorsorgeuntersuchung: Ergebnisse der Vorsorgeuntersuchung und Hinweise zur Häufigkeit, Recalleintrag.
In einem zweiten Schritt könnte man dann die Formulardruckfunktion und als Grundlage dafür die Patientenstammdatenverwaltung in Angriff nehmen. Hier würde erstmals Genehmigungsbedarf bestehen.
Ein Formulargenerator wäre sicher eine tolle Sache in Anbetracht der regional unterschiedlichen und ständig sich ändernden Formulare. Ideal wäre, wenn jeder Benutzer ein damit selbst generiertes Formular per Mailingliste an andere Anwender verschicken könnte!
Aus meiner Sicht ist der Formulardruck auch zweitwichtigste Priorität. Ein Formulargenerator wäre absolut genial. Insbesondere mit den Möglichkeiten sich mit anderen Anwendern auszutauschen. Was macht man denn den halben Tag: Formulare ausfüllen. Ich warte gerade auf die Formulare für die neue Heilmittelverordnung (seit ca. 3 Monaten). Wenn ich einen Generator hätte wäre die Sache schon 7 Tage vor Termin fertig gewesen.
Beim Formulardruck wäre eine gewisse eingebaute Intelligenz nützlich: So müssten sich häufig wiederkehrende Medikamente, Verschreibungen etc. abrufen und bei Bedarf auch aus einzelnen Bausteinen zusammensetzen lassen. Aber das ist sicher klar.
Frage: Ist ein Arztbrief nicht auch ein Formular? Das bedeutet auch hier müsste es einen Generator geben, der eine Generierung von Standardbriefen mit standadisierten Inhalten aus vorhandenen Daten (siehe Dokumentation) zulässt.
Ein Modul, daß sich um den Formulardruck kümmert. Dies hat zwei Teile: ein Modul fragt die Daten vom Anwender/von der elektronischen Kartei ab. Dieses Modul kann es in mehreren Ausführungen geben: GUI mit Formulardarstellung, Text, Skript (für Massendruck oder Wiederholungsdruck), für Windows, Linux, Mac, ... Das zweite Modul hat eigentlich keinen Schimmer von den Formularen, sondern lädt bloß eine vom ersten Modul erzeugt XML-Datei mit Feld-Inhalt-Paaren sowie weiteren Definitionen (z.B. gesetzlich vorgeschriebener Zeichensatz) und erzeugt daraus meinetwegen ein PDF oder Postscript. Das Ergebnis wird dem Druckerspooler übergeben (das 2. Modul weiß also - abgesehen von der Konfiguration: welcher Drucker wo für welches Formular - vom Drucken überhaupt nichts...) Die Module an sich sollten Open Source sein, die Formulartemplates wiederum wären eine Einnahmequelle für eine Firma - und zu Recht. Wie man schon bemerkt, können die Module auch auf getrennten Rechnern laufen.
unabhängiger Formulargenerator, der per BDT/GDT mit den Praxisprogrammen in Verbindung steht
Drucken
auf lokale Drucker (Formulare)
von lokal auf Netzwerkdrucker (CustoMed)
verteiltes Bearbeiten eines Druckauftrags
lokal vorbereiten (Rezept Sprechzimmer)
in Druckmanager (Applikationsebene) schieben
woanders lokal/im Netz ausdrucken (Rezept Anmeldung)
Formularbearbeitung
Rezept
Kasse/privat/BG/privat auch für Kassenpatienten (Pille)
Zuzahlungsbefreiung automatisch nach Status (Frist, Differenzierung)
Blanko mit/ohne Datum
mit/ohne Medikamente
Anbindung Medikamentendatenbank (arztbezogen/IFAP)
Verordnung von Heil- und Hilfsmitteln
als Kurzattest (= freier Text)
AU
Überweisung
Behandlungsschein
Ersatzverfahren
Notfallschein
Transportschein
Verordnung häuslicher Pflege
Krankengeldbescheinigung
ZUSATZ:
Formulardruck
reportlab
ProForma
GNUe Forms
Blankoformulare von KBV
- Formulardruck / Formulargenerator
Gängige Formulare müssen enthalten sein. Für weitere Formulare, Atteste, muß ein Formulargenerator enthalten sein, über den diese erfaßt werden können (z.B. bei
KV-Bezirks-individuellen Formularen).
Markierung von Werten außerhalb Normbereich:
Individuell veränderbare Reihenfolge der Testergebnisse in Profilen muß möglich sein. Ausgelieferte, vorgefertigte Profile dürfen beim Update praxisspezifische nie überschreiben. Es muß ein Profil “alle Werte” geben. Beim Patienten sollte das zuletzt gewählte Profil eingestellt bleiben.
Alternative: “Intelligente” Sortierung der Testreihenfolge:
Wenn weitere Spalten (Zeitpunkte) mit Labordaten außerhalb des Bildschirms vorliegen: Markierung der betreffenden Zeile mit “>”, “+”, “->” o.ä. am rechten Bildschirmrand
Wenn weitere Zeilen mit Laborwerten unterhalb Bildschirmrand vorliegen: Markierung der betreffenden Spalten mit “Y”, “v”, “V”, “+”, “↓” o.ä. am unteren Maskenrand. Bei pathologischen Werten andersfarbig oder anderes Symbol, z.B. “!”.
Das Laborblatt sollte zwar als vordefiniertes, spezialisiertes Modul die Labordaten anzeigen, diese sollten aber wie andere medizinische Daten so abgelegt sein, daß sie beim Karteikartenfilter “alle medizinischen Daten im Zeitraum” mit auftauchen.
Siehe auch linuxpraxis.multiservers.com/os-pms/pms-main.html unter “Labor”
Unabhängig von der Benennung eines Labortests in einem bestimmten Labor muß in der Praxis die Möglichkeit vorhanden sein, mehrere Testkürzel zu einem Test zu gruppieren. Dadurch können Ergebnisse desselben Parameters aus verschiedenen Laboren (z.B. nach Wechsel des Labors) oder nach Wechsel der Methode und somit der Benennung innerhalb des Labors in einer Zeile angezeigt werden, anstatt mehrere Zeilen zu bilden. Die Normalwerte müssen dabei allerdings je nach Quelle des Ergebnisses gespeichert werden.
Dieses Kapitel gehört z.T. in das Dokument Design.
Testkürzeldatenbank
pro Labor
Labor-ID
Testkürzel in Labor
Testkürzel in Praxis
Normalwerttabellen
Frauen
Männer
Kinder
(Senioren)
(Altersgruppen)
methodenspezifisch ! (also ca. laborspezifisch)
Notiz
praxisintern
Testkürzel in der Praxis
Name des Tests ausgeschrieben
zugeordnete GNR (nur auf LDT anwendbar)
EBM
GOÄ-96
BG-GOÄ
(GOÄ-88)
äquivalente Testkürzel (notwendig ? - da pro Labor schon vorhanden)
Notiz
Normalwertreferenzen müssen zum Laborergebnis zugeordnet bleiben, da mit Wechsel der Analysemethode andere Bereiche vorliegen können !!
In der Datenbank muß also beim Ergebnis eine Referenz auf den Testverfahrensdatensatz vorhanden sein. Testverfahren dürfen dann nie gelöscht, sondern nur als alt markiert werden.
Tabelle “Labortest”
Diese Tabelle stellt die Tests so dar, wie es die jeweilige Praxis wünscht. Auf diese Weise können Tests mit unterschiedlichen Kürzeln aber gleicher Bedeutung (z.B. nachdem man das Labor gewechselt hat oder weil das Labor eine zusätzliche Methode für den gleichen Wert eingeführt hat und den alten Test genauer benennen mußte) zusammengeführt werden.
Diese Tabelle soll in jeder Praxis vorkommen. Natürlich
würde ich niemandem zumuten wollen, diese Tabelle von Hand anzulegen.
Beim Import von Labordaten wird das Kürzel aus der LDT-Datei
genommen. Es wird geprüft, ob diesem laborspezifischen Kürzel
schon eine praxisspezifische Bezeichnung zugeordnet ist. Wenn
nicht, wird dies an Ort und Stelle vorgenommen. Dabei wird das
Kürzel des Labors als Praxiskürzel automatisch vorgeschlagen.
Ebenso die Langbezeichnung, die im LDT mitgeliefert wird. Im
günstigsten Falle bestätigt man nur mit <ENTER>.
Natürlich werden zur Entscheidungsfindung alle Praxiskürzel angezeigt,
die in Kürzel oder Volltext “Hb” oder “Hämoglobin” anzeigen.
Man kann direkt in die Liste der Praxiskürzel zum Suchen
verzweigen. Man kann selbstverständlich immer einfach das
Laborkürzel übernehmen. Dann hat man die herkömmliche
Situation. Mancher mag das sogar immer so wollen und
folglich eine Option in der Konfiguration wünschen (z.b. wenn
man seit Menschengedenken nur ein Labor nutzt).
Tabelle “laborspezifischer Test”
Diese Tabelle beschreibt einen Test, wie er für ein bestimmtes Labor gilt. Es wird die Verbindung zu der Bezeichnung in der eigenen Praxis hergestellt. Die Tabelle kann per ELV-Datei des Labors und/oder per dynamischer Hinzufügung bei Import einer LDT-Datei gefülllt werden.
Ein automatischer Prüflauf kann des Nachts auf dem Server Diskrepanzen zwischen Praxis- und Laborkürzeltabellen ermitteln.
Inwieweit muß man die Normalbereiche weiter differenzieren (Senioren, Kinder, Altersgruppen) ?
> Ich würde es mit den Normalbereichen nicht übertreiben. Es gibt zwar bei
> bestimmten Werten große Abweichungen für bestimmte Personengruppen (z.B. AP
> bei Kindern), aber auch intraindividuelle Schwankungen (Hormone). Der Sinn
> von Normalbereichen ist meist nur eine erste Orientierung oder eine visuelle
> Markierung von Abweichungen. Unser Labor überträgt bei solchen komplexen
> Werten oft einen längeren Kommentartext.
Das ist exzellent zu wissen. Es muß also eher ausreichend Platz für den Laborkommentar in der Tabelle “Laborergebnis” vorliegen.
Tabelle “GNR für Labortest”
Diese Tabelle wird beim Abrechnen von Laborwerten während des Imports benutzt.
> Die GNR werden doch in der LDT-Datei mitübertragen?!
In der Tat, sie haben recht. In der Vorgängerversion des LDT war es noch so, daß nur eine Markierung übertragen wurde, ob dieser Test abgerechnet werden kann. Inzwischen wird die GNR selbst übertragen - immer dann, wenn abgerechnet werden kann.
> Sinnvoll wäre eine solche Tabelle allerdings bei der Korrektur von Fehlern,
> wenn das Labor z.B. mal wieder GOÄ-Ziffern bei einem Kassenpatienten
> abgerechnet/übertragen hat.
Das erleben wir auch hin und wieder. Ich werde also die übertragenen GNR in der Tabelle “GNR für Labortest” sammeln und *bei Abweichung* den Anwender benachrichtigen. Das sollte dann die fehlerhaft übertragenen abfangen.
Tabelle “Laborergebnis”
Diese Tabelle enthält die eigentlichen Ergebnisse. Die letzten beiden Felder erlauben die Rückverfolgung in Problemfällen. Mancher möchte das Abnahmedatum, ein anderer das Datum des Imports.
Tabellen für den Import mit Zuordnungen von Probennummern zu Patienten sind hier noch nicht enthalten.
> Es entstehen auch oft Probleme durch fehlerhafte Zuordnungen Name - > Labor-ID. Das läßt sich leider schlecht automatisch erkennen. Oder haben Sie dazu möglicherweise eine Idee ?
Man könnte einige Plausibilitätsprüfungen vornehmen.
> Hierbei wäre es nützlich, falsch zugeordnete Labordaten noch nach dem Import > vom falschen auf den richtigen Patienten übertragen zu können (falls > KV-konform). OK, werde es vormerken. Hier erweisen sich dann evtl. die Felder “Labor-ID” und “Probennummer im Labor” als nützlich (zum Ermitteln des richtigen Patienten auch nach längerer Zeit).
> Apropos Zuordnung: Die Vergabe der Labor-IDs könnte etwas eleganter vor sich > gehen. Wie wäre es mit einem optionalen Barcodeleser? Den kann man doch auch bei TM anschließen ? Im Prinzip funktioniert das analog einer Tastatur: Der Leser liest und schiebt es in den Computer. Der denkt dann, jemand hätte was getippt und schreibt es an die Stelle, wo gerade der Cursor steht. Das geht dann mit jeder Software, wenn das Betriebssystem einen Treiber für den Barcodeleser hat. Eine elegantere Lösung wäre allerding, wenn die Software anhand des eingelesenen Barcodes selbst entscheiden könnte, was damit zu tun ist. Z.B.: Nummern vom Format “4341zzzzBBzzzzzz” sind immer Labor-IDs (z =3D Zahl, B =3D Buchstabe). Wenn eine solche gelesen wird, erstelle einen Labor-ID-Eintrag mit dieser Nummer. Mancher will dann sofort den Patienten zuordnen, ein anderer einfach den Barcode von der Karteikarte scannern. Hier gibt es viele Möglichkeiten, die bei Bedarf implementiert werden sollten.
Ablauf bei LDT-Verwendung:
- ggf. Entschlüsselung (KBV-Kryptomodul)
- Plausibilitätsprüfung
- ist einsendendes Labor in Praxis schon bekannt ?
- Neuanlage des Labors anbieten
- absendendes Labor anzeigen
- Adressaten (empfangenden Arzt) anzeigen
- fast nur Sichtprüfung durch Anwender sinnvoll
- Lesen eines Datensatzes
- betreffenden Patienten bzw. ID-Nummer anzeigen
- Prüfung, ob Datensatz identifizierbar
- Zuordnung Nummer <-> Patient oder Datensatz enthält Patientennamen
- Nummer kann in verschiedenen Feldern stehen
- nicht identifizierbar:
- Hinweis an Nutzer
- Zuordnung ad hoc anbieten:
- Verzweigung in Patientensuchfunktion der Praxisdatenbank
- bei Nichtzuordnung Übertragen in “LDT-Warteliste”
- wird beim nächsten Import erwähnt
- nach Zuordnung auch Patientennamen anzeigen
- Lesen eines Testergebnisses
- Konfiguration Zeitpunkt für Ergebnis: Abnahme Probe, Eingang Labor, Zeitpunkt Ergebnis, Zeitpunkt Import
- ggw. bearbeiteten Test mit Datum anzeigen
- Kürzel noch nicht in laborspezifischer Liste:
- Identität von “Kürzel”, “Bezeichnung” und “Normbereich”
- Hinweis an Nutzer
- Suche/Darstellung evtl. passender Kürzel in vorhandenen Kürzeln
- Abfrage, ob “neues Kürzel” oder “geändertes Kürzel”
- neu: neu anlegen
- geändert: neu anlegen, aber in Gruppe des alten Kürzels in praxisspezifischer Liste aufnehmen
- Import relevanter Felder (Normalwerte, Bezeichnung, etc.)
- Kürzel noch nicht in einer Gruppe der praxisspezifischen Liste:
- Hinweis an Nutzer
- Suche/Darstellung evtl. passender Kürzel in vorhandenen Kürzelgruppen
- Zuordnung zu oder Neuanlage einer Kürzelgruppe durch Nutzer
- Import relevanter Felder (Bezeichnung, etc.)
- Verzweigung in Datenbank bei fehlenden Feldern
- Prüfung, ob zu importierende Testdaten schon beim Patienten vorhanden
- Identität von Datum, Test und Ergebnis
- Nutzerabfrage bei schon vorhandenen Daten, ob trotzdem importiert werden soll
- importieren
- pathologische Werte auf Sammelliste vermerken
- Vermerk in Zuordnung Proben-ID/Patient über Status
- Teilbefund
- Endbefund
- Prüfung, ob ggw. bearbeitetem Test GNr zugeordnet ist
- je nach Versicherungsart des Patienten GOÄ/EBM
- GNr fehlt:
- Nutzerabfrage und ggf. Verzweigung in EBM/GOÄ-Datenbank
- Prüfung, ob zu importierende GNr. mit laborspezifisch für diesen Test gespeicherter GNr. übereinstimmt
- ggf. Korrektur anbieten
- Korrektur der gespeicherten GNr.
- Korrektur der zu importierenden GNr.
- Prüfung, ob zu importierende GNr. schon abgerechnet wurde
- Identität von Datum und GNr
- Nutzerabfrage bei schon vorhandenen GNr mit Anzeige vorhandener + Datum
- importieren
- Löschen aller Zuordnungen Probe/Patient mit Status “Endbefund”
- Nutzerabfrage
- Konfigurationseinstellung
- Löschen der Importdatei
- Archivierung bereits nach Übertragung
- Sammelliste “pathologische Werte” bearbeiten
- wenn pathologische Werte vorhanden
- Abfrage, ob angezeigt/gedruckt werden soll
- keine pathologischen Werte
- Hinweis an Nutzer
Formate
LDT
verschlüsselt
unverschlüsselt
Zertifizierung erforderlich
Pflichtformat
Textformat der KBV
www.kbv.de -> xDT
seit 1997 vorgeschrieben
(Bonner Modell)
obsolet
ggf. für alte Gerätesoftware
offiziell nicht mehr zulässig
andere
sollten vor Import in LDT konvertiert werden
ELV
Übermittelung von Testkürzeln, etc. durch das Labor
Beim Importieren von Labordaten mit Patientennamen (z.B. O-III) sollte eine Zuordnung Probennummer <-> Patient nicht zwingend erforderlich sein. Bei ambivalenten Patientendaten (mehrere passende) muß beim Anwender mit Auswahl nachgefragt werden, z.B. so:
“Die Laborwerte für HBA1c, HS, GLU, HB vom 11.11.2004 aus dem Labor TESTLABOR sollen für den Patienten Musterfrau, Ilona, geb. 11.11.1999 importiert werden. Folgende Patienten aus meiner Datenbank passen auf die Patientendaten des Labors. Bitte wählen Sie den richtigen Patienten aus !”
Labor
mögliche Abläufe
Probenaufkleber werden vom Labor ausgegeben,
oft mit Barcode,
oft mit arztspezifischer Nummer (Arzt-ID)
immer mit lfd. Probennummer
Probe wird abgenommen und mit Aufkleber versehen,
Nummer des Aufklebers wird beim Patienten vermerkt,
Probe mit Aufkleber geht ans Labor
anonym: nur Probe und Nummer
nicht anonym: explizite Anforderung per Formular
Zuordnung Patient-Probe-Anforderung
zu erfassen:
Patient
zugehörige Probennummer
Erfassungsmöglichkeiten
Barcodeleser
Proben-ID vom Aufkleber,
Patienten-ID von Karteikartenaufkleber,
Tastatur
manuelle Eingabe
Übernahme aus Praxisdatenbank
als ID-Nummer
OIII-Labore: meist anonym
namentlich
Mikrobiologie, etc. meist namentlich
wenn mit Ü-Schein,
manche Laborgeräte
“automatisch” von “intelligenten” Laborgeräten vor Ort
z.B. Clinitek 100,
manche Geräte liefern den Namen (und ggf. die ID) mit
KVK-Lesegerät
logische Trennung
wichtig wegen Zuordnungskollision
je Arzt
je Labor, an das Proben versandt werden
Fremdlabore
Eigenlabor (Geräte)
Ein Terminkalender für Patiententermine soll eine offene Schnittstelle haben,
umd den Abgleich mit persönlichen Terminplanern (zum Beispiel auf PDAs) zu
ermöglich.
Es sollte eine Integration zwischen Warteliste (was eigentlich ist das Anderes
als die Seite “Heute” des Terminkalenders ... ?) und Terminkalender vorhanden sein.
Es müssen Ressourcenbeschränkungen berücksichtigbar sein:
- Räume
- Geräte
- Ärzte
Es wäre sicher interessant, wenn sich Patienten einige Termintypen per WWW
oder per Sprachcomputer am Telefon selbst geben lassen könnten. Dabei muß
es möglich sein, daß ein Termin bei Überschreiten von Ressourcenanforderungen
(Zeit, Kosten) erst von einem Praxismitarbeiter endgültig bestätigt werden muß,
woraufhin dann eine Zusagebenachrichtigung z.B. per SMS oder E-Mail an den
Patienten gesendet werden könnte.
Herr Dr.Streller schrieb folgende Kritik zum Terminplaner von TurboMed@Windows:
* Es ist bei der Terminvergabe nicht vorher erkennbar, dass bestimmte
Termine nicht vergeben werden können, weil die entsprechende
Ressourcengruppe bereits anderweitig belegt ist (Sehr ärgerlich
im Patientenkontakt: Oh tut mir leid der Termin ist doch nicht möglich....).
* umständlicher und nicht skalierbarer Ausdruck der Terminzettel;
Bemerkung wird nicht gedruckt.
* Termine sind in der Übersicht unter Umständen nicht sichtbar,
wenn nicht der betreffende Tag angeklickt wird.
* Steht der Terminpatient an der Anmeldung wird nicht sofort
darauf hingewiesen, dass dieser Patient einen Termin hat -
Geschweige denn welche Termine
* Es erfolgt (daher) auch keine automatische Übernahme der
Terminbemerkung beim Eintrag in eine Warteliste
* Eine generelle Sperrung von allen Termin im Voraus
(wie z.b. vor Praxisurlaub) ist nicht möglich
* Ein mehrfach verschiedene Terminlänge ist nicht realisierbar
* Eine generelle Sperrung bestimmter Termine (z.B. 10:15
Teepause o.ä.) bzw. von Pufferterminen ist nicht möglich
* Es ist nicht möglich bestimmte Termine erst zu einem
bestimmtem Zeitpunkt vor der Vergabe freizugeben (Akuttermin
frühestens 24h vor Vergabe freigegeben)
* Es können Termine vergeben werden, die eigentlich nicht
existieren ( Versuchen Sie mal an einem tag mit vollen TK
einen Termin zu vergeben (-> Terminvergabe zum gewünschten
Zeitpunkt nicht möglich; möchten den den nächsten freien
Termin um 23:00 Uhr vergeben...?)
Herr Dr.Elisat stellte folgende Kriterien auf:
Da ich mich mit dem Problem seit längerer Zeit beschäftige möchte
ich für die Kolleginnen und Kollegen, die sich mit dem Gedanken
tragen, eventuell einschlägige Software einzusetzen, einen Katalog
an sinnvollen Funktionen und Möglichkeiten, die ein solches
Programm haben sollte, in dieses Forum stellen. Vielleicht hilft
es, die Auswahl zu erleichtern.
Natürlich ist und bleibt die Rezeptionskraft mit
zwanzigjähriger Praxiszugehörigkeit, die jeden
Patienten und seine Eigenheiten kennt, das
Nonplusultra. Aber wenn die einmal länger krank wird,
doch noch heiratet und wegzieht, in Rente geht
oder... Lieber nicht daran denken. Dann ist
vielleicht ein adäquates Programm doch eine große
Hilfe. Ich meine jedenfalls, daß die Terminvergabe in
ärztlichen und zahnärztlichen Praxen eine Tätigkeit
ist, die durch eine sachgerechte EDV-Lösung
wesentlich verbessert und erleichtert werden kann.
Qualitativ: Die vom Behandler für den Termin
gemachten Vorgaben werden exakt eingehalten, die vom
Patienten gewünschten (geforderten) Optionen werden
bestmöglichst berücksichtigt, umfassende
Informationen über den Patienten, der einen Termin
nachfragt, stehen bei jeder Terminvergabe zur
Verfügung. Aus diesem Grund ist ein solches Werkzeug
interessant für jede Praxis.
Quantitativ: Eine Kraft kann problemlos wesentlich
mehr Termine (für mehr Behandler) korrekt verwalten,
wenn ein gutes Terminvergabeprogramm benutzt wird.
Aus diesem Grund ist ein solches Werkzeug sinnvoll
für große Praxen bzw. Praxisgemeinschaften.
Ohne Zweifel hat die gelungene Terminvergabe einen
extrem wichtigen, in der Regel aber stark
unterschätzten Einfluß auf den Praxisablauf. Hier
sollen nur der Imagegewinn der Praxis, der sich aus
kurzer Wartezeiten für die Patienten ergibt, und die
wesentlich geringere Belastung des Praxisteams
infolge des gleichmäßigeren Arbeitsflusses erwähnt
werden.
Um diesen Effekt zu erreichen, sind an das
Terminvergabeprogramm einige Forderungen zu stellen,
ohne deren Realisierung Terminmanagement Stückwerk
bleibt.
- Einfache Bedienung und automatische schnelle und
zutreffende Terminvergabe den Wünschen des Patienten
entsprechend, um diese Tätigkeit zu erleichtern und
auch weniger qualifiziertem Personal zugänglich zu
machen.
- Gute Übersichtlichkeit und schnelle
Suchalgorithmen, um Terminüberschneidungen,
Anschlußtermine (bei mehreren Behandlern, einmal
kommen, zwei Termine wahrnehmen) und Kettentermine
vergeben zu können.
- Notizbuch- und Wiedervorlagefunktion für die
Patienten, damit der aktuelle Informationsstand für
alle Mitarbeiter nutzbar wird.
- Durchgehende Benutzerkontrolle für alle Aktionen,
um Fehlbedienungen zuzuordnen und abstellen zu
können.
- Uneingeschränkte Mehrplatzfähigkeit für dezentrale
Terminvergabe in den Sprechzimmern und in großen
Netzwerken.
- Direkter Zugriff auf die Stammdaten des
Abrechnungsprogramms, um Doppeleingaben und
zusätzlichen Aufwand zu vermeiden.
Im Einzelnen sollten folgende Merkmale vorhanden
sein:
Frei definierbare Vorgaben für jeden Behandler:
a) Der Zeitraum, in dem das Programm nach freien
Terminen sucht, sollte etwa im Bereich von 30 bis 365
Tagen einstellbar sein.
b) Arbeitszeiten sollten für jeden Tag
unterschiedlich mit mindestens zwei Pausen für jeden
Wochentag definierbar sein.
c) Behandlungsarten müssen für jeden Behandler mit
zugehöriger Vorgabedauer (Defaultzeit) individuell
einstellbar sein. Während der Terminvergabe muß diese
Vorgabezeit problemlos variiert werden können.
d) Außerdem muß es möglich sein, bestimmten
Behandlungen bestimmte Sprechzimmer zuzuweisen, weil
möglicherweise nur dort notwendige Geräte etc. für
diese Behandlung zur Verfügung stehen. Diese Vorgaben
müssen bei der automatischen Terminvorgabe abgeprüft
werden. (exklusive Zimmer- bzw. Ressourcenzuordnung)
e) Um “Zwischendurchtermine” wie z.B.
Schmerzpatienten etc. verwalten zu können, sollten
Sammelblöcke an beliebigen Stellen der
Behandlungszeit realisiert werden können. Hier kann
man manuell Kurztermine eintragen. Bei der
automatischen Terminvergabe werden diese Zeiten nicht
berücksichtigt.
f) Fehlzeiten (Urlaub, Fortbildung...) unter
automatischer Berücksichtigung der gesetzlichen
Feiertage müssen für jeden Behandler beliebig
einstellbar sein.
g) Für gelegentlich außerhalb der normalen
Arbeitszeit anfallende Behandlungen sollten
Sonderzeiten anlegbar sein.
Schichtarbeitszeitregelungen sollten über das
wöchentliche Wechseln der Arbeitszeiten hinaus
möglich sein (mindestens drei unterschiedliche
Wochenarbeitszeiten in beliebiger Reihenfolge und mit
beliebigem Wiederholungsintervall).
Umfassende Bearbeitungsfunktionen:
a) Grundsätzlich müssen alle Möglichkeiten bei der
Terminvergabe vorhanden sein, die auch bei Benutzung
von Terminkladde, Bleistift und Radiergummi genutzt
werden können. Daher ist die Vergabe von Primär- und
Sekundärterminen zur Realisierung von
Terminüberschneidungen und Doppelbelegungen
unerläßlich.
b) Den größten Nutzen bringt die automatische
Terminsuche nach allen denkbaren Vorgaben wie vom
Patienten gewünschte Auswahl der ihm genehmen Tage
und Uhrzeiten sowie Termine nach/vor einem bestimmten
Datum. Für den Fall, daß automatisch kein freier
Termin gefunden werden kann, muß jederzeit auf die
manuelle Vergabe gewechselt werden können.
c) In Praxen mit mehreren Behandlern ist die
automatische Behandlererkennung bei der
Patientenauswahl obligatorisch (setzt voraus, daß das
Abrechnungsprogramm eine eindeutige
Behandlerzuordnung erlaubt).
d) Sind mehrere Behandler vorhanden, die
möglicherweise auf Grund von Spezialisierung
gemeinsam einen Patienten versorgen, so muß eine
automatische Anschlußterminvergabe bei einem zweiten
Behandler unter Berücksichtigung einer maximalen
Wartezeit zum Vortermin möglich sein.
e) Bestimmte Behandlungen laufen in mehreren
Sitzungen nach einem gleichbleibendem Schema ab.
Diese Behandlungen müssen zum Gegenstand einer
Kettenterminvergabe von maximal sechs
Einzelbehandlungen unter Berücksichtigung minimaler
und maximaler Abstände zu den Vorbehandlungen gemacht
werden können.
f) Besonders wichtig: Nach erfolgter
Kettenterminvergabe das perfektes Handling
(Neuvergabe, Verlegen, Löschen einzelner oder
mehrerer Termine) der verbleibenden Terminkette, wenn
es im Zuge der Behandlung zu Terminverschiebungen
oder Terminversäumnissen durch den Patienten oder
Behandler kommt.
g) Kann einem Patienten aktuell kein ihm genehmer
Termin gegeben werden, so muß er in einer Warteliste
gespeichert werden können, damit, falls andere
Patienten Termine absagen, diese angeboten werden
können.
h) Das Löschen und Verlegen von Terminen sowie die
Verlängerung/Verkürzung der Einbestellzeit muß
einfach und schnell zu bewerkstelligen sein.
i) Auf einer Bildschirmseite des Monitors sollte die
gesamte grafische Tagesanzeige für einen Arbeitstag
angezeigt werden können. Dabei muß der Zeitraum von
mindestens acht Stunden bei einem minimalem Intervall
(= kleinste Zeiteinheit = kürzester Termin) von fünf
Minuten dargestellt werden können.
j) Unverzichtbar ist das automatische Erstellen von
“Kollisionsdatenbanken” für Termine, die nach Eingabe
von Fehlzeiten oder durch Änderung der Arbeitszeiten
verlegt werden müssen. Die Bearbeitung solcher
Ereignisse muß schnell und einfach vorgenommen werden
können. Dazu gehören die telefonische
Benachrichtigung des Patienten mit direkter Verlegung
bzw. Löschen des Termins und die schriftliche
Benachrichtigung der nicht telefonisch erreichbaren
Patienten über eine Serienbrieffunktion.
k) Natürlich muß bei Rücknahme der eingetragenen
Fehlzeit die Rekonstruktion der Termine aus der
Kollisionsdatenbank, soweit sie nicht schon gelöscht
oder verlegt wurden , möglich sein.
l) Für die Patienten müssen sowohl Bemerkungen als
auch Wiedervorlagen angelegt werden können. Nach
diesen zusätzlichen Informationen zum Patienten muß
nach zeitlichen und inhaltlichen Vorgaben gesucht
werden können.
m) Weiterhin soll die Anzeige von Bemerkungen und/
oder Wiedervorlagen vor einer Terminvergabe
automatisch erfolgen können. Wichtig sind die
Wiedervorlagensuche bei Programmstart und beliebig
erweiterbare Textbausteine für sich wiederholende
Eingaben.
n) Nötig sind ferner umfangreiche Druckfunktionen für
Etiketten, Terminzettel, Terminbuch, Reportlisten,
Kalenderfunktion mit Anzeige von Feiertagen,
Fehlzeiten und Terminvorgabezeiträumen, sowie ein
kontextbezogenes Hilfesystem.
Sicherheits- und Kontrollfunktionen:
a) Passwortschutz und Zugriffsregelung durch
abgestufte Benutzerrechte. Ob der Benutzer die für
eine bestimmte Aktion erforderlichen Rechte besitzt,
sollte durch die Abfrage eines nur dem speziellen
Benutzer bekannten Kürzels erkannt werden können
(alternativ sollten Fingerabdruckscanner bzw. Karten
nutzbar sein). Es ist jederzeit nachvollziehbar,
welcher Mitarbeiter einen Termin vergeben, zuletzt
bearbeitet oder andere Daten verändert hat.
b) Umfangreiche Plausibilitätsprüfung aller
relevanten Aktionen zur Vermeidung von Fehleingaben.
c) Außerordentlich wichtig: “Crash-Programm” zum
Erstellen einer weiterverwendbaren Terminkladde bei
einem Komplettausfall der EDV-Anlage durch Ausdrucken
auf einem beliebigen anderen Computer mit den Daten
der Datensicherung von Diskette oder Zip-Medium.
d) Zugriff auf Termine aus der Vergangenheit und
statistische Aufbereitung erfaßter Daten.
Die hier aufgeführten Eigenschaften beschreiben den
notwendigen Funktionsumfang. Ohne Zweifel sind noch
viele Möglichkeiten da, weitere Aufgaben zu
integrieren und bestehende zu erweitern.
Herr Dr. Bauer merkte an:
Ich suche für meine kardiologische Bestellpraxis einen Terminplaner
mit für jedes Sprechzimmer taktbarer Zeiteinteilung, automatischer
Ablaufplanung für Neu- oder Kontrollpatienten und besonders wichtig
mit Recallsystem. D.h., der Terminplaner schreibt mir automatisch
die Terminerinnerungsschreiben für einen bestimmten Zeitraum für die
eingetragenen Neu- oder Kontrollpatienten. Aufgrund einer langen
Warteliste kommen leider zu viele Patienten zu dem vereinbarten
Termin nicht, was phasenweise ein echtes Problem ist. Mit einem
automatischen Recall- oder Terminerinnerungssystem wäre dieses
Problem gut zu beherrschen.
Falls dann noch der Terminplaner eine Statsitik-Möglichkeit hat
und mir sagt, ob ich in meinem Budget mit meiner Planung bin, wäre
das natürlich das i-Tüpfelchen.
ZUSATZ:
Bestellsystem/Terminkalender
MDSchedule (OIO)
RFC für Scheduling/Calendaring
- Tagesliste / Tagesprotokoll / Tagesstatistik
zum kompletten Überblick zum Tagesgeschehen in den verschiedenen Praxisbereichen,
Überblick über die Vollständigkeit der eingetragenen Leistungen mit Direktsprung
zu gelisteten Patienten
Im Wesentlichen sollen Medikamentendaten zwei Zielen dienen:
Rezeptiert werden die verschiedensten Dinge:
Zum Verschreiben von Medikamenten braucht man mindestens folgende Angaben:
Für diese Daten sind regelmäßige Erneuerungen notwendig, am besten über das Internet, etwa 14-tägig.
Weitere bedeutsame Angaben:
Verschiedene Mechanismen erleichtern das Rezeptschreiben ungemein:
Hier müssen Entwicklungen wie elektronischer Medikamentenpass und Generika-/aut-idem-Regelung im Auge behalten werden.
Die grundlegendsten Medikamentendaten für diesen Bereich sollten halbwegs zumutbar zu beschaffen sein, immerhin sind die Pharmafirmen ja daran interessiert, daß ihre Produkte verschrieben werden. Hier muß man ggf. auch Schnittstellen zu existierenden kommerziellen Datenbanken schaffen.
Für den Anwender ist es sehr hilfreich, wenn für die verfügbaren Arzneimittel weiterführende Informationen zum Abruf bereitstehen. Diese dienen dann einer detaillierten Therapieentscheidung und auch zur Information über von anderen Ärzten verordnete Medikamente.
Nicht alle Informationen müssen vor Ort gespeichert sein. Bestimmte Dinge können einfach mit dem Internet verlinkt werden, beispielsweise komplette Monographien.
Für Medikamente wären das
Aber auch andere Informationen sollten im Programm nahe der Rezeptfunktion zu finden sein, so etwa eine Liste der Zuordnung Leistungsnummer <-> Verfahren bei der Physiotherapie für BG-Fälle oder der Leistungskatalog für besondere Heilbehandlung bei BG oder auch der Heil- und Hilfsmittelkatalog bei Kassenbehandlung.
Ich wünsche mir _eine_ Taste zum Aufruf einer Verordnung. Z.B.
bedeutet F5 immer “Rezept starten”. Danach erscheint ein
kleines Menü:
.----------.
| 1 Normal | (= Kasse/Privat je nach Patient)
| 2 BG |
| 3 Privat | (nur bei Kassenapatienten)
`----------'
Die Typen sind mit der Zahl oder dem Buchstaben aufrufbar oder mit dem Balken über die Pfeiltasten auswählbar. Also:
F5+1 -> normales Rezept für diesen Patienten (entweder Kasse oder Privat) F5+n -> -- ” -- F5+Enter -> -- ” --
In dieser ersten Menüzeile wird in Klammern angezeigt, was für diesen Patienten “normal” bedeutet “= Kasse” oder “= Privat”.
Mancher wird bevorzugen, daß die Zeile “BG” nur dann angezeigt wird, wenn auch ein offener BG-Fall existiert. Andere werden bevorzugen, diese Möglichkeit immer zu haben, sodaß bei Auswahl derselben der offene BG-Fall aktiv wird, ein geschlossener wieder geöffnet oder ein neuer angelegt wird (muß im Einzelfall jeweils abgefragt werden). Bei Neuanlage sollte die Wahl der BG natürlich gleich für den H-Arzt-Bericht nutzbar gespeichert werden.
Die letzte Zeile macht natürlich nur bei Kassenpatienten Sinn (Pillenrezept, etc).
Man kann als Alternative zum Weglassen von nicht-zutreffenden Zeilen diese auch graumeliert und nicht wählbar anzeigen. Insbesondere bei Auswahlmöglichkeit über Ziffern ist das sinnvoll, um die Zuordnung von Rezepttyp zu Auswahlziffer zu erhalten.
Ein Blanko wird folgendermaßen gedruckt:
F5 + 1/n Enter> + STRG-D (bzw. eben die Taste zum Auslösen
des Drucks) -> Abfrage, ob mit oder ohne Datum/Stempel.
Die Unterscheidung in “Medikamente”, “Physiotherapie”, “Ergotherapie”, “Logopädie” und “Bescheinigung” wünsche ich mir erst bei der eigentlichen Auswahl des Rezeptinhalts. Die Einträge in der patientenspezifischen Liste der bisherigen und der arztspezifischen bevorzugten Verordnungspunkte sind markiert als “Medikament” oder “Physiotherapie” etc. Bei Wahl eines Eintrags werden die anderen Eintragstypen für die Auswahl für dieses Rezept gesperrt, sodaß auf ein Rezept nur gleiche Typen gelangen können. Das Formular stellt sich angepaßt auf den Typ des Eintrags etwas unterschiedlich dar. Physiotherapie als BG-Leistung sollte über sprechende Einträge mit Hinterlegung der Leistungsnummer wählbar sein.
Bei Verordnung von mehr als drei Medikamenten entstehen automatisch mehrere Rezeptdruckaufträge.
Man kann auf SHIFT-F5, ALT-F5 und STRG-F5 ja noch häufige
Rezeptuntertypen legen.
Es müßte sich konfigurieren lassen, ob standardmäßig der Stempel eingedruckt werden soll oder nicht.
MATERIAL:
Eine Medikamentendatenbank. Diese muß immer sehr aktuell sein, daher ist die Datenlieferung wieder eine kommerzielle Angelegenheit - zu Recht. Zwischenupdates natürlich wie bei IFAP übers Internet. Dieses Modul könnte nun entweder eine Black Box (ein Rechner) im LAN sein, dem man über ein offenes Protokoll Anfragen schicken kann (Medikamente abfragen, NW, WW, Zusammensetzung, Kontraindikationen [Aktualität !! Ich sage nur: Betablocker und Herzinsuffizienz !], ATC, PZN, ...) und der kostenpflichtig auf dem neuesten Stand gehalten wird oder ein binär geliefertes Programm, daß die Finanzierung über Werbung der Pharmaindustrie ermöglicht (wie zur Zeit beim IFAP).
für die Medikamentendatenbank gibt es mehrere Möglichkeiten:
AMIS: vom Bundesamt für Arzneimittel über DIMDI und KBV verfügbar. Hat ausreichend Inhalt, ist ausreichend strukturiert und die Struktur ist offengelegt. Kostet rund 20 TDM als Einmallizenz (zahl- bar in 2 TDM Raten pro 100 gemeldete Nutzer, erste Rate bei Lieferung) und dann pro Anwender pro Quartal zwischen 20 und 30 DM. Hat keine Oberfläche, soweit ich weiß.
IfAp: Dann gibt es den IfAp-Index. Er ist weitverbreitet und ist gut aufbereitet. Er hat eine Oberfläche für DOS und eine für Windows. Er läuft im DOSemu (mit leichten Unbequemlichkeiten für den Administrator). Diese Datenbank finanziert sich aus Werbeeinnahmen von der Pharmaindustrie. Daher (auf Nachfrage) werden Quellcode und Datenformat nicht herausgegeben. Pluspunkt: Kann per Internet aktualisiert werden. Negativ dabei: laufend wird die URL der Updates geändert und das Einspielen der Updates enthält derzeit noch keine Versionskontrolle mit (Erfahrungswert) Datenkorruption bei Fehleinspielen.
Das Problem bei einer pharmagesponsorten Datenbank ist, daß die Sponsoren versuchen werden, sich nicht nur visuell, sondern auch programmlogisch zu verewigen. Mithin wird es wesentlich leichter sein, ihre Produkte zu finden und auszuwählen als die der Konkurrenten. Hinweis: Beim IfAp ist das m.W. noch NICHT so, was sehr für den IfAp spricht (moralisch zumindest).
Medikamentendatenbank
Das Dateiformat BDT wird häufig gescholten, weil es nicht alle Details für den Export vorhandener Daten festlegt. Dies ist durchaus richtig. Ein Nachteil muß das dennoch nicht sein.
Computer verstehen den Inhalt medizinischer Daten derzeit sowieso noch nicht. Eine vollständige, korrekte, automatische Konvertierung von Daten aus Programm A nach Programm B ist mithin nicht möglich.
Nichtsdestotrotz versteht der Arzt medizinische Angaben, auch wenn diese nicht von einer Software vorklassifiziert sind.
Es soll also folgendes Verfahren angewandt werden:
Im BDT bekannt richtig klassifizierte Daten (Stammdaten, Kassenzugehörigkeit) sollen direkt an die richtige Stelle importiert werden. Andere Daten, die nur mit großem Aufwand und nahezu für jede Praxis individuell vorzuverteilen wären, werden bei Aufruf eines Patienten einfach als "noch nicht importierte Altdaten" mit allen verfügbaren Metadaten (BDT-Zeilentyp, BDT-Zusammengehörigkeit) angezeigt. Der Arzt kann dann einzelne Einträge auswählen und den Typ der Daten (Cave-Eintrag, Hausarzt, Allergie, Notiz, Angehöriger, etc.) angeben. Derart markiert werden die Daten an die entsprechende Stelle importiert und aus der Liste noch nicht importierter Daten gelöscht.
Günstig wäre ein Serverprozeß im Hintergrund, der bei Stecken einer Chipkarte diese sofort liest und sich merkt. Anwendungen überwachen eine Semaphore oder Pipe und lassen sich so vom KVK-Server über das Einlesen informieren. Die Applikation entscheidet dann selbst, ob bei Einlesen sofort ein bestimmter Programmteil aufgerufen werden soll, ob die Karte nur in einer Liste gespeichert werden soll oder ob bestimmte Hintergrundaktionen ausgelöst werden sollen.
Das hätte den Vorteil, daß der Server selbst keine Zwischenspeicher