Analysedokument zur Erstellung eines Informationssystems fuer den Einsatz in der Medizin
Mailingliste ResMedicinae-Deutsch 
Eine gemeinsame Anstrengung vieler Enthusiasten aus den Bereichen der Medizin, Informatik, öffentlicher Einrichtungen und auch Firmen. Entstanden unter maßgeblicher Beteiligung der Mitleser der Mailingliste ResMed-de resmedicinae-deutsch@lists.sourceforge.net (mailto:resmedicinae-deutsch@lists.sourceforge.net).
Administrivia
Copyright © 1999-2002. Karsten Hilbert, Christian Heller, Roland Colberg, Peter Hahn et al.
Res Medicinae -- Information in Medicine -- <www.resmedicinae.org> (http://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:
•	Dr. Roland Colberg <rcolberg@gmx.de> (mailto:rcolberg@gmx.de)
•	Dr. J. Fischer <joachim_fischer@web.de> (mailto:joachim_fischer@web.de)
•	Priv.-Doz. Dr. P. Hahn <> (mailto:no-spam@somewhere.de)
•	Dr. Bernd Heller <> (mailto:no-spam@somewhere.de)
•	Christian Heller <christian.heller@tuxtax.de> (mailto:christian.heller@tuxtax.de)
•	Magdalena Heller <> (mailto:no-spam@somewhere.de)
•	Karsten Hilbert <Karsten.Hilbert@gmx.net> (mailto:Karsten.Hilbert@gmx.net)
•	Jörg M. Sigle <joerg.sigle@jsigle.com> (mailto:joerg.sigle@jsigle.com)
•	Jürgen Saucke <jsaucke@t-online.de> (mailto:jsaucke@t-online.de)
•	Dr. Winfried Behrendt <Behrendt.Oedesse@t-online.de> (mailto:Behrendt.Oedesse@t-online.de)
•	Dr. med. Andreas Streller <streller@t-online.de> (mailto:streller@t-online.de)
•	Dr. med. Michael Elisat <> (mailto:no-spam@somewhere.de)
•	Dr. med. Gerhard Bauer <> (mailto:no-spam@somewhere.de)
Hinweis: Der Inhalt basiert auf Version 1.33 der früheren Textversion.
$RCSfile: analysis-de.sgml,v $
@version $Revision: 1.1 $ $Date: 2003/07/05 18:24:23 $ $Author: chrissy $
Einleitung
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.
Konzepte und Prinzipien
Programmsteuerung
•	notwendige Aktionen der Anwender minimieren 
•	Anzahl Tastendrücke
•	Wechsel Maus/Tastatur
•	dabei aber Möglichkeiten der Anwender zum Abweichen vom Standardvorgehen erhalten
•	trotz grafischer Oberfläche durchgängig Bedienung mittels Tastatur ermöglichen
•	Platzhalter 
•	Platzhalter: Kürzel, das in längeren Text umgewandelt werden kann
•	in allen Feldern mit Texteingabe bereitstellen
•	programmweit konsistent
•	kontextabhängig (vom gewählten Patienten, etc.)
•	manuell umwandeln nach z.B. STRG-M
•	automatisch umwandeln (z.B. beim Laden einer Schnellbriefvorlage) von speziell formatierten Platzhaltern, wie $SHT$ -> Schädel-Hirn-Trauma
•	alle Daten der Datenbank sollen (je nach Zugriffsrechten) per Platzhalter verfügbar sein
•	Platzhalter sind intern Skripte, z.B. in \GNUmed\Platzhalter\
•	diese Skripte können einfach Text zurückliefern oder beliebig komplexe Aktionen ausführen
•	Auswahl aus Listen 
•	Texteingaben mit (teils kontextabhängigen) Listen hinterlegen
•	mehrstufige Datenbankanbindung (pro Patient, pro Arzt, pro Praxis, amtlicher Stamm)
•	amtliche Stämme nur lesbar (PLZ, BLZ, Kassen, etc.)
•	Suche per word wheel und Suchfunktion 
•	beim Tippen erscheinen die bisherigen Treffer
•	1 Buchstabe - alle Phrasen, die damit beginnen
•	2 Buchstaben - alle Phrasen, die ein Wort enthalten, welches damit beginnt
•	4 Buchstaben - alle Phrasen, die diese Sequenz beinhalten
•	Schwellen (1,2,4) konfigurierbar und von Netzlast (Antwortverhalten) abhängig
•	Listen auf Patient-, Arzt-, Praxisebene 
•	automatisch füllen durch eingegebene Phrasen, die noch nicht enthalten sind
•	während der Benutzung zum Füllen von Feldern bearbeitbar - löschen, duplizieren, ergänzen, ändern
•	Tastensteuerung 
•	vergleiche Mutt (http://www.mutt.org)
•	intern symbolische Aktionen
•	arbiträre, freie Zuordnung von Tastenkombinationen zu Aktionen 
•	Strg+NN
•	ALT+NN
•	SHIFT+einige
•	Enter 
•	“Ausführen”
•	“Übernehmen”
•	ESC 
•	“zurück” stufenweise bis zu unterster Ebene
•	dort durch fortlaufend ESC rotieren durch Übersicht aktueller Patient/Warteliste/Patientensuche/Terminkalender heute/etc (Konfig)
•	Leertaste 
•	markieren in Listen
•	Funktionstasten
•	Ziffernblock
•	direkt Einzelbuchstaben
•	Tabulator / STRG-I o.ä. 
•	Kontext der Cursorposition “expandieren” / “detaillieren”
Programmelemente
•	Onlinehilfe 
•	Integriertes Handbuch
•	Hilfetaste <F1> mit Erläuterungen 
•	kontext- bzw. feldbezogen
•	Handbuchtexte und Beispiele sofort verfügbar
•	erspart das mühsame Blättern im Handbuch
•	nutzerbezogene Hilfeebenen (Einsteiger, Fortgeschrittener, Experte)
•	1. x F1 bringt Hilfeleiste mit Tastenkürzeln unterste Bildschirmzeile
•	2. x F1 bringt kontextsensitive, ausführliche Hilfe (ggf. mit Themenwahl)
•	3. x F1 bringt Index des kompletten Handbuchs
•	Datumsfelder
•	Textfelder 
•	konsequente Datenbankanbindung über immer gleiche Tastenkombination
•	stets Sprung in mehrstufige Listen ermöglichen (spezifisch für: Patient -> Arzt -> Praxis -> amtlicher Stamm)
•	Makros
•	Platzhalter
•	Filter für Rückgabewerte
•	Fehlertoleranz bei Eingaben
•	Plausibilitätsprüfungen 
•	z.B.: liegt Anfangs- vor Enddatum ?
•	automatische Komplettierung 
•	beim Tippen von Worten erscheint ab 2-3 Buchstaben eine Liste aller darauf passenden Worte
•	die Liste der angebotenen Worte ist nach Häufigkeit des bisherigen Vorkommens sortiert
•	Sortierschwelle aber nicht absolute Häufigkeit (dadurch würden die häufigsten Begriffe ständig die Plätze vertauschen), sondern prozentuale Häufigkeitsunterschiede
•	bei Tippen eines Worttrenners (Leertaste, Zeilenende, Tab, “-”) 
•	Prüfung, ob Wort in z.B. Diagnosendatei vorhanden 
•	ja: Markierung setzen, nach nächstem Wort auf Phrase testen
•	nein: Markierung löschen, vorheriges Wort auf Diagnose prüfen, ggf. als Diagnose übernehmen
•	natürlich auch manuelle Markierung als Diagnose möglich
•	bei Tippen eines Phrasentrenners (»,« »;« ».« »!« »?«) 
•	Prüfen, ob Phrase in z.B. Diagnosendatei
•	Hauptprogramm 
•	nicht modal
•	zu jeder Zeit beliebig nebeneinander patientenspezifische Module aufrufbar
•	diese im Einzelnen können quasi-modal ablaufen (wie ein “Wizard”, immer ein Schritt nach dem anderen)
•	Programmfenster, die zu einem Patienten gehören 
•	müssen leicht als zueinander gehörig identifizierbar sein
•	auf Anforderung alle Fenster dieses Patienten schließen
•	Listenfenster 
•	automatisch auf Inhaltsgröße zoomen
•	vorhersagbare Positionierung
•	optische Orientierungshilfen 
•	Rahmen, Beschriftungen, etc. sollen in den Hintergrund sinken
•	der Nutzer soll anhand des Vorhandenseins/der Hervorhebung (Farbe, Dicke, Schriftart) von Text erkennen können, ob wichtige Einträge, wie Allergien, Warnungen, o.ä. zu beachten sind, dies soll nicht erst durch das interne Beantworten der Frage: “Ist das mit 'Allergie' überschriebene Feld leer ?” zu ermitteln sein
•	redundante Beschriftungen sollen nicht vorkommen
•	Module 
•	die verfügbaren Module sollen an die Art des Arbeitsplatzes angepaßt sein
•	Module für die gleiche Funktionalität müssen für unterschiedliche Plätze nicht identisch sein 
•	z.B. Dokumentenarchiv 
•	am Scannerarbeitsplatz ist ein umfangreiches Modul mit vielen Manipulationsmöglichkeiten wünschenswert
•	in den Sprechzimmer reicht ein einfaches Modul mit Darstellung, Zoom, Verschieben
•	an einem Sono-Arbeitsplatz wiederum eine Mischung aus beiden
•	die Verfügbarkeit soll festlegbar sein, z.B. über eine Liste mit den zu ladenden Modulen
•	an der Rezeption z.B. KVK-Modul, Eingabe Stammdaten, Formulardruck, Terminkalender
•	im Sprechzimmer hingegen z.B. Kartei, Formularerstellung, Ansicht Stammdaten, Dokumentenarchiv
Programmkonfiguration
Die Konfiguration dient dazu, eine Software dem jeweiligen Benutzer und seiner Umgebung bestmöglich anzupassen. Es müssen aber andere Aspekte beachtet werden:
•	exzessive Konfigurationsmöglichkeiten können die Geschwindigkeit des Programmablaufs negativ beeinflussen
•	fehlende Konfigurationseinstellungen dürfen die Funktionsfähigkeit der Software nicht verringern
Es gibt mehrere Arten von Konfigurationsdaten:
a) abhängig vom Bediener, unabhängig vom Arbeitsplatz
 	
•	KV-Nummer
•	Stempeleinstellungen
•	Zugriffsrechte
•	Farbeinstellungen
•	kollegenspezifische Anrede für Schnellbriefe
•	Warteliste 
•	für diesen Kollegen soll immer die persönliche Warteliste voreingestellt sein
b) unabhängig vom Bediener, unabhängig vom Arbeitsplatz
 	
•	Praxisart 
•	Einzelpraxis, Praxisgemeinschaft, Gemeinschaftspraxis, etc.
•	Einstellungen zur EDV-Abrechnung
•	patientenabhängige Spezifika 
•	welches Profil beim Anzeigen von Labordaten war zuletzt gewählt ?
•	Budgetgrenzwerte
•	Warteliste 
•	welche Wartelisten sind überhaupt verfügbar
c) unabhängig vom Bediener, abhängig vom Arbeitsplatz
 	
•	Fähigkeit zur Darstellung von Grafiken
•	Anbindung medizinischer Geräte
•	Art des KVK-Kartenlesers
•	Druckerzuordnung
•	Spiegelung von Daten
•	verfügbare Programmmodule 
•	z.B. Anmeldung: nur Formulardruck und KVK-Handling
•	Warteliste 
•	im Sonoraum soll immer automatisch die Warteliste “Herzecho” aufgerufen werden
d) abhängig vom Bediener und vom Arbeitsplatz
 	
•	Warteliste 
•	für Kollegen A soll im Sonoraum immer Warteliste “Herzecho” gezeigt werden
•	Kollege B kann kein Herzecho, behandelt aber im Sonoraum Patienten, also immer Warteliste “Kollege B” auch im Sonoraum anzeigen
Prinzipiell sollte man mit zwei Tabellen auskommen:
•	für Typ a), c) und d) 
    .---------------------------------------.
    | Nutzer | Arbeitsplatz | Option | Wert |
    `---------------------------------------'
    
•	Für Typ b) 
    .---------------------------------.
    | Patientennummer | Option | Wert |
    `---------------------------------'
    
Bei Patientenunabhängigkeit könnte die Patientennummer -1 lauten.
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.
Konfiguration von Ja/Nein-Optionen
 	
•	wo sinnvoll, sogenannte Quad-Options (siehe Mutt) oder Untermenge davon: 
•	auto-yes
•	auto-no
•	ask-default=yes
•	ask-default=no
Sonstige Konzepte
•	Daten in Textformaten, soweit sinnvoll
•	alle anderen Formate offengelegt
•	Programmreaktionszeit für sprechstundenrelevante Aufgaben muß immer kleiner 500ms sein
•	Kontakt mit Kodierung nur dort für den Anwender notwendig, wo unumgänglich (aber natürlich überall möglich)
•	eigene Ergänzungen und “offizielle” Daten dürfen sich nie überschneiden (ein “Update” darf niemals nicht praxisspezifisch erstellte Formulare überschreiben)
•	Auswahlmöglichkeiten (z.B. Formularliste o.ä.) dürfen nie durch arbiträre Faktoren (Fenstergröße, verfügbare Buchstaben als Aufrufkürzel o.ä.) begrenzt werden
•	saubere Trennung der Abrechnung und Kodierung (ICD) von der eigentlichen, übergeordneten Dokumentation 
•	aber vielfältige Schnittstellen
•	dadurch ärztliche Dokumentation fördern, ohne Abrechnung zu stark zu gefährden
•	Diagnosenliste an sich und Zuordnungsliste Code<->Diagnosentext sind verschiedene Liste !!
•	Zuordnungsliste Code<->amtliche Bezeichnung ist eine dritte Liste !!
•	aussagekräftige Fehlermeldungen 
•	was geht warum nicht
•	was soll der Anwender tun
•	explizit Dateinamen und -pfade angeben
•	Hinweis auf Fehlerlog
•	aussagekräftige Fehlerlogs 
•	Ursachenforschung ermöglichen
•	aussagekräftige Nutzerabfragen: 
•	warum Nutzerabfrage (“Es soll ... getan werden. Das geht nicht automatisch, weil ...”
•	aktuelle Daten zeigen, die die Abfrage auslösen
•	Lösungsmöglichkeiten aufzeigen
•	Nutzergemeinschaft fördern 
•	versenden erstellter Formulare/Vordrucke/etc. per Knopfdruck an Mailingliste/Webseite
•	gemeinsames, automatisiertes Pflegen von Listen (ICD, Rechtschreibung)
•	Querverweise, die aus der Praxis hinausführen (Internet, Praxisnetz) müssen klar erkennbar sein
•	die Software soll auch unter widrigen Umständen funktional bleiben, z.B.: 
•	bei Nichterreichbarkeit des Datenbankservers soll einfach ein alternativer Server angegeben werden können
•	fehlende Konfigurationseinstellungen dürfen den Programmablauf nicht verhindern
•	Fehlerlogs sollen nur geschrieben werden, wenn Platz vorhanden ist
•	wenn die Software von einem read-only Medium (CD) gestartet wird, sollen Zustandsdaten (temporäre Dateien, Logdateien, Konfigurationsdateien) auch in anderen als den Standardverzeichnissen abgelegt werden können
•	konservativ 
•	die Software soll bei eigenen Entscheidungen auf der sicheren Seite bleiben, z.B. bei Unklarheit Daten lieber doppelt speichern und den Nutzer darüber informieren, als sich auf mglw. unzuverlässige Programmlogik zu stützen
•	z.B. Löschen von Laborimportdateien erst nach einer festlegbaren Zeitspanne
•	Zustandsfreiheit 
•	Prozesse sollten möglichst wenig von transienten Zuständen im RAM abhängig sein - Plattenplatz ist billig !
•	checkpoints mit Wiederaufnahme des Ablaufs von dort
•	z.B. halb ausgefüllte Formulare können beliebig oft abgebrochen und weitergeführt werden
•	sicher
•	autonom - do one task and do it well
Funktionalität im Detail
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 the Section called technische Details unter dem jeweils betreffenden Bereich aufgeführt.
Aufnehmen eines Patienten (Rezeption/Anmeldung)
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.
mit Chipkarte
 	Die Liste der gegenwärtig eingelesenen, aber noch nicht übernommenen Chipkarten erscheint. Der Anwender wählt eine Chipkarte aus.
•	der Patient existiert noch nicht in der Datenbank 
•	ein neuer Patientendatensatz wird angelegt
•	die Stammdaten werden von der Karte übernommen
•	die Kartendaten werden abgespeichert
•	bei ungültiger Karte werden Krankenkasse und Status manuell erfragt
•	bei gültiger Karte werden (ggf. per Tabelle korrigierte) Krankenkasse und Status übernommen
•	der Patient existiert schon in der Datenbank 
•	bei Mehrfachtreffern muß der Anwender auswählen
•	geänderte Kartendaten werden abgespeichert
•	geänderte Adressdaten werden feldweise/gesamthaft zur Übernahme angeboten, wobei Unterschiede nebeneinander dargestellt werden
•	falls Kartendaten nicht geändert aber Stammdaten anders 
•	falls Markierung “Karte falsch” gesetzt 
•	nur Hinweis an Anwender, kein Übernahmezwang
•	falls Markierung “Karte falsch” noch nicht gesetzt 
•	Hinweis an Anwender
•	Abfrage, ob Datenübernahme (komplett/teilweise) anhand KVK
•	Markierung “Karte falsch” entsprechend setzen
•	bei gültiger Karte wird ggf. ein Kassen-/Statuswechsel durchgeführt
•	Karte ist ungültig (abgelaufen) 
•	Warnung an Anwender
•	Einlesedatum für Karte wird nicht gesetzt
•	Karte ist gültig 
•	Einlesedatum für Karte wird gesetzt
ohne Chipkarte
 	
•	Name, Vorname und Geburtsdatum werden abgefragt.
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.
•	Nach Vervollständigung von Name und Geburtsdatum wird die Postleitzahl abgefragt. Daraus abgeleitet werden Vorwahl, Ortsliste, Straßenliste und Wegegeldzone/Entfernung in Kilometern.
•	Die Straße wird als nächstes eingegeben. Es müssen nur einige Buchstaben getippt werden, dann kann man aus einer Liste passender Straßen wählen. Diese Liste ist durch die PLZ schon so stark eingeschränkt, daß ein oder zwei Buchstaben reichen sollten. In Verbindung mit der PLZ läßt sich aus dem Straßennamen der Ortsname fast immer eindeutig ableiten.
•	Die Hausnummer wird erfragt.
•	Der Ortsname wird, falls noch nicht eindeutig, jetzt gewählt.
•	Die Krankenkasse wird gewählt, ebenso der Versichertenstatus.
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 ...
•	Arbeits-/Wegeunfall ? 
•	ein BG-Fall wird angelegt
•	die BG-Grunddaten werden abgefragt
•	Überweisungsfall 
•	der Überweiser wird eingetragen (Briefempfänger, etc.)
•	Art der Überweisung (Mit-/Weiterbehandlung, ...)
•	bei Kassenpatienten wird ein Überweisungsfall angelegt
•	normaler Fall während der Sprechzeiten 
•	ein Behandlungsfall wird angelegt
•	bei fehlender Chipkarte wird ein Ersatzschein gedruckt
•	normaler Fall außerhalb der Sprechzeiten 
•	ein Notfall-Fall wird angelegt
•	bei Kassenpatienten wird ein Notfallschein gedruckt
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.
Aufruf eines Patienten (Behandlungsraum)
mit KVK
Im Sprechzimmer soll die Übersicht zu den Daten des Patienten (siehe the Section called Überblick über die Daten eines Patienten) direkt auf den Schirm gebracht und der Aufruf in der Kartei mit Zeit vermerkt werden.
manuell
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:
•	Umlaute müssen hin- und her übersetzt werden 
•	Müller <-> Mueller
•	f <-> ph
•	Komplettierung/Trunkierung 
•	Suche “Mül” findet Müller, Müler, Mülte, Mueltholz, etc.
•	Wildcards 
•	Suche “M?ll” findet Müller, Möller, Mallis, etc
•	Suche “Rot+e” findet Rote und Rothe
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.
aus der Warteliste/dem Terminkalender
Wenn der Patient z.B. an der Anmeldung in die Warteliste oder den Terminkalender gestellt wurde, kann man ihn von dort auswählen.
von extern per xDT
Externen Programmen sollte es möglich sein, per definierter Schnittstelle dem Programm einen Patientenaufruf mitzuteilen.
aus einer Patientenliste
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.
Überblick über die Daten eines Patienten
Variante 1 - Dr. Colberg
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:
•	Stammdaten incl. Foto 8%
•	Versicherungsdaten 2%
•	Cave-Einträge 5%
•	Problemliste mit Diagnosen usw. 30%
•	Medikation 30%
•	ausstehende Dinge 25%
Variante 2 - Karsten Hilbert
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):
•	Stammdaten 
•	evtl. Photo
•	Name
•	Geschlecht
•	Adresse
•	Kontaktmöglichkeiten
•	Versicherungsdaten 
•	Art der Kasse (privat/gesetzlich)
•	Name der Kasse (...)
•	existieren offene BG-Fälle ?
•	Cave-Einträge 
•	Allergien
•	eigene Hinweise/Kurznotizen
•	zu beachtende Medikation
•	Schwangerschaft
•	Einträgen muß ein Verfallsdatum zugeordnet werden können 
•	“nie” (z.B. “Atemnot nach Ketoconazol”)
•	“in nn Tagen/Wochen/Monaten” (z.B. “ist schwanger”)
•	“beim nächsten Besuch” (z.B. “nach Haustier fragen”)
•	medizinische Problemliste/Letzter Kontakt 
•	Diagnosen/Episoden 
•	jünger als konfigurierbares Höchstalter, außer als chronisch markierte
•	STRG-I zeigt Detailinfos 
•	alle zugehörigen Behandlungstage
•	abhängig von Diagnose: welche Untersuchungen liegen (nicht) vor
•	wann zuletzt deswegen
•	ggf. hierarchisch geordnet (von mir zugeordnet)
•	dieser Bereich sollte (in der Tab-Reihenfolge) beim Aufruf der Übersicht gewählt sein
•	Medikation 
•	zuletzt verschriebene oben bzw. markiert
•	warum verschrieben (ein/zwei Worte, müssen von mir zugeordnet worden sein)
•	wann verschrieben
•	ob lt. Packungsgröße/Einnahmefrequenz alle oder nicht
•	dieser Bereich sollte nach Aufruf der Übersicht durch einmal Tab erreichbar sein
•	Markieren mit Leertaste und z.B. Strg-D erzeugt ein neues Rezept
•	ausstehende Dinge (Recall, Todo, Termine) 
•	Impfungen
•	sonstige Dinge, die zu tun sind
•	wenn Termin vorhanden: wie lange überschritten/wie lange noch bis hin
•	Wiedervorlage von Diagnosen (Frequenz muß von mir zugeordnet werden)
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).
Patientendaten im Hausbesuch
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 :
•	Export von Patientendaten auf Papier oder als Datei
•	das Dateiformat muß textbasiert sein, um alle Zielgeräte zu unterstützen
•	es sollten 3 Formate unterstützt werden 
•	maschinenlesbar strukturiert 
•	zum Einsatz auf einem vollwertigen portablen Rechner
•	HTML 
•	für portable Geräte mit Browser
•	ASCII 
•	für sonstige Geräte
•	es sollten Gruppen von Patienten für typische Hausbesuchsrunden definierbar sein, z.B. alle Bewohner eines bestimmten Heimes
•	Hausbesuchsexport von Patientendaten soll die Daten in der Praxis nicht gegen Bearbeitung sperren, es soll aber eine Warnung angezeigt werden
•	innerhalb der Möglichkeiten der portablen Technik soll ein Rückfluß von Daten möglich sein
•	der Datenrückfluß muß die Daten zusammenführen, nicht Versionen überschreiben, es soll also ein paralleles Ändern der Daten möglich sein -- soweit das technisch lösbar ist
•	die Software eines PDA sollte das Ausdrucken von Formularen auf dem patienteneigenen Drucker ermöglichen (ja ja, das Treiberproblem ...), z.B. per USB, Infrarot, BlueTooth oder Wireless LAN
•	ein PDA sollte möglichst gleich eine Möglichkeit zum Einlesen und Übertragen der Chipkarte in die Praxis-EDV aufweisen (gibt es dafür PCMCIA-Karten ?) 
•	ein Problem hierbei könnte die Zertifizierungspflicht sein
Eine nützliche Minimallösung ist aber schon die Exportmöglichkeit der derzeit aktuellen Daten der Praxis zur Mitnahme zum Hausbesuch.
Medizinisches Dokumentieren
Es klingt sinnvoll, zunächst mit nicht zulassungspflichtigen Programmteilen anzufangen. Das wäre im Wesentlichen die medizinische Dokumentation.
Modellvorstellung
•	Problemliste/Zielliste 
•	kann identisch werden mit Episodenliste
•	aktiv vs. inaktiv
•	nicht nur medizinisch (Diagnosen), auch Soziales, Syndrome, etc.
•	ggf. zugeordnete Daten
•	Wiedervorstellungsautomatik je KH-Bild
•	Episodenstruktur 
•	analog Niederlande
•	http://www.phcsg.org.uk/conferences/cambridge1998/westerhof.htm
•	Komplettfassung, aber nur in Niederländisch
Episode:
 	Zeitdauer eines Gesundheitsproblems im Zustand “aktiv”
Kontakt:
 	ein Arztbesuch wegen eines oder mehrerer Probleme
Teilkontakt:
 	Bearbeitung eines Problems während eines Arztbesuches. In der el. Kartei durch mehrere Einträge dargestellt.
Zeile:
 	Eine physikalische Zeile mit Patientendaten in der elektronichen Kartei. Eine oder mehrere Zeilen bilden einen Eintrag.
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.
Stammdaten des Patienten
Verwandschaftsverhältnisse
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.
fortlaufende Dokumentation in der Sprechstunde
Variante Karsten Hilbert
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:
•	Datum
•	Tageszeit
•	zur Zeit des Eingebens gewählter Benutzer
•	Typ des Eintrags (Anamnese, Befund, Therapie, Diagnose, etc.)
•	zugehörige Episode
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:
•	alle aus der Datumsspalte
•	weitere mögliche Gruppen mit Kürzel und Beschreibung
•	per word-wheel kann man eine andere Markierung wählen
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:
•	alles Episoden
•	alle außer die aktuell gewählte
Markieren ...
 	... 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.
Bewegen ...
 	... 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.
Autokomplettierung ...
 	... 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.
Makros und Platzhalter ...
 	... 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 ...
... automatische Diagnosenerkennung
 	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:
•	ICD-Code
•	relevanter ICD-Pfad (Kapitel, etc.)
•	offizieller ICD-Text
•	Aufruf von relevanten Fachinformationen
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:
•	“APGAR” oder “GCS” öffnen entsprechende Masken
•	“Finger”, “Fing.”, “Dig” o.ä. öffnen eine Abfrage “rechts/links” und “1-5”, sofern diese Angaben nicht schon vor “Finger” stehen
•	“Tetanus”, “Tet.”, “Td” o.ä. lösen aus: “aktuell (˜)”, “Boosterung erfolgt”, “zuletzt ˜” (eigentlich gehört diese Angabe unter “Anamnese” - der Mechanismus müßte also auch dort greifen, ggf. mit anderen Schlüsselworten)
•	“Monitoring” erzeugt “Zeit: ˜:˜, RR: ˜/˜, Puls: ˜, SpO2: ˜%”
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:
•	privat -> BG -> privat
•	Kasse -> BG -> privat -> Kasse
•	Reihenfolge konfigurierbar
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).
Variante Dr. Hahn
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:
Anamnese
 	Patient klagt seit 3 Tagen über Schmerzen in der re. Hand. Bekannte rheumatoide Arthritis, Gicht, Herzinsuffizienz.
Befund
 	DS über A1-Ringband 3 und 4 re
Diagnose
 	TVS 3und 4 re
Therapie
 	Injektion mit Cortison und LA
ICD
 	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.
Variante Dr. Colberg
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...)
Sonstiges
•	Import von Werten aus Fremdprogrammen
•	weitestmöglich automatische Führung des EHR
•	Sofortanzeige: Sofortige Anzeige wichtiger Informationen beim Aufruf des Patienten. Risikopatientenüberwachung, Impfkontrolle, Nachsorge.
•	Recallverfahren, durchzuführende Leistungen.
•	AODT - Basisdokumentation ambulantes Operieren: elektronische Erfassung der Dokumentationsbögen und Ausgabe auf Diskette zur Einreichung bei der KV
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.
grafisch gestützte topologische Dokumentation
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
Dokumentenarchiv
(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.
Diagnostizieren
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.
Therapieren
- 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.
Drucken von Formularen
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).
Nutzen von Labordaten
Darstellung
Markierung von Werten außerhalb Normbereich:
•	durch “+++” oder “---”
•	durch “!”
•	durch farbliche Hervorhebung
•	durch anderen Zeichensatz, größere Schrift, anderen Stil (fett, kursiv, ...)
•	Konfigurationsfrage
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:
•	generell nur Kürzel, für die ein Ergebnis vorliegt, werden zeilenweise angezeigt
•	Sortierungreihenfolge nach dem jüngsten vorhandenen Ergebnis
•	bei bestimmter Taste in einer bestimmten Spalte: Sortierung so, daß Zeilen mit Ergebnissen in dieser Spalte (am entsprechenden Tag) direkt untereinander stehen
•	manch einer mag dies nicht
•	sollte als Pseudoprofil “automatische Sortierung” aufrufbar sein
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 (http://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.
Speicherung
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”
•	Kürzel, z.B. Hb
•	volle Bezeichnung, z.B. “Hämoglobin”
•	Kommentar
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” 
•	Labor, z.B. “Labor Dr. Mustermann, Musterstadt”
•	Laborkürzel, z.B. “Hb 1”
•	volle Bezeichnung, z.B. “Hämoglobin, bestimmt mit Gerät XY” - wie im LDT vom Labor geliefert
•	volle Bezeichnung, z.B. “Hämoglobin” (wie in der Praxis, siehe Tabelle “Labortest”)
•	Normalbereich weiblich
•	Normalbereich männlich
•	Normalbereich Einheit
•	Kommentar
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” 
•	volle Bezeichnung, z.B. “Hämoglobin” (wie in der Praxis, siehe Tabelle “Labortest”)
•	EBM, GNR aus dem EBM
•	GNR GOÄ 88
•	GNR GOÄ 96
•	GNR GOÄ BG
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” 
•	Patienten-ID (zu welchem Patienten gehört das Ergebnis)
•	Kürzel, z.B. “Hb” - wie in der eigenen Praxis verwendet, siehe Tabelle “Labortest”
•	Abnahmedatum
•	Ergebniswert
•	Einheit des Ergebnisses
•	Grenzwertindikator (Markierung des Labor von pathologischen Werten)
•	Laborkommentar, z.B. “Hinweis auf stattgehabte Borrelieninfektion”
•	eigener Kommentar (“ach Quatsch ... :-)”)
•	Labor-ID (aus welchem Labor stammt das Ergebnis)
•	Probennummer (welche Nummer hatte die Probe im Labor)
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.
Import
•	mehrere Labore pro Praxis müssen unterstützt werden
•	Import und Übertragung müssen unabhängige Programme sein
•	Übertragung per Diskette
•	Übertragung per Datenleitung 
•	kein einheitliches Protokoll bei den verschiedenen Laboren
•	bereits Perlprogramm vorhanden
•	sollte per Hand auslösbar sein
•	sollte auf Wunsch nachts automatisch erfolgen können
•	externes Programm (nicht GNUmed-intern), Skriptsprache zur leichten Anpassung empfehlenswert
•	per Modem, ISDN oder TCP/IP
•	anschließend Bereitstellung zum Import
•	Praxissoftware sollte bei Einloggen bestimmter Benutzer auf zum Import bereitliegende Labordateien hinweisen
•	Import soll mehrere Quellpfade + Dateinamenmasken für Labordateien erlauben 
•	wenn nur eine Datei auf Pfad + Maske paßt: Import automatisch starten
•	wenn mehrere passen: Auswahl erlauben mit Sonderpunkt “alle nacheinander”
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 !”
Export
•	Export nach außen und programmintern
•	programmintern über Platzhalter
•	Direktansprung des Laborblattes mit Auswahl von Daten für Arztbrief, etc. aus anderen Programmteilen
•	extern als ASCII-Tabelle für Textverarbeitungen
•	extern als LDT bzw. XML
•	andere Formate können per Konvertierung aus LDT/XML erzeugt werden
sonstiges
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)
Planen von Aufgaben/Zeit - Terminkalender Patienten
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
Nutzung von Medikamentendaten
Im Wesentlichen sollen Medikamentendaten zwei Zielen dienen:
•	Verschreiben von Therapien
•	Informationen über Medikamente für den Anwender
Verschreiben von Therapien
Rezeptiert werden die verschiedensten Dinge:
•	Medikamente als Fertigarzneimittel
•	Zubereitungen (Tees, Salben, etc.)
•	Heil- und Hilfsmittel
•	physio-, ergotherapeutische und logopädische Behandlungen
•	kurze Bescheinigungen
Zum Verschreiben von Medikamenten braucht man mindestens folgende Angaben:
•	genaue Bezeichnung des Medikaments (Markenname)
•	Wirkstoff bzw. pharmakologisch aktive Komponenten
•	verfügbare Stärken je Dosierungsart
•	verfügbare Zubereitungsarten
•	verfügbare Packungsgrößen (N1 - N3)
•	aktueller Preis (zum Preisvergleich)
Für diese Daten sind regelmäßige Erneuerungen notwendig, am besten über das Internet, etwa 14-tägig.
Weitere bedeutsame Angaben:
•	Rezeptpflichtigkeit
•	Btm-Rezeptpflichtigkeit
•	Zuzahlungsbetrag für den Patienten
•	Zusatzstoffe
Verschiedene Mechanismen erleichtern das Rezeptschreiben ungemein:
•	Anzeige von CAVE-Einträgen
•	automatische Prüfung auf WeWi/KoInd/SchwSch/Allerg
•	hinterlegte Dosierungsanweisungen
•	Anzeige des aktuellen Medikamentenbudgets
•	bei Wiederverordnung Berechnung, wie lange letzte
•	Verordnung noch gereicht hätte
•	Übernahme vorheriger Verordnungen mit minimalem Aufwand mit Warnung bei Arzneimitteln, die nicht mehr im Handel sind
•	einheitliches Formular für BG/Kasse/Privat mit deutl. Darstellung des Kostenträgers
•	Makros für Kurztexte
•	bequeme Handhabung der Zuzahlungsbefreiung
•	strukturiertes (also wiederverwertbares) Speichern von Dosierungsanweisungen
•	Vorschlag von Äquivalenzpräparaten im Preisvergleich
•	Prüfung gegen Negativ-/Positivlisten
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.
Arzneimittelinformationen
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
•	Kontraindikationen
•	Zusammensetzung mit allen Stoffen (Allergieprüfung)
•	detaillierte Dosierungsempfehlungen (Kinder, Erwachsene, Senioren, Nieren/-Lebererkrankte)
•	Wechselwirkungen
•	Hersteller mit Kontaktinformationen
•	Antidote
•	Wirkmechanismus/-spektrum (Antibiotika)
•	Schwangerschaft/Stillzeit
•	optische Indikation (die große gelbe Kapsel, Herr Doktor)
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.
Ablauf einer Verordnung
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.
Mögliche Datenquellen
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 
•	AMIS
•	IFAP
•	Gelbe Liste IMP
•	Rote Liste
•	Scholz- Datenbank
•	ABDA mit quartalsweisem Update (Preisaktualisierung)
•	Budgetstatistik
•	Medikamente
•	Medikamentendatei mit Übernahmefunktion für Rezept und Statistik
•	Eingabemöglichkeit freier Text (mit Preis für Statistik)
•	Statistische Ausklammerung der Ärztemuster
Importieren von Patientendaten mittels BDT
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.
technische Details
Verarbeitung von Chipkarten (KVK)
•	auch Privatpatienten können eine Chipkarte haben
•	Chipkartendaten sollten getrennt von den “wahren” Stammdaten gespeichert und nicht als autoritativ angesehen werden
•	Fehler, die erfahrungsgemäß auf KVK vorkommen: 
•	falcher Name (Name/Vorname vertauscht, falsch buchstabiert)
•	falsches Geburtsdatum
•	falsche Adresse (z.B. veraltet)
•	falsche Krankenkassendetails 
•	es gibt eine amtliche Korrekturtabelle, die berücksichtigt werden muß
•	das Einlesedatum der Chipkarte muß für den Anwender unveränderlich gespeichert werden, sonst ist keine EDV-Abrechnung zulässig :-))
•	ungültige Karten müssen abgewiesen werden; bei Patienten mit solchen Karten darf theoretisch nicht einmal mehr ein kassenärztliches Formular gedruckt werden, allerdings kann (und muß) aus anderen (medizinischen nämlich) dann ein Ersatzverfahren zur Anwendung kommen
•	für die KVDT-Abrechnung sollte die Adresse auf der Chipkarte verwendet werden, nicht die mglw. abweichende richtige in der Stammdatenbank
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).
Anforderungen an eine Datenbank
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 (http://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.
sonstiges
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.
sonstiges 2
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
Anhänge
GNU Free Documentation License
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.
Danksagungen
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