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 Zwischenspeicherung vornehmen muß.
KVK
Cherry-Tastatur
andere Lesegeräte
Suchen von Patienten mit KVK
automatisch Markierung “vorgelegt” bei Suche
Kreuzprüfung KVK-Daten <-> Stammdaten in Datenbank -> Update bei Differenz
KVK-Gültigkeitsprüfung
neuen Patienten anlegen mittels Einlesen der KVK (im Dienst)
Kartenterminals
CT-API
KVK - zunächst am wichtigsten
Tastaturen
Cherry
braucht Kernelpatch zum Ansteuern
unterstützt read-on-insert wahrscheinlich nicht
Preh Commander
beide “zertifiziert”
serielle Geräte
einheitliche API (CT)
wenige Modelle
einige Modelle “zertifiziert” -> Gesetzeslage ?
viele andere Billigmodelle z.B. bei Conrad
mobile Geräte
seriell anschließbar
per Adapter-KVK an normales Gerät anschließbar
verhält sich wie normale KVK beim Lesen
Batchmodus zum Einlesen unterstützen !
kvk-server
speichert gelesene Daten als XML,
sysctl, CLI, pipe,
--demon
startet sich als demon,
liest Daten, sobald Karte gesteckt,
--read-kvk
CLI-Interface für direktes Lesen einer Karte,
--quit
stoppe demon
--reload
lade Konfiguration neu
API
identify
liefere Identifikation (XML)
Version
Gerät + Version
Schnittstelle
get-kvk
liefert ersten vorhandenen Datensatz
setzt “geliefert”-flag
delete-kvk
löscht ersten vorhandenen Datensatz
“geliefert”==true -> löschen
“geliefert”!=true -> “force”==true -> löschen
delete-all
löscht alle vorhandenen Datensätze
“geliefert”==true -> lösche
“geliefert”!=true
“force”==true -> lösche
“force”!=true -> return error
read-kvk-now
versuche jetzt, eine KVK aus dem Gerät einzulesen
Kreditkarten
HCPP
HBCI
PAM
Medizinische Speicherkarten
- CHIP-Karten-Anschluß
Software und Hardware sind auf die von der KV gelieferten Lesegeräte bzw. Drucker eingestellt - Verarbeitung der verschiedenen Karten (KVK und PKA).
Patientendaten sollten in einem robusten Datenbankmanagementsystem (DBMS) gespeicherte werden. An weitesten verbreitet sind heutzutage relationale Datenbanken mit der Abfragesprache SQL. Die Fähigkeiten der Datenbank sollten die auf der Webseite www.de.postgresql.org/features.html aufgeführten Eigenschaften nicht unterschreiten.
Darüber hinausgehend sollte die Datenbank online gespiegelt werden können und ein detailliertes Logging von Anfragen bieten. Mit einem solchen Log in Verbindung mit einem digitalen Notar ist das medizinrechtliche Auditing relativ sicher realisierbar. Ein weiterer wünschenswerter technischer Aspekt wäre die Unterstützung von automatisch auf Datenbanken aufgeteilte SQL-Anfragen.
Besonders wichtig in einer medizinischen Einrichtung ist die Möglichkeit, während des laufenden Betriebs eine konsistente Datensicherung vornehmen zu können.
3.7 Verarbeiten von Text
________________________
Eine Textverarbeitung. Gibt's zuhauf für Linux. Braucht ggf. einige
Erweiterungen, um komfortabel Platzhalter aus der Praxis-EDV zu
unterstützen und zum skriptgesteuerten Erstellen von Arztbriefen,
Befundberichten, ...
Textverarbeitung
Platzhalter für Patientendaten
Arztbriefschreibung
LaTeX
LyX
Abiword
Schnellbrief
LDAP - Arztadressen von KBV als xDT
GNOME/KDE: Wizards
Shellskripte
XV
Unterschrift mit GPG abgelegt
aspell
- On-Line-Textverarbeitung
Per Knopfdruck ! Überleitung zum Textprogramm aus den Behandlungsdaten heraus und Ausdruck der vorgegebenen Daten aus der elektronischen Kartei des Patienten in
Verbindung mit Adreßdatei (z.B. kompl. Kollegenbrief).
- Einbindung fremder Textverarbeitung / Schnittstelle zu anderen Textverarbeitungsprogrammen.
Aufruf eines anderen Textprogrammes (z.B.WORD for Windows), wobei ein vorgegebener, mit Patientendaten gefüllter Standardtext an das andere Textprogramm zur
Weiterbearbeitung übergeben wird.
- Kurztexte
Atteste, Schul-, Sportbescheinigungen, Einnahmevorschriften, Patientenmitteilungen etc.
- Textprogramm
Listenfunktion z.B.Selektionsbestand, - Endlosbriefe, Direktzugriff Patient, Stapelfunktion für späteren Ausdruck, Exportfunktion zu externem Textprogramm ( z.B. WINWORD),
Mail-Funktion (z.B. eMail), direkte Überleitung zum Faxanschluß.
3.8 Erstellen von Statistiken
_____________________________
Ein Statistikmodul. Extrem komplexe Thematik in Deutschland. Sollte
Open Source sein, kann aber wunschweise kommerziell gepflegt werden.
- Statistische Hinweise
zur späteren Auswertung, z.B. erhaltene Überweisungen, Krebspatienten, Materialverbrauch, Zugriff auf die Daten der Vorquartale (Nach abgeschlossenen Quartal im direkten Zugriff
/ Keine Auslagerung).
- Anzeige Behandlungszeit
mitlaufende Minutenanzeige vom Aufruf des Patienten an, zur Feststellung der bisher benötigten Zeit (Zeitdauer bei Gesprächsleistungen)
- Fallwertstatistik
Anzeige des eigenen Durchschnittes im Vergleich zur Fachgruppe in Bezug auf Einzelziffer / Zifferngruppen.
- Praxisbudgetstatistik
Auswertung der Auslastung des Praxis-Budgets (grün),
Auswertung der Auslastung der Zusatzbudgets (gelb),
Berücksichtigung der Fälle die nicht budgetiert werden,
Berücksichtigung der fallzahlabhängigen Faktoren bei der Errechnung der Budgetgrenzen (Fallzahlwippe),
Anzeige freier Kapazitäten / Überschreitung.
- Laborstatistik
Anzeige Laborverbrauch und im Verhältnis zum Budget (z.B. O I).
- Medikamentenstatistik
Anzeige Medikamentenverbrauch / pro Patient / nach Altersstufen / Indikation ...
- Patientenprofilstatistik
Auswertung Patientenbestand nach Geschlecht, M/F/R, Altersstruktur ect... / Begründung.
- Diagnosenstatistik
Häufigkeit der Diagnosen im Quartal und Vergleichsmöglichkeit zu anderen Quartalen / Begründung.
- Veranlassungsstatistik
Auswertung nach Kassenart - AUs, Überweisungen, Krankenhauseinweisungen.
- freie Statistik
Selektion, Auswertung und Auflistung der Anzahl bestimmter Begriffe aus der Patientenkartei.
- Dokumentations-Statistik
Häufigkeit best.Begriffe, z.B.Überweisungen d. Kollegen, Krebspatienten, Sonderfälle ..
- Betriebswirtschafts-Statistik
Auswertung erbrachte Leistungen in Bezug auf Ertrag, Selbstkosten, Umsatzsanteil..,
Hochrechnung auf das Quartal,
Simulation bestimmter Einflüsse auf das Praxisergebnis,
- Statistik, vorhandene Fallzahlen
Anzahl Krankenscheine/ VK und deren Verteilung auf Kassengruppen und Scheinarten
- Tagesstatistik
Auswertung der Leistungen des gewünschten Arbeitstages / Errechnung Arbeitszeit abgerechn. Leistungen.
- Zeitaufwandsstatistik
Quartals- / Tages-Auswertung der für die Erbringung der ärztlichen Leistungen benötigten Zeit (z.B. bei Gesprächsleistungen),
Dokumentation bei Leistungen mit Zeitvorgaben (z.B.10).
- Praxis-Bereichsstatistik
Auswertung der verschiedenen Praxisbereiche oder Differenzierung nach Arzt bei Gemeinschaftspraxen (Mandantenfähigkeit).
3.9 Kommunizieren
_________________
Eine E-Mail-Schnittstelle. E-Mail-Programme sind das täglich Brot von Linux. Es fehlen ggf. noch ein paar Sicherheitsfunktionen (VCS, HCPP) und Schnittstellen (VCS, KDT) zum Praxisprogramm.
sicherer E-Mail-Server für die Praxen mit Verschlüsselung (alles fertig, muß nur zusammengesteckt werden)
E-Mail
VDAP
GnuPG, GEAM, Sylpheed
IMAP
fetchmail + ssl
HCPP
LDAP - Arztadressen von KBV als xDT
- elektronische Mitteilungen
Mail-System für Mitteilungen von jedem Arbeitsplatz zu Arbeitsplatz,
eMail zu anderen Partnern über Online-Dienste,
Befundübermittlungen an Kollegen.
Fax
HylaFAX
sendfax
eFax
- Internetzugang
Internetzugang, eMails aus dem Standardprogramm heraus aufrufbar, Homebanking.
3.10 Abrechnen von Leistungen
_____________________________
Ein Abrechnungsmodul, daß einen Patientennamen übernimmt (xDT), eine minimale GUI hat und sich mit der Abrechnung (EBM, GOÄ, iGel, BG, KVK, Scheinarten) auskennt. Hier besteht hoher, stark reglementierter Implementationsbedarf (xDT, Stammdateien,Prüfung). Die notwendigen Datenformate sind frei verfügbar, ein Prüfmodul (sogar im Quellcode) und das Kryptomodul (Binärversion, läuft mittels IBCS auch unter Linux) kann besorgt werden. In diesem Bereich besteht auch hoher Pflegeaufwand der Schnittstellen und Datenbankinhalte. Ich bin der Ansicht, daß hier durchaus ein Softwarehaus sein Auskommen finden kann und jeder Arzt wird bereit sein, für die notwendige Pflege und Updates auch Gebühren zu bezahlen. Die Schnittstellenimplementationen sollten Open Source sein (meinetwegen BSD-Lizenz, sodaß jemand gegenüber der KBV verantwortlich zeichnen kann für die Konformität), die aktuellen Daten aber braucht es nur gegen Gebühr zu geben. M.E. wäre es wünschenswert, daß z.B. TurboMed seine DOS-Version nach offiziellem Auslaufen massiv abspeckt und dieses Modul daraus macht. Oder APW. Oder wer sonst will. Dieses Modul sollte sich ausschließlich um die Abrechnung kümmern und nicht um andere Dinge. Nach Quartalsende und Abrechnung würden die Abrechnungsdaten zur Archivierung an das
Hauptmodul übergeben. Von dort könnten Sie zur Vorquartalsauswertung, zur Korrekturabrechnung, etc. ggf. wieder zurückgereicht werden. Ich würde mir dieses Modul so minimalistisch wie sinnvoll möglich wünschen.
Abrechnung:
Der Vorschlag einer kassenärztlichen Verrechnungsstelle
ist derzeit nicht vom Abrechnungschaos realisierbar.
Es gibt aber genügend Anbieter, die zertifiziert sind.
Es sollte sich sicherlich einer finden lassen, der ein
Modul zur Regelwerkprüfung bereitstellt (keine Oberfläche,
nur über Pipes/Sockets o.ä ansteuerbar). Nach anfänglicher
Portierung würde das im Rahmen seiner eigentlichen
Softwarepflege einfach abfallen. Kann ruhig auch was
kosten.
Rechnungslegung für Privatpatienten (existiert, muß aber an Privatabrechnung angepaßt werden)
Kassenabrechnung
Tagesliste
Online-Regelwerk bei Eingabe
Prüflauf zu beliebiger Zeit
Fehlersuchfunktionen
Suchmasken für vergessene/eingetragene GO-Nr.
Prüfmodul, Kryptomodul
automatische Warnung bei fehlender 1
Automatik für Wegegeldzonen
KV-Spezifika zumindest vom Anwender einpflegbar
Statistik
Arztgruppe
Ermächtigung
Zusatzbezeichnung
BG
Unfallmeldung
BG-Abrechnung (GOÄ)
Übernahme in Liste Offene Rechnungen
mehrfach druckbar
Druck von Mahnungen
Privatliquidation
GOÄ mit Online-Regelwerk
eigene Ziffern einpflegbar
Übernahme in Liste Offene Rechnungen
mehrfach druckbar
Layout veränderbar
Berechnungszeitraum frei wählbar
Einzelerstellung pro Patient
Druck von Mahnungen
Abrechnung
APW
David/X
Apris/Open
- Abrechnungsarten
Ambulant, Stationär, Notfall/Vertretung, Privat, BG
Privatrechnungen nach EBM sollten ebenfalls mögl. sein.
- Abrechnungsziffern
Vorgabe und Direktkontrolle des Eintrages unter Berücksichtigung der Gebührenordnung des Kostenträgers nach BMÄ/EGO/GOÄ.
Die Möglichkeit einer individuellen Änderung/Neuaufnahme muß vorhanden sein (Sonderziffern/Regeln des KV-Bezirks).
- Zifferndatei BMÄ / EGO (EBM)
Mit eingebautem Regelwerk - Sofortkontrolle/Fehlerliste - Beispiele !!!
Sonderregelungen des eigenen KV-Bezirks müssen einstellbar sein.
- Zifferndatei GOÄ
diverse Faktoren, Begründungen, besondere Kosten §10 GOÄ, Sachkosten/Regelwerk,
Angaben in DM und EURO möglich.
- Kostenträgerstammdatei
Kostenträgerstammdatei der KBV integriert,
zusätzlich die Verschiedenen “Privaten Kostenträger”,
Datei aller Kostenträger mit 5-stelliger Kassennummer und Institutionskennzeichen.
- ICPM
Verzeichnis der durchzuführenden Leistungen im Krankenhaus.
- Heil- und Hilfsmittel
Heil- und Hilfsmitteldatei mit Preisangaben,
Übernahmefunktion für Verordnung und Statistik.
- Fehlerkontroll-Liste
auf Drucker und Anzeige am Bildschirm mit Direktkorrekturmöglichkeit in Patientendaten.
- Kassenabrechnung
KVrichtlinienkonforme Erstellung des Datenträgers,
Abrechnungszeitpunkt unabhängig vom Behandlungsdatum,
KBV- Zulassungsnummer.
- ADT-Prüfmodul KBV
Der Einsatz des KBV-Prüfmoduls zur Überprüfung des ADT-Disketteninhaltes ist Vorschrift (KBV),
Aufruf und Durchführung aus dem Abrechnungsprogramm heraus,
Prüfmodul wird mit Quartalsupdate geliefert,
Ausdruck der Prüfprotokolle,
- ADT-Kryptomodul KBV
Verschlüsselung der Abrechnungsdaten in einigen KV-Gebieten Vorschrift.
- Privatabrechnung
Abrechnung der Privatpatienten zeitraumbezogen - Zeitraum bel. Wählbar,
Regelprüfung, Einzel-, Gesamtabrechnung, Zahlungseingänge, Mahnverfahren, unterschiedliche Faktoren, Begründungstexte, besondere- und Sachkosten, Verwendung der Daten der
PKV-Karte,
Rechnungen wahlweise EURO, DM oder EURO und DM.
- Abrechnung über Privatärztliche Verrechnungsstelle
PAD-Schnittstelle (Diskettenabrechnung PVS oder Online-Übertragung der Abrechnungsdaten via ISDN).
- BG-Abrechnung
Berufsgenossenschaftliche Abrechnung - Rechnungserstellung an die BG incl “Besondere Kosten nach §10 GOÄ”,
Unfallberichtschreibung - Nachschaubericht der eigenen Fachrichtung.
3.11 Nutzen von Geräten
_______________________
Gerätetreiber (KVK-Leser, Kleinstlaborgeräte) - teilweise in Entwicklung
- Anschlußmöglichkeit für Digitalisierbrett und Mausbedienung,Virtuelle Maus
Mit gewünschten Begriffen selbst programmierbar / als alternative Eingabemedien für Anwender, die nicht gerne mit der Tastatur arbeiten.
- Spracheingabe
Spracherkennung zur Texterfassung und Systemsteuerung.
Vorhandener medizinischer Wortschatz.
3.12 Sichern von Daten
______________________
juristisch beweisbar unveränderbare Datensicherung (teilweise einsatzbereit)
3.13 Beachten von Sicherheitsaspekten
_____________________________________
Datensicherheit
Zugriffsschutz
Datensicherung
Netzschutz
Tools
gnupg frontend
digital notary frontend
- Intime Daten
Datenkategorien, die auch vor dem Einblick des Praxispersonals mittels Passwort geschützt werden müssen.
- Datenschutz, Zugriffsschutz
Schutz des kompletten Systems vor unberechtigtem Zugriff (z.B. beim Systemstart),
Schutz bestimmter Programme und Anzeigen vor dem Einblick der Helferin (z.B. Umsatzstatistik, Privatabrechnung),
Schutz der Karteikarte bzw. bestimmter Daten vor dem Einblick des Patienten (z.B. an exponierten Arbeitsplätzen),
automatische Dunkelsteuerung bzw. Abschalten des Zugriffs beim Verlassen des Arbeitsplatzes oder nach einer vorgegebenen Zeit,
individuelle Zugangskontrolle mittels Passwort / Mitarbeiterkennung.
3.14 Unsortiert
_______________
- Kostenträgeranzeige
Krankenkassen, BGs und private Versicherungsträger incl. der
unterschiedlichen Abrechnungsbestimmungen /-Faktoren der einzelnen Kostenträger.
Suchfunktionen nach Name, Nummer, Suchort
- Hausarztanzeige
Vermerk des Hausarztes in den Stammdaten,
Erfassungsmöglichkeit einer Adressdatei der umliegenden
Ärzte und Krankenhäuser,
zur automatischen Briefschreibung (Tastendruck) gekoppelt mit
Patient und Textverarbeitung
- Direktkontrolle bei der Eingabe
Ziffernein- und -ausschlüsse, Begründungen, Uhrzeiten
- Standardbausteine für häufig wiederkehrende Begriffe
Rezept, Abrechnungsschein, AU, Überweisung, Krankentransport,
Bescheinigungen, Kollegenbriefe mit der Möglichkeit auf
Standard-Bausteine zurückzugreifen,
freier Text ohne Feldbegrenzung mit gegliederter Anzeige
und graphischer Darstellung.
Sofortanzeige
- Sofortstatistik Ziffern/Teilbudget
Anzeige des Zifferndurchschnittes und des Teilbudgets über
100% verglichen mit der eigenen Fachgruppe bei Eingabe der Ziffer.
- Medikamentenbuget,
Jederzeit abrufbare Budgetkontrolle Gesamtpraxis, pro Fall und
Verbrauch Patient im Quartal.
- Graphische Anzeige der verschiedenen Statistiken,
Vergleiche mit anderen Quartalen (z. B. Vorquartal,
Vorjahresquartal, Quartalsverlauf etc.).
- Info Pool Zugang
Bei einigen Anbietern gibt es als Zusatz die Möglichkeit eines
monatlichen Vergleiches der eigenen Daten mit den Daten anderer
Praxen der gleichen Fachrichtung durchzuführen, um rechtzeitig
besondere Entwicklungen der eigenen Praxis erkennen zu können.
- Patientenanmeldung im Sprechzimmer
Patient kann von der Rezeption an best. Arbeitsplätzen angemeldet werden.
Weitermeldung an andere Arbeitsplätze von jedem Arbeitsplatz aus.
- Makrofunktion/Behandlungsdaten
Erfassung eines kompletten Behandlungsschemas, unter einem Befund-Kürzel
können Sie sich zusätzlich zu Ihren Standard-Befundtexten weitere
Datenkategorien vorschlagen lassen.
- z.B. Ziffern, Diagnosetexte, Medikamente, Therapie usw....
- Automatische Patientenvorlage
Tagesliste, Fehlerprotokoll, Selektionsliste, Laborübertragung
mit automatischer Vorlage der Patienten zur direkten Ansicht und
Korrektur/Eingabe am Bildschirm.
- Recallverfahren
Einbestellung und Überwachung der Risikopatienten, Nachkontrolle,
Impftermine etc... in Verbindung mit Endlosbriefschreibung.
- Terminplanung - Wartezimmerliste
Tages-, Wochen-, Monats- und Jahresplanung (Jahr 2000-Problematik),
Ergänzungs-Hinweis und Zeitpunkt des Eintreffens in der Praxis,
Aufruf aus der Patientenkarte heraus und Eintrag, wenn Patient
Praxis wieder verlassen hat beziehungsweise Behandlung eingetragen wurde.
- Selektions-Programm
und/oder/nicht - zum Auffinden bestimmter Eingaben in Patientenkartei
und Listung,
Selektion nach mehreren Suchbegriffen und Verknüpfungen gleichzeitig.
Abspeicherbare Standardselektions-Vorgaben,
Negativselektion nach nicht vorhandenen Einträgen,
Kombination mit Listenausdruck und Serienbrief.
- Mahnung Krankenscheine / Vorlage Versichertenkarte
Ausdruck/Anzeige als Telefonliste, Adressetiketten
und Verwendung der Daten für Endlosbriefe.
Prüfliste der Fälle mit Ersatzverfahren,
- Mahnung Privatrechnungen
Offene Posten-Liste - Berücksichtigung Mahnstufen bzw.
geleistete An- oder Teilzahlungen.
- Gemeinschaftspraxis
Einstellung des Systems zur Bearbeitung bei Gemeinschaftspraxen.
ACHTUNG:
Sonderregelung bei fachübergreifenden Gemeinschftspraxen
(Besondere Kennzeichnungspflicht der abgerechneten Ziffern -
KV-Vorschrift beachten),
Berücksichtigung besonderer Faktoren für die Praxisbudget-Statistik
(Faktorerhöhung).
Getrennte statistische Auswertungen (Mandantenfähigkeit) und
gemeinsame Abrechnung.
Entstehen Zusatzkosten in Bezug auf Softwarepflege und Softwaremodule??.
- Praxisgemeinschaft/
Einstellung des Systems zur Bearbeitung bei Praxisgemeinschaften
(Mix Gemeinschaftspraxis und Praxisgemeinschaft auch möglich ?).
ACHTUNG:
Besondere Bestimmungen in Bezug aus den Datenschutz müssen beachtet werden.
Entstehen Zusatzkosten in Bezug auf Softwarepflege und Softwaremodule??.
- BDT - BehandlungsDatenTräger
Ist der BDT im Lieferumfang des Programmes enthalten?
Ausgabe der Patientendaten im BDT-Format zur Übernahme in andere
Systeme (Abklärung: eigene Kürzel, Texte, Befundbausteine etc.).
Anbindung weiterer Programme/ bzw. medizinischer Geräte über die BDT-Schnittstelle.
- GDT - GeräteDatenTräger
Gerätedatenträger-Schnittstelle realisiert und im Umfang enthalten?
(GDT-Schnittstelle wurde von der KBV herausgegeben).
- KVDT
KVDT vorgesehen - Option ?
KV-Abrechnung plus weitere Datenpakete KBV,
- LapTop-Modul
Programm zur Auslagerung, Weiterbearbeitung und Wiedereingliederung
der Patientendaten für Hausbesuche und ggf. in der Zweigpraxis.
- Makro-, Stapelverarbeitung-Programme
Abarbeitung hintereinandergeschalteter Durchlauf-Programme ohne Stop
(z.B. zu einem Zeitpunkt, in der die Praxis nicht besetzt ist).
- Individuelle Funktionstastenprogrammierung
programmübergreifend, individuell durch Anwender einstellbar zur
Abkürzung von sich wiederholenden Eingaben oder Programmsprüngen,
z.B. Kollegenbrief ausdrucken aus aufgerufenen Patientendaten heraus.
- Betriebssystem und Programmlizenz: Einplatz / Mehrplatz
gibt es preisliche Ausbau-Stufen/Anzahl.
Original-Diskettensatzvorhanden (Netzwerk-Software, Betriebssystem,
Treiberdiskette/CD für diverse Hardwarekomponenten).
- Praxisbereiche
Aufteilung der Praxis in verschiedene Statistikbereiche,
z.B. zur Honoraraufteilung arztbezogen (Erbringer der Leistung),
z.B. zur Ermittlung des Ertrags bestimmter Praxisbereiche
(Gegenüberstellung Kosten/Nutzen).
- Datenausgabe
Ausgabe der Daten (z.B. statistische Auswertungen) im Word-,
Excel- oder Access-Format zur weiteren Bearbeitung (z.B. in Text,
Tabellen und Graphik).
- Multiuser
Mehrplatzbetrieb, bei dem an den Arbeitsplätzen und Druckern
gleichzeitig verschiedene Programme laufen können.
- Multitasking
Parallelbearbeitung div. Programme auf mehreren Ebenen
innerhalb eines Arbeitsplatzes unabhängig voneinander.
Dieses ist besonders für die Praxen wichtig, bei denen telefonisch
durchgestellte Patientendaten zwischendurch eingesehen werden
müssen, ohne daß der gerade aufgerufene Patient verlassen,
oder das Statistikprogramm abgebrochen werden muß.
Ähnlich wie im Fernsehen können unabhängig von einander
verschiedene Programme laufen, die Sie per Knopfdruck umschalten können.
- Multiprocessing
Abarbeiten länger dauernder Durchlaufprogramme im Hintergrund
während am selben Arbeitsplatz im Vordergrund weitergearbeitet
werden kann . z.B. Durchführung der Abrechnung im neuen Quartal.
- Parallelprocessing Fremdprogramme
Nutzung externer Programme wie DATEV, Bank/Geldverkehr,fremde
Textprogramme, Impfprogramme, Diagnoseunterstützung, Bildschirmatlas
etc. im gemeinsamen Parallelbetrieb mit dem laufenden
Praxisverwaltungsprogramm aus der Patientenkarte heraus.
- DOS-Kompatibilität
In Verbindung mit Multiuser-, Multitasking- und
Multiprocessingfunktion an allen Arbeitsplätzen, läßt Ihnen den
Freiraum für andere Programme und deren Nutzung. Eine
Beschränkung auf die nur vom Softwarehaus gelieferten
Arztprogramme gibt es nicht - die größte Programmbibliothek
der Welt gibt es unter DOS - diese können Sie nutzen.
- Archivsystem
Archivierung nicht mehr benötigter Patientendaten mit
direktem Zugriff aus der Patientenkartei heraus.
- Offene Praxis EDV Vorschlag zur Dokumentation von Jürgen Saucke:
Habe einen Vorschlag aus unserer Praxis die mit TM dos
arbeitet.
Die wichtigsten Dokumentationsinfos sind bei uns
mittlerweile ,die Dauerdiagnosen die werden -ICD 10 Nummer hin oder her-
möglichst genau formuliert und immer wiederaktualisiert.
Was nützt es einem wenn in der offiziellen ICD 10 im Diagnosentext
Bösartige Erkrankung weibl Brustdrüse” oä steht Das sagt uns wenig. Da
wir nur sehr wenig Platz für die Diagnosen haben müssen wir extrem´Abkürzen damit
alle wichtigen Dauerdiagnosen dokumentiert werden. Leider können wir in TM Dos
keine Formatierung im Sinne einer Diagnosehierarchie machen.
Der Überblick mit einem Blick über alle wesentlichen Dauerdiagnosen ist
das wesentliche was man beim Blick auf den Bildschirm erfassen sollte, wenn man
man einen Pat noch nicht kennt oder wieder vergessen hat was seine wesentlichen
Erkrankungen sind.
Dieser Ein Blick giltt für Dos genauso wie für multitasking Programme.
Die Diagnosen sollte per ziehen und Ablegen kopierbar sein in jedes andere
Programm.
Wir müssen leider in extremen Kürzeln schreiben bei uns sieht das dann so aus:
CaMastektomie bds 98u99 RadChem postOP
oder
CaMastektomie r 78 Lympharmödem
Nur diese Kürzel können wir leider den anderen Kollegen nicht immer anbieten,
dann müssen wir es wieder verlängern. Diese Info ist aber die wichtigste und sie wird
ständig aktualisiert.
Unsere Diagnosedatei ist bereits auf 8300 Diagnosen angestiegen.
Weiter wäre es wichtig bereits ausgeschlossen Verdachts-
diagnosen ersehen zu können Dies ist besonders bei Somatoformen Störungen also zB bei
Patienten mit Panikattacken und Angst vor Herzinfarkt oder Krebserkrankungen
wichtig, da mit einem Blick ersichtlich ist ob und wie eine KHK ausgeschlossen wurde.
Bei uns heißt das dann KHK ZnA m
Coro wenn bei dem Pat. mit einer Herzkatheter Untersuchung
eine Herzkranzgefäßerkrankung ausgeschlossen wurde.
Oder CCToB 00 wenn 2000 eine ComputerTomografie des Gehirns einen
Tu ausgeschlossen hat.
Die Gesundheits und vororge Untersuchungen sollte mit einem blick ersichtlich
sein wann zuletzt mit einem 2. Blick genauere Ergebnisse zB Sono und körperliche
Untersuchung sowie Fremdbefunde.
Die bereits durchuntersuchten Organsysteme sind aber zur Verhinderung
von Doppeldiagnostik wichtig, und auch weil
man dann weiß wann ein Organsystem ev mal wieder untersucht werden müßte insbes
bei anlagebedingten oder erblichen Riskofaktoren die auch auftauchten müssten.Die
Berufsanamnese fehlt auch.
Wenn die Diagnosen und Ausschlußdiagnosen auch noch an einem Homunkulus sichtbar
wären wäre das vielleicht auch hilfreich.Beim Aufsuchen mit dem Mauszeiger würde
dann der Facharztbefund aufklappen schön wärs und so praktisch.
Grüße von Jürgen Saucke
Software/Oberfläche: SAA (IBM), muß nicht GUI sein
generelle Struktur
Tk Family Practice (OIO)
AccessGP
FreePM
GNUMed
- intelligent Agents for Observations in Medicine
- communicating with medical devices using Java JINI
- mobile devices (PDA, Handheld, mobile phone)
- bei AU: Beruf und Cave einblenden !
4 Facharzt Use Cases
____________________
- Besonderheiten der eigenen Fachrichtung
Programme für die eigene Fachrichtung im Umfang enthalten,
Facharztmodul/Grundbestände Diagnosen, Befunde etc ohne Aufpreis.
4.1 Behandeln von Zahnerkrankungen
__________________________________
4.2 Behandeln von Augenerkrankungen
___________________________________
5 Zusatz Use Cases
__________________
5.1 In Anspruch Nehmen von Dienstleistungen
___________________________________________
Übersetzerservice
Artikelbeschaffung
Telefontarife
Sprechstundenbedarf
5.2 Nutzen von Fremdprogrammen
______________________________
CustoMed LZ-RR
vom Patienten aufrufbar mit Im-/Export (GDT/BDT)
aus Menü aufrufbar (unabhängig vom Patienten)
BDT-Schnittstelle
Im-/Export
gesamt/pro Zeitraum
5.3 Nutzen von kommerziellen Programmen
_______________________________________
Verschiedene Bereiche, besonders in der Inhaltspflege
halte ich keineswegs für einen Open Content Ansatz geeignet
(siehe oben). Dort wäre der Platz für kommerzielle Anbieter.
Oder auch bei Administration, Wartung, Infrastruktur
(VPN, SSL, SSH für Mail).
5.4 Nutzen von HDTF Services
____________________________
(CORBAmed)
Siehe:
http://www.omg.org
http://www.openemed.org
6 Einführungsstrategie
______________________
6.1 Voraussetzungen zur KV-Zulassung
____________________________________
Unter http://daris.kbv.de/daris/link.asp?ID=1003729060 kann sich jeder einen
Eindruck über die Voraussetzungen zur KV-Zulassung einer Software machen.
Aus diesem pdf geht hervor, dass bereits die Stammdatenverwaltung der
Patienten mit Formularbedruckung, _ohne_ Abrechnungsfunktionen,
genehmigungspflichtig ist (ca. DM 500,-)
Bei Nutzung des Programms zu Abrechnungszwecken wird eine umfangreiche
Prüfung verlangt, ferner bei jeder diesbezüglichen Änderung im Programm.
Interessant sind die Kapitel Spezialprüfungen, kombinierte Systeme und
Individualprüfungen.
Demnach ist es durchaus möglich, Programmteile verschiedener Hersteller
zusammenzusetzen, aber auch das erfordert eine neue Zulassung des
“gesamthaften Abrechnungssystems”.
Ferner kann sich jeder Vertragsarzt sein eigenes Progrämmchen genehmigen
lassen, er ist dann selbst Softwareverantwortlicher (!). Für die Prüfung ist
dann u.U. die lokale KV zuständig.
Grundsätzlich dürfte das Problem “Softwareverantwortlicher” damit lösbar
sein. Den offenen Quelltext halte ich nicht für ein Problem, da
1. Jeder Vertragsarzt bei der Abrechnung unterschreibt, mit einem
zugelassenen Programm regelkonform abgerechnet zu haben und
2. Manipulationen an den Abrechnungsdateien auch bei closed-source Programmen
möglich sind.
6.2 Reihenfolge der Entwicklung
_______________________________
- erstmal vorrangig auf ärztliche, medizinische Nutzung ausrichten
Diese Reihenfolge ist nicht festgeschrieben. Wir halten sie nur
gegenwärtig für am sinnvollsten.
1) Medizinische Dokumentation
2) Formulardruck
Es klingt sinnvoll, zunächst mit nicht zulassungspflichtigen Programmteilen
anzufangen, das wäre im wesentlichen die Dokumentation. Dabei halte ich es
für besonders wichtig, ein gutes Datenbankdesign zu entwerfen. Vielleicht
kann ich hierzu auch als Anwender noch Hinweise geben (ich beschäftige mich
gerade mit der Theorie relationaler DB).
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!
Die KV-Abrechnung sollte dann als nächstes implementiert werden.
Dabei kann man vielleicht nochmal differenzieren zwischen einer reinen
Datenbanktabelle für die Speicherung der Abrechnungsziffern und
ICD10-Diagnosen, die dann per ADT/BDT an ein anderes Praxisprogramm übergeben
und von diesem abgerechnet werden. Ich denke aber, dass auch diese Version
schon genehmigungspflichtig wäre (siehe oben).
Inwieweit ein kommerzieller Hersteller sein Abrechnungsmodul zur Verfügung
stellt, weiß ich nicht. Schließlich hat Microsoft auch keine C-Compiler oder
Bibliotheken zur Entwicklung von Linux beigesteuert ;-)
Denkbar wäre am ehesten ein kleinerer Anbieter, der noch nicht von einem
großen Softwarehaus geschluckt wurde und noch etwas Idealismus mitbringt.
Ansonsten wäre an dieser Stelle bereits eine kleine Gruppe (>10) ernsthaft
interessierter Anwender notwendig, die sich die Zulassungsgebühren teilen.
Die Privat- und BG-Abrechnung lässt sich dagegen (vielleicht auch als
Vorläufer) wohl aus der Klasse (KV-)Abrechnung ableiten, mit Anbindung an
eine Textverarbeitung für die Rechnungen.
Behandlungsdaten/Abrechnung/Verordnung:
kleine Karteikarte: begrenzt auf Ziffern. Diagnosen, Rezepte, Bemerkungen
für den Einstieg - erweiterbar auf elektronische Kartei
6.3 Möglichkeiten zur “Markteinführung” - der Weg auf den Rechner des Anwenders
_______________________________________________________________________________
6.4 Partnerschaften
___________________
UVT-Verband
PVS-Verband
KVen
KBV
ZI
“kleinere” Anbieter und Einzelzulassungen
- wer hat Adressen ?
Woher _könnte_ Widerstand zu erwarten sein ?
- jetzige Marktführer bei Praxis-EDV
7 Hardware Infrastruktur
________________________
Rechner
Bildschirme
touch screen für Selbsteingabe von Anamnesebögen durch Patienten
KVK-Geräte
Drucker
Tastatursteuerung
siehe Mutt
Das Ganze sollte auf einer soliden Serverbasis sitzen: Linux (Debian)
oder Free-/OpenBSD mit Journalling Filesystem und RAID. Eine
professionelle Datenbank: www.PostgreSQL.org
Dazu Sicherheitsmaßnahmen: Backup.
Digitale notarielle Beglaubigung (gnumed.net/gnotary/gnotary.html).
Transaktionsserver (siehe Konzept von www.gnumed.org)
Struktur
Einzelplatz
Netz
Server
dediziert
nicht-dediziert
Praxisdaten
Internetzugang
Arbeitsplätze
servertechnik
backups brennen, digital notary
failsave
encrypted fs
journalling
raid 1
controller für root partition
software für andere Partitionen
hardwaremonitoring
internet (ISDN/modem/dsl)
8 Fragen & Antworten
____________________
Kann unsere vorhandene Hardware auch fuer das neue System problemlos eingesetzt werden?
Sind unser Betriebssystem und das Netzwerk für die neue Software geeignet?
Können unsere Daten problemlos übernommen werden?
- BDT-Schnittstelle beim Altsystem verfügbar?
- Was kostet die Ausgabe der Daten im BDT-Format?
- Handelt es sich um eine BDT-Schnittstelle nach dem aktuellen Standard oder um eine frühere Version?
Was kostet die Übernahme der Daten ins Neusystem?
Können die Daten komplett übernommen werden oder gibt es Einschränkungen (z.B. VK-Einlesedatum, VK-Daten, Privatpatienten, individuelle Bausteine, Texte etc.).
- Eventuell vorherigen Test durchführen !!
Welcher Zeitpunkt ist für eine Umstellung geeignet?
- Teminabsprache zur Umstellung genau festlegen
- Kann die Umstellung auch im laufenden Quartal erfolgen?
- Ist auch eine Schulungskraft zum Zeitpunkt der Umstellung verfügbar?
Welchen Inhalt sollte ein Softwareservice Vertrag haben?
- Oft stellt sich heraus, daß ein vermeintlich günstiger Softwareservice·Vertrag aufgrund zusätzlich nötiger Eweiterungen oder nicht enthaltener Leistungsmerkmale im Nachhinein wesentlich teurer sein kann als ursprünglich angenommen.
- der Vertrag für die Anwender-Programm-Pflege sollte folgende Positionen ohne Aufpreis enthalten:
- Update infolge KV- und Gesetzesbestimmungen,
- Update der Programme auf den laufenden Stand (inkl. Kosten für Datenträger),
- Neuentwicklungen und Verbesserungen im Programm,
- Anpassungsprogramme an geänderte Hardwarekonfigurationen,
- Zugriff auf die Hotline (Software- und Hardwarehotline,
- Sonderzugriff-Hotline (Rückruf/ Kurzschulungen am Telefon),
- Datenlieferungen Medikamentendatenbank,
- Datenlieferungen Kostenträgerdatei,
- Datenlieferung Gebührenordnungen,
- Datenlieferung Diagnosedatei (ICD),
- Datenträger, Porto und Verpackung,
- Wartung der Sonderprogramme für bestimmte Fachrichtungen,
- Wartungskosten für Laboranbindungen, Homecomputing, etc.,
- Instandsetzung beschädigter Anwenderdateien (gegebenenfalls vor Ort),
- Dokumentationen zu allen Programmen und Programmänderungen,
- Handbuch bei Neuauflagen/ Handbuch-Ergänzungslieferungen,
- Umstellung auf andere Praxisform (ohne Zusatzkosten für Praxisgemeinschaft, Gemeinschaftspraxis)
- Quartalsweise Kündigungsmöglichkeit
- Monatliche/Quartalsweise Beitragszahlung nach Ablauf des Leistungsmonats
- Der Vertrag sollte inklusive aller Kosten für die benötigten Datenträger, Transport und Verpackung ausgelegt sein. Bei Fernübertragungen der Updates sollten die Kosten der Updates ebenfalls vom Vetrag mit abgedeckt werden.
9 Verzeichnisse
_______________
9.1 Abkuerzungen
________________
CIAS - Clinical Imaging Access Service der HDTF
COAS - Clinical Observation and Access Service der HDTF
GNU - “GNU's Not UNIX” Rekursives Akronym, welches als Name fuer ein freies UNIX, basierend auf dem Linux Kernel, gewaehlt wurde.
HDTF - Healthcare Domain Task Force (CORBAmed) der OMG
JSP - “Java Server Pages” HTML Seiten, die Java Programmcode enthalten. Vor ihrer Anzeige werden die JSP Seiten durch ein Interpreter Programm gelesen und in reines HTML umgewandelt. Mit Hilfe von JSP koennen Applikationen eine plattformunabhaengige Web Oberflaeche erhalten und sind damit ueber WebBrowser bedienbar. Als Alternative zu diesen Web basierten Oberflaechen gibt es herkoemmliche stand alone Applikationen, also Programme, die eigenstaendig gestartet und ausgefuehrt werden und ihre Oberflaeche mitbringen. Siehe hierzu “Swing”.
OMG - Object Management Group http://www.omg.org
PIDS - Person Identification Service der HDTF
RAD - Resource Access Decision Service der HDTF
Swing - Bezeichnung einer Quelltextbibliothek der Sprache Java fuer die Oberflaechenprogrammierung. Dient dem Erstellen von Oberflaechen fuer stand alone Applikationen.
W3C - World Wide Web Consortium http://www.w3.org
9.2 Abbildungen
_______________
9.3 Tabellen
____________
9.4 Literatur
_____________
Links auf Standards sind generell nicht hier verzeichnet, sondern in der OIO Project Library
auf http://www.txoutcome.org zu finden.
Wissensarchiv
-------------
siehe Artikel zu Glimpse in c't 11/2001
Share “Wissensarchiv” per Samba bereitstellen
dort werden Dokumente (doc, html, pdf, txt, rtf, ps) frei abgespeichert
auf Wunsch Aufteilung in Verzeichnisse möglich, aber nicht notwendig
nächtliche Indexierung per Glimpse
Suche im Archiv per Formular im Browser in LAN der Praxis
ist nicht als “formelles” Archiv für Patientenbriefe, etc. gedacht
z.B. laxe Sicherheit, Datensicherung und Integritätskontrolle
QuickQuack Pflichtenheft/Requirements: siehe Website
“Der Computer-Führer für Ärzte”, Ausgabe 1999
Version 1.1, March 2000
Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other written document “free” in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”.
A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five). C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section entitled “History”, and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. In any section entitled “Acknowledgements” or “Dedications”, preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section entitled “Endorsements”. Such a section may not be included in the Modified Version. N. Do not retitle any existing section as “Endorsements” or to conflict in title with any Invariant Section.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections entitled “History” in the various original documents, forming one section entitled “History”; likewise combine any sections entitled “Acknowledgements”, and any sections entitled “Dedications”. You must delete all sections entitled “Endorsements.”
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an “aggregate”, and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
Hier sind Menschen und Firmen aufgelistet, die nicht zum eigentlichen Entwicklerteam gehören, sich aber um das Vorwärtskommen offener Projekte in der Medizin verdient gemacht haben. Private E-Mail-Adressen sind bewußt nicht aufgeführt. Dr.med. Ch. Hein - http://www.pge.de - stellte eine Cherry-Tastatur zum Testen des KVK-Leser-Treibers bereit Herr M. Westermann - http://www.microdata-pos.de - entwickelte das Kernelmodul für den KVK-Leser in der Cherry-Tastatur Firma Orga Kartensysteme GmbH - http://www.orga.com - stellte einen Kartenleser Typ HML 5010 zur Anbindung bereit Frau U. Wermter vom Zentralinstitut für die kassenärztliche Versorgung in der Bundesrepublik - http://www.zi-koeln.de/ZIK/themen/arznei/werm-11.htm - stellte Testdaten der Medikamentendatenbank AMIS intern für Programmierzwecke zur Verfügung (keine Weitergabe an Dritte möglich, bitte von Anfragen absehen !) Frau D. Brücher von der Ärztlichen Verrechnungsstelle Büdingen GmbH - http://www.pvs-buedingen.de - stellte die Definition des Datenformats zur Einreichung von Privatrechnungen auf Datenträgern bereit Herr Jörg Garritzmann - mailto:j.garritzmann@gmx.de - stellte seine guten Kontakte in der Praxis-EDV-Branche zur Verfügung und vermittelte schwer beschaffbare Informationen Frau H. Krüger-Brand Beilage “PraxisComputer” des Deutschen Ärzteblattes - http://www.deutsches-aerzteblatt.de - ermöglichte die Veröffentlichung einiger Artikel zur Materie Firma Krake Softwaretechnik - http://www.krake.de - ermöglichte Einblick in den Quellcode der Privatliquidationssoftware Bub