File: analysis-de.sgml

package info (click to toggle)
resmed-doc 20020327-2
links: PTS
area: main
in suites: etch, etch-m68k, lenny, squeeze
size: 288 kB
ctags: 10
sloc: makefile: 77
file content (4056 lines) | stat: -rw-r--r-- 181,938 bytes
parent folder | download | duplicates (2)
<!doctype linuxdoc system>

<article>

<title>Analysedokument zur Erstellung eines Informationssystems fuer den Einsatz in der Medizin</title>
<author>Mailingliste ResMedicinae-Deutsch <htmlurl url="mailto:resmedicinae-deutsch@lists.sourceforge.net" name="resmedicinae-deutsch@lists.sourceforge.net"></author>
<date>$Date: 2002/03/14 19:48:04 $</date>

<abstract>
Eine gemeinsame Anstrengung vieler Enthusiasten aus den Bereichen der
Medizin, Informatik, ffentlicher Einrichtungen und auch Firmen.
Entstanden unter mageblicher Beteiligung der Mitleser der Mailingliste ResMed-de
<htmlurl url="mailto:resmedicinae-deutsch@lists.sourceforge.net" name="resmedicinae-deutsch@lists.sourceforge.net">.
</abstract>

<toc>

<sect>Administrivia
<p>
Copyright &copy; 1999-2002. Karsten Hilbert, Christian Heller, Roland Colberg, Peter Hahn et al.

<htmlurl url="http://www.resmedicinae.org" name="Res Medicinae -- Information in Medicine -- &lt;www.resmedicinae.org&gt;">

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
&ldquo;GNU Free Documentation License&rdquo;.

Autoren:

<itemize>
<item><htmlurl url="mailto:rcolberg@gmx.de" name="Dr. Roland Colberg &lt;rcolberg@gmx.de&gt;">
<item><htmlurl url="mailto:joachim_fischer@web.de" name="Dr. J. Fischer &lt;joachim_fischer@web.de&gt;">
<item><htmlurl url="mailto:no-spam@somewhere.de" name="Priv.-Doz. Dr. P. Hahn &lt;&gt;">
<item><htmlurl url="mailto:no-spam@somewhere.de" name="Dr. Bernd Heller &lt;&gt;">
<item><htmlurl url="mailto:christian.heller@tuxtax.de" name="Christian Heller &lt;christian.heller@tuxtax.de&gt;">
<item><htmlurl url="mailto:no-spam@somewhere.de" name="Magdalena Heller &lt;&gt;">
<item><htmlurl url="mailto:Karsten.Hilbert@gmx.net" name="Karsten Hilbert &lt;Karsten.Hilbert@gmx.net&gt;">
<item><htmlurl url="mailto:joerg.sigle@jsigle.com" name="Jrg M. Sigle &lt;joerg.sigle@jsigle.com&gt;">
<item><htmlurl url="mailto:jsaucke@t-online.de" name="Jrgen Saucke &lt;jsaucke@t-online.de&gt;">
<item><htmlurl url="mailto:Behrendt.Oedesse@t-online.de" name="Dr. Winfried Behrendt &lt;Behrendt.Oedesse@t-online.de&gt;">
<item><htmlurl url="mailto:streller@t-online.de" name="Dr. med. Andreas Streller &lt;streller@t-online.de&gt;">
<item><htmlurl url="mailto:no-spam@somewhere.de" name="Dr. med. Michael Elisat &lt;&gt;">
<item><htmlurl url="mailto:no-spam@somewhere.de" name="Dr. med. Gerhard Bauer &lt;&gt;">
</itemize>

<em>Hinweis: Der Inhalt basiert auf Version 1.33 der frheren Textversion.</em>

<tscreen>
<verb>
$RCSfile: analysis-de.sgml,v $
@version $Revision: 1.6 $ $Date: 2002/03/14 19:48:04 $ $Author: ncq $
</verb>
</tscreen>

</sect>
<!--
==============================================================================================
-->
<sect>Einleitung
<p>
Vereinfachte Modelle alltglicher, realer Ablufe bilden und sie in Software
umsetzen, um Zeit und Kosten zu sparen, die Qualitt 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 fr Schritt kommt man dann zu einem sinnvollen Ganzen.
Es sollte mglich sein, von einem herkmmlichen System nach und
nach alles bis auf die eigentliche Abrechnung+Statistik zu
ersetzen.

Um real zu starten (in den Arztpraxen) bruchte man: das
Abrechnungsmodul und den Formulardruck. Letzteres ist u.U. noch
machbar. Ersteres mu m.E. von einem Anbieter beigesteuert werden
(nicht kostenfrei natrlich !). Alles andere ist &ldquo;irgendwie&rdquo; bereits
vorhanden, machbar, &ldquo;anstrickbar&rdquo;. Durch die Offenheit des gesamten
Systems wre dieses &ldquo;Anstricken&rdquo; auch kein Problem, da nach und nach
alle Hacks durch ordentlich implementierte Module ersetzt werden 
knnen, ohne die Gesamtheit zu gefhrden. Und die Offenheit vertuscht 
auch die noch vorhandenen Hacks nicht, soda man immer wei, wo 
dringend Arbeit ntig ist.
</p>
</sect>
<!--
=============================================================================
-->
<sect>Konzepte und Prinzipien

<sect1>Programmsteuerung

<p>
<itemize>
<item>notwendige Aktionen der Anwender minimieren
    <itemize>
    <item>Anzahl Tastendrcke</item>
    <item>Wechsel Maus/Tastatur</item>
    <item>dabei aber Mglichkeiten der Anwender zum Abweichen vom Standardvorgehen erhalten</item>
    </itemize>
</item>

<item>trotz grafischer Oberflche durchgngig Bedienung mittels Tastatur ermglichen</item>

<item>Platzhalter
    <itemize>
    <item>Platzhalter: Krzel, das in lngeren Text umgewandelt werden kann</item>
    <item>in allen Feldern mit Texteingabe bereitstellen</item>
    <item>programmweit konsistent</item>
    <item>kontextabhngig (vom gewhlten Patienten, etc.)</item>
    <item>manuell umwandeln nach z.B. STRG-M</item>
    <item>automatisch umwandeln (z.B. beim Laden einer Schnellbriefvorlage) von speziell formatierten Platzhaltern, wie $SHT$ -> Schdel-Hirn-Trauma</item>
    <item><em>alle</em> Daten der Datenbank sollen (je nach Zugriffsrechten) per Platzhalter verfgbar sein</item>
    <item>Platzhalter sind intern Skripte, z.B. in \GNUmed\Platzhalter\</item>
    <item>diese Skripte knnen einfach Text zurckliefern oder beliebig komplexe Aktionen ausfhren</item>
    </itemize>
</item>

<item>Auswahl aus Listen
    <itemize>
    <item>Texteingaben mit (teils kontextabhngigen) Listen hinterlegen</item>
    <item>mehrstufige Datenbankanbindung (pro Patient, pro Arzt, pro Praxis, amtlicher Stamm)</item>
    <item>amtliche Stmme nur lesbar (PLZ, BLZ, Kassen, etc.)</item>
    <item>Suche per word wheel und Suchfunktion
	<itemize>
	<item>beim Tippen erscheinen die bisherigen Treffer</item>
	<item>1 Buchstabe - alle Phrasen, die damit beginnen</item>
	<item>2 Buchstaben - alle Phrasen, die ein Wort enthalten, welches damit beginnt</item>
	<item>4 Buchstaben - alle Phrasen, die diese Sequenz beinhalten</item>
	<item>Schwellen (1,2,4) konfigurierbar und von Netzlast (Antwortverhalten) abhngig</item>
	</itemize>
    </item>	
    <item>Listen auf Patient-, Arzt-, Praxisebene
	<itemize>
	<item>automatisch fllen durch eingegebene Phrasen, die noch nicht enthalten sind</item>
	<item>whrend der Benutzung zum Fllen von Feldern bearbeitbar - lschen, duplizieren, ergnzen, ndern</item>
	</itemize>
    </item>
    </itemize>
</item>
<item>Tastensteuerung
    <itemize>
    <item>vergleiche Mutt (<tt>http://www.mutt.org</tt>)
    <item>intern symbolische Aktionen
    <item>arbitrre, freie Zuordnung von Tastenkombinationen zu Aktionen
	<itemize>
	<item>Strg+NN
	<item>ALT+NN
	<item>SHIFT+einige
	<item>Enter
	    <itemize>
    	    <item>&ldquo;Ausfhren&rdquo;
    	    <item>&ldquo;bernehmen&rdquo;
	    </itemize>
	</item>
	<item>ESC
	    <itemize>
    	    <item>&ldquo;zurck&rdquo; stufenweise bis zu unterster Ebene
    	    <item>dort durch fortlaufend ESC rotieren durch bersicht aktueller Patient/Warteliste/Patientensuche/Terminkalender heute/etc (Konfig)
	    </itemize>
	</item>
	<item>Leertaste
	    <itemize>
    	    <item>markieren in Listen
	    </itemize>
	</item>
	<item>Funktionstasten
	<item>Ziffernblock
	<item>direkt Einzelbuchstaben
	<item>Tabulator / STRG-I o..
	    <itemize>
	    <item>Kontext der Cursorposition &ldquo;expandieren&rdquo; / &ldquo;detaillieren&rdquo;
	    </itemize>
	</item>
	</itemize>
    </itemize>
</item>
</itemize>
<!--
=============================================================================
-->
<sect1>Programmelemente

<p>
<itemize>
<item>Onlinehilfe
    <itemize>
    <item>Integriertes Handbuch
    <item>Hilfetaste &lt;F1&gt; mit Erluterungen
	<itemize>
	<item>kontext- bzw. feldbezogen
	<item>Handbuchtexte und Beispiele sofort verfgbar
	<item>erspart das mhsame Blttern im Handbuch
	</itemize>
    </item>
    <item>nutzerbezogene Hilfeebenen (Einsteiger, Fortgeschrittener, Experte)
    <item>1. x F1 bringt Hilfeleiste mit Tastenkrzeln unterste Bildschirmzeile
    <item>2. x F1 bringt kontextsensitive, ausfhrliche Hilfe (ggf. mit Themenwahl)
    <item>3. x F1 bringt Index des kompletten Handbuchs
    </itemize>
</item>

<item>Datumsfelder

<item>Textfelder
    <itemize>
    <item>konsequente Datenbankanbindung ber immer gleiche Tastenkombination
    <item>stets Sprung in mehrstufige Listen ermglichen (spezifisch fr: Patient -> Arzt -> Praxis -> amtlicher Stamm)
    <item>Makros
    <item>Platzhalter
    <item>Filter fr Rckgabewerte
    <item>Fehlertoleranz bei Eingaben
    <item>Plausibilittsprfungen
	<itemize>
	<item>z.B.: liegt Anfangs- vor Enddatum ?
	</itemize>
    </item>
    <item>automatische Komplettierung
	<itemize>
	<item>beim Tippen von Worten erscheint ab 2-3 Buchstaben eine Liste aller darauf passenden Worte
	<item>die Liste der angebotenen Worte ist nach Hufigkeit des bisherigen Vorkommens sortiert
	<item>Sortierschwelle aber nicht absolute Hufigkeit (dadurch wrden die hufigsten Begriffe stndig die Pltze vertauschen), sondern prozentuale Hufigkeitsunterschiede
	<item>bei Tippen eines Worttrenners (Leertaste, Zeilenende, Tab, &ldquo;-&rdquo;)
	    <itemize>
    	    <item>Prfung, ob Wort in z.B. Diagnosendatei vorhanden
    		<itemize>
    		<item>ja: Markierung setzen, nach nchstem Wort auf Phrase testen
		<item>nein: Markierung lschen, vorheriges Wort auf Diagnose prfen, ggf. als Diagnose bernehmen
		<item>natrlich auch manuelle Markierung als Diagnose mglich
		</itemize>
	    </item>
	    </itemize>
	</item>
	<item>bei Tippen eines Phrasentrenners (&raquo;,&laquo; &raquo;&semi;&laquo; &raquo;.&laquo; &raquo;!&laquo; &raquo;?&laquo;)
	    <itemize>
    	    <item>Prfen, ob Phrase in z.B. Diagnosendatei
    	    </itemize>
	</item>
	</itemize>
    </item>
    </itemize>
</item>

<item>Hauptprogramm
    <itemize>
    <item>nicht modal
    <item>zu jeder Zeit beliebig nebeneinander patientenspezifische Module aufrufbar
    <item>diese im Einzelnen knnen quasi-modal ablaufen (wie ein &ldquo;Wizard&rdquo;, immer ein Schritt nach dem anderen)
    </itemize>
</item>

<item>Programmfenster, die zu <em>einem</em> Patienten gehren
    <itemize>
    <item>mssen leicht als zueinander gehrig identifizierbar sein
    <item>auf Anforderung alle Fenster dieses Patienten schlieen
    </itemize>
</item>

<item>Listenfenster
    <itemize>
    <item>automatisch auf Inhaltsgre zoomen
    <item>vorhersagbare Positionierung
    </itemize>
</item>

<item>optische Orientierungshilfen
    <itemize>
    <item>Rahmen, Beschriftungen, etc. sollen in den Hintergrund sinken
    <item>der Nutzer soll anhand des Vorhandenseins/der Hervorhebung (Farbe,
	    Dicke, Schriftart) von Text erkennen knnen, ob wichtige Eintrge,
	    wie Allergien, Warnungen, o.. zu beachten sind, dies soll nicht
	    erst durch das interne Beantworten der Frage: &ldquo;Ist das mit 'Allergie'
	    berschriebene Feld leer ?&rdquo; zu ermitteln sein
    <item>redundante Beschriftungen sollen nicht vorkommen
    </itemize>
</item>

<item>Module
    <itemize>
    <item>die verfgbaren Module sollen an die Art des Arbeitsplatzes angepat sein
    <item>Module fr die gleiche Funktionalitt mssen fr unterschiedliche Pltze nicht identisch sein
	<itemize>
	<item>z.B. Dokumentenarchiv
	    <itemize>
	    <item>am Scannerarbeitsplatz ist ein umfangreiches Modul mit vielen Manipulationsmglichkeiten wnschenswert
	    <item>in den Sprechzimmer reicht ein einfaches Modul mit Darstellung, Zoom, Verschieben
	    <item>an einem Sono-Arbeitsplatz wiederum eine Mischung aus beiden
	    </itemize>
	</itemize>
    <item>die Verfgbarkeit soll festlegbar sein, z.B. ber eine Liste mit den zu ladenden Modulen
    <item>an der Rezeption z.B. KVK-Modul, Eingabe Stammdaten, Formulardruck, Terminkalender
    <item>im Sprechzimmer hingegen z.B. Kartei, Formularerstellung, Ansicht Stammdaten, Dokumentenarchiv
    </itemize>
</item>

</itemize>
<!--
=============================================================================
-->
<sect1>Programmkonfiguration

<p>
Die Konfiguration dient dazu, eine Software dem jeweiligen Benutzer und seiner Umgebung
bestmglich anzupassen. Es mssen aber andere Aspekte beachtet werden:

<itemize>
<item>exzessive Konfigurationsmglichkeiten knnen die Geschwindigkeit des Programmablaufs negativ beeinflussen
<item>fehlende Konfigurationseinstellungen drfen die Funktionsfhigkeit der Software nicht verringern
</itemize>

Es gibt mehrere Arten von Konfigurationsdaten:

<descrip>
<tag>a) abhngig vom Bediener, unabhngig vom Arbeitsplatz</tag>
    <itemize>
    <item>KV-Nummer
    <item>Stempeleinstellungen
    <item>Zugriffsrechte
    <item>Farbeinstellungen
    <item>kollegenspezifische Anrede fr Schnellbriefe
    <item>Warteliste
	<itemize>
	<item>fr diesen Kollegen soll immer die persnliche Warteliste voreingestellt sein
	</itemize>
    </item>
    </itemize>

<tag>b) unabhngig vom Bediener, unabhngig vom Arbeitsplatz</tag>
    <itemize>
    <item>Praxisart
	<itemize>
	<item>Einzelpraxis, Praxisgemeinschaft, Gemeinschaftspraxis, etc.
	</itemize>
    </item>
    <item>Einstellungen zur EDV-Abrechnung
    <item>patientenabhngige Spezifika
	<itemize>
	<item>welches Profil beim Anzeigen von Labordaten war zuletzt gewhlt ?
	</itemize>
    </item>
    <item>Budgetgrenzwerte
    <item>Warteliste
	<itemize>
	<item>welche Wartelisten sind berhaupt verfgbar
	</itemize>
    </item>
    </itemize>

<tag>c) unabhngig vom Bediener, abhngig vom Arbeitsplatz</tag>
    <itemize>
    <item>Fhigkeit zur Darstellung von Grafiken
    <item>Anbindung medizinischer Gerte
    <item>Art des KVK-Kartenlesers
    <item>Druckerzuordnung
    <item>Spiegelung von Daten
    <item>verfgbare Programmmodule
	<itemize>
	<item>z.B. Anmeldung: nur Formulardruck und KVK-Handling
	</itemize>
    </item>
    <item>Warteliste
	<itemize>
	<item>im Sonoraum soll immer automatisch die Warteliste &ldquo;Herzecho&rdquo; aufgerufen werden
	</itemize>
    </item>
    </itemize>

<tag>d) abhngig vom Bediener und vom Arbeitsplatz</tag>
    <itemize>
    <item>Warteliste
	<itemize>
	<item>fr Kollegen A soll im Sonoraum immer Warteliste &ldquo;Herzecho&rdquo; gezeigt werden
	<item>Kollege B kann kein Herzecho, behandelt aber im Sonoraum Patienten, also immer Warteliste &ldquo;Kollege B&rdquo; auch im Sonoraum anzeigen
	</itemize>
    </item>
    </itemize>
</descrip>

Prinzipiell sollte man mit zwei Tabellen auskommen:

<itemize>
<item>fr Typ a), c) und d)
    <tscreen><verb>
    .---------------------------------------.
    | Nutzer | Arbeitsplatz | Option | Wert |
    `---------------------------------------'
    </verb></tscreen>
</item>

<item>Fr Typ b)
    <tscreen><verb>
    .---------------------------------.
    | Patientennummer | Option | Wert |
    `---------------------------------'
    </verb></tscreen>
    Bei Patientenunabhngigkeit knnte die Patientennummer -1 lauten.
</item>
</itemize>

Die Einstellung von Optionen sollte leicht sein.
Alle Optionen sollten unter <em>einem</em> Programmpunkt zu finden sein.
Zustzlich ist es bequem, wenn alle Optionen eines Programmbereiches
in diesem Programmbereich zugnglich sind.

Beim Fehlen von Einstellungen whrend des Programmablaufs sollten sofortige
Einstellung per Direktverzweigung mglich sein. Man sollte dabei die Mglichkeit
bekommen, Einstellungen fr sich von anderen Arbeitspltzen oder von anderen
Kollegen bernehmen zu knnen. Eine schnelle Auswahl einer funktionsfhigen
Voreinstellung mu mglich 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 ntzlich, 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 knnen.

<descrip>
<tag>Konfiguration von Ja/Nein-Optionen</tag>
    <itemize>
    <item>wo sinnvoll, sogenannte Quad-Options (siehe Mutt) oder Untermenge davon:
	<itemize>
	<item>auto-yes
        <item>auto-no
        <item>ask-default=yes
        <item>ask-default=no
	</itemize>
    </item>
    </itemize>
</descrip>
<!--
=============================================================================
-->
<sect1>Sonstige Konzepte

<p>
<itemize>
<item>Daten in Textformaten, soweit sinnvoll
<item>alle anderen Formate offengelegt
<item>Programmreaktionszeit fr sprechstundenrelevante Aufgaben mu immer kleiner 500ms sein
<item>Kontakt mit Kodierung nur dort fr den Anwender notwendig, wo unumgnglich (aber natrlich berall mglich)
<item>eigene Ergnzungen und &ldquo;offizielle&rdquo; Daten drfen sich nie berschneiden (ein &ldquo;Update&rdquo; darf niemals nicht praxisspezifisch erstellte Formulare berschreiben)
<item>Auswahlmglichkeiten (z.B. Formularliste o..) drfen nie durch arbitrre Faktoren (Fenstergre, verfgbare Buchstaben als Aufrufkrzel o..) begrenzt werden

<item>saubere Trennung der Abrechnung und Kodierung (ICD) von der eigentlichen, bergeordneten Dokumentation
    <itemize>
    <item>aber vielfltige Schnittstellen
    <item>dadurch <em>rztliche</em> Dokumentation frdern, ohne Abrechnung zu stark zu gefhrden
    <item>Diagnosenliste an sich und Zuordnungsliste Code<->Diagnosentext sind verschiedene Liste !!
    <item>Zuordnungsliste Code<->amtliche Bezeichnung ist eine dritte Liste !!
    </itemize>
</item>

<item>aussagekrftige Fehlermeldungen
    <itemize>
    <item>was geht warum nicht
    <item>was soll der Anwender tun
    <item>explizit Dateinamen und -pfade angeben
    <item>Hinweis auf Fehlerlog
    </itemize>
</item>

<item>aussagekrftige Fehlerlogs
    <itemize>
    <item>Ursachenforschung ermglichen
    </itemize>
</item>

<item>aussagekrftige Nutzerabfragen:
    <itemize>
    <item>warum Nutzerabfrage (&ldquo;Es soll ... getan werden. Das geht nicht automatisch, weil ...&rdquo;
    <item>aktuelle Daten zeigen, die die Abfrage auslsen
    <item>Lsungsmglichkeiten aufzeigen
    </itemize>
</item>

<item>Nutzergemeinschaft frdern
    <itemize>
    <item>versenden erstellter Formulare/Vordrucke/etc. per Knopfdruck an Mailingliste/Webseite
    <item>gemeinsames, automatisiertes Pflegen von Listen (ICD, Rechtschreibung)
    </itemize>
</item>

<item>Querverweise, die aus der Praxis hinausfhren (Internet, Praxisnetz) mssen klar erkennbar sein

<item>die Software soll auch unter widrigen Umstnden funktional bleiben, z.B.:
    <itemize>
    <item>bei Nichterreichbarkeit des Datenbankservers soll einfach ein alternativer Server angegeben werden knnen
    <item>fehlende Konfigurationseinstellungen drfen den Programmablauf nicht verhindern
    <item>Fehlerlogs sollen nur geschrieben werden, wenn Platz vorhanden ist
    <item>wenn die Software von einem read-only Medium (CD) gestartet wird, sollen
          Zustandsdaten (temporre Dateien, Logdateien, Konfigurationsdateien) auch in
          anderen als den Standardverzeichnissen abgelegt werden knnen
    </itemize>
</item>

<item>konservativ
    <itemize>
    <item>die Software soll bei eigenen Entscheidungen auf der sicheren Seite bleiben, z.B. bei Unklarheit
          Daten lieber doppelt speichern und den Nutzer darber informieren, als sich auf mglw. unzuverlssige
	  Programmlogik zu sttzen
    <item>z.B. Lschen von Laborimportdateien erst nach einer festlegbaren Zeitspanne
    </itemize>
</item>

<item>Zustandsfreiheit
    <itemize>
    <item>Prozesse sollten mglichst wenig von transienten Zustnden im RAM abhngig sein - Plattenplatz ist billig !
    <item>checkpoints mit Wiederaufnahme des Ablaufs von dort
    <item>z.B. halb ausgefllte Formulare knnen beliebig oft abgebrochen und weitergefhrt werden
    </itemize>
</item>

<item>sicher
<item>autonom - do one task and do it well
</itemize>

</sect>
<!--
=============================================================================
-->
<sect>Funktionalitt im Detail

<p>
Hier sollen typische, reale Ablufe in einer Arztpraxis und
deren optimale Untersttzung durch eine Praxis-EDV beschrieben.
Was wie optimal ist, hngt natrlich immer vom Betrachter ab.

Details anderer Art (gesetzlich, technisch, administrativ,
konzeptionell), die nicht direkt die Funktionalitt, wohl aber die
Implementation betreffen, sind im Kapitel 
<ref id="sect-tech-details" name="Technische Details">
unter dem jeweils betreffenden Bereich aufgefhrt.
<!--
=============================================================================
-->
<sect1>Aufnehmen eines Patienten (Rezeption/Anmeldung)
<p>
Hier soll beschrieben werden, wie die EDV effektiv den Ablauf
vom Eintreffen eines Patienten in der Arztpraxis bis zum Zeitpunkt
&ldquo;Sie knnen jetzt Platz nehmen.&rdquo; untersttzen soll.

Der Programmteil "Patient aufnehmen" wird aufgerufen.
Es bietet sich an, am Arbeitsplatz an der Anmeldung zwei Varianten
mit Krzeln zu belegen: 1) Aufnehmen mit Chipkarte, 2) Aufnehmen
ohne Chipkarte.

<descrip>
<tag>mit Chipkarte</tag>
Die Liste der gegenwrtig eingelesenen, aber noch nicht
bernommenen Chipkarten erscheint.
Der Anwender whlt eine Chipkarte aus.

<itemize>
<item>der Patient existiert noch nicht in der Datenbank
    <itemize>
    <item>ein neuer Patientendatensatz wird angelegt
    <item>die Stammdaten werden von der Karte bernommen
    <item>die Kartendaten werden abgespeichert
    <item>bei ungltiger Karte werden Krankenkasse und Status manuell erfragt
    <item>bei gltiger Karte werden (ggf. per Tabelle korrigierte) Krankenkasse und Status bernommen
    </itemize>
</item>

<item>der Patient existiert schon in der Datenbank
    <itemize>
    <item>bei Mehrfachtreffern mu der Anwender auswhlen
    <item>genderte Kartendaten werden abgespeichert
    <item>genderte Adressdaten werden feldweise/gesamthaft zur bernahme angeboten, wobei Unterschiede nebeneinander dargestellt werden
    <item>falls Kartendaten nicht gendert aber Stammdaten anders
	<itemize>
	<item>falls Markierung &ldquo;Karte falsch&rdquo; gesetzt
	    <itemize>
	    <item>nur Hinweis an Anwender, kein bernahmezwang
	    </itemize>
	<item>falls Markierung &ldquo;Karte falsch&rdquo; noch nicht gesetzt
	    <itemize>
	    <item>Hinweis an Anwender
	    <item>Abfrage, ob Datenbernahme (komplett/teilweise) anhand KVK
	    <item>Markierung &ldquo;Karte falsch&rdquo; entsprechend setzen
	    </itemize>
	</item>
	</itemize>
    </item>
    <item>bei gltiger Karte wird ggf. ein Kassen-/Statuswechsel durchgefhrt
    </itemize>
</item>

<item>Karte ist ungltig (abgelaufen)
    <itemize>
    <item>Warnung an Anwender
    <item>Einlesedatum fr Karte wird <em>nicht</em> gesetzt
    </itemize>
</item>

<item>Karte ist gltig
    <itemize>
    <item>Einlesedatum fr Karte wird gesetzt
    </itemize>
</item>
</itemize>

<tag>ohne Chipkarte</tag>
<p>
<itemize>
<item>Name, Vorname und Geburtsdatum werden abgefragt.
<p>
Alternativ sollte man auch die Patientennummer
in eines dieser Felder tippen knnen.
Whrend der Eingabe startet die Suche, deren Ergebnisliste sich mit
jedem weiteren Buchstaben verkleinert.

Pat nur noch eine vorhandene Person, wird beim nchsten getippten
Buchstaben ein Signalton und ein Hinweis ausgegeben (ohne da der
Anwender diesen Hinweis besttigen mte).
Dasselbe beim zweiten weitergetippten Buchstaben.
Ab dem dritten Buchstaben (oder Wechsel in ein anderes Feld)
wird angenommen, da tatschlich ein neuer Patient eingegeben
werden soll.
Die Maske erweitert sich zur Eingabemaske fr neue Patienten.

In dieser Maske sollte hchstmgliche Intelligenz den Anwender
untersttzen.
</item>

<item>Nach Vervollstndigung von Name und Geburtsdatum wird die
Postleitzahl abgefragt.
Daraus abgeleitet werden Vorwahl, Ortsliste, Straenliste
und Wegegeldzone/Entfernung in Kilometern.

<item>Die Strae wird als nchstes eingegeben.
Es mssen nur einige Buchstaben getippt werden, dann kann
man aus einer Liste passender Straen whlen.
Diese Liste ist durch die PLZ schon so stark eingeschrnkt,
da ein oder zwei Buchstaben reichen sollten.
In Verbindung mit der PLZ lt sich aus dem Straennamen
der Ortsname fast immer eindeutig ableiten.

<item>Die Hausnummer wird erfragt.

<item>Der Ortsname wird, falls noch nicht eindeutig, jetzt gewhlt.

<item>Die Krankenkasse wird gewhlt, ebenso der Versichertenstatus.
</itemize>
</descrip>

<p>
Nun liegen identische Zustnde unabhngig von der Chipkarte vor.

Es werden jetzt Felder fr weitere Eingaben angeboten, falls
diese nicht schon gefllt sind.

Aus dem Vornamen wird per Liste das Geschlecht ermittelt.
Ist keine eindeutige Zuordnung mglich, so wird abgefragt.

Optional werden Telefonnummer, Beruf, Rezeptbefreiung,
Hausarzt, Stockwerk, Wohnungsnummer und Kommentar erfragt.

Bei Privatpatienten wird nach dem Rechnungsempfnger gefragt.
Die Daten des Patienten sind voreingestellt, knnen aber einfach
durch Tippen berschrieben werden.

Ist es ein ...

<itemize>
<item>Arbeits-/Wegeunfall ?
    <itemize>
    <item>ein BG-Fall wird angelegt
    <item>die BG-Grunddaten werden abgefragt
    </itemize>
</item>
<item>berweisungsfall
    <itemize>
    <item>der berweiser wird eingetragen (Briefempfnger, etc.)
    <item>Art der berweisung (Mit-/Weiterbehandlung, ...)
    <item>bei Kassenpatienten wird ein berweisungsfall angelegt
    </itemize>
</item>
<item>normaler Fall whrend der Sprechzeiten
    <itemize>
    <item>ein Behandlungsfall wird angelegt
    <item>bei fehlender Chipkarte wird ein Ersatzschein gedruckt
    </itemize>
</item>
<item>normaler Fall auerhalb der Sprechzeiten
    <itemize>
    <item>ein Notfall-Fall wird angelegt
    <item>bei Kassenpatienten wird ein Notfallschein gedruckt
    </itemize>
</item>
</itemize>

Die "reason for encounter"/Beratungsursache aus Sicht des
Patienten ("habe Rckenschmerzen", "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.
</sect1>
<!--
=============================================================================
-->
<sect1>Aufruf eines Patienten (Behandlungsraum)

<sect2>mit KVK
<p>
Im Sprechzimmer soll die bersicht zu den Daten des Patienten
(siehe <ref id="tag-pat-overview" name="Patientenbersicht">)
direkt auf den Schirm gebracht und der Aufruf in der Kartei mit
Zeit vermerkt werden.
</sect2>

<sect2>manuell
<p>
Eine Suche per Hand mu auch mglich sein. Dort mu man wahlweise
Patientendaten (Name) oder die Patientennummer eintippen knnen. Der
Suchalgorithmus mu fehlertolerant sein:

<itemize>
<item>Umlaute mssen hin- und her bersetzt werden
    <itemize>
    <item>Mller <-> Mueller
    <item>f <-> ph
    </itemize>
</item>
<item>Komplettierung/Trunkierung
    <itemize>
    <item>Suche &ldquo;Ml&rdquo; findet Mller, Mler, Mlte, Mueltholz, etc.
    </itemize>
</item>
<item>Wildcards
    <itemize>
    <item>Suche &ldquo;M?ll&rdquo; findet Mller, Mller, Mallis, etc
    <item>Suche &ldquo;Rot+e&rdquo; findet Rote und Rothe
    </itemize>
</item>
</itemize>

Falls diese normale Suche keine Ergebnisse bringt, sollte
automatisch eine Suche nach dem Soundex-Algorithmus
durchgefhrt werden.

Die Suchergebnisse werden alphabetisch sortiert und per word wheel
ist der gewnschte Patient aufrufbar. Zum Namen sollen Geburtsdatum,
Straenname und Wohnort (ohne PLZ) angezeigt werden.
</sect2>

<sect2>aus der Warteliste/dem Terminkalender
<p>
Wenn der Patient z.B. an der Anmeldung in die Warteliste oder den
Terminkalender gestellt wurde, kann man ihn von dort auswhlen.
</sect2>

<sect2>von extern per xDT
<p>
Externen Programmen sollte es mglich sein, per definierter
Schnittstelle dem Programm einen Patientenaufruf mitzuteilen.
</sect2>

<sect2>aus einer Patientenliste
<p>
Man soll aus einer Patientenliste, die per Suche nach
bestimmten Kriterien entstanden ist, direkt den Patienten
aufrufen knnen.
Dann sollte das Wechseln des Patienten
nur ber Zurckgehen in die Liste und Wahl eines anderen
bzw. Verlassen der Listenwahl mglich sein.
Solche Listen wren z.B: Fehlerliste KV-Prflauf, Suche von Patienten
mit bestimmten Eigenschaften (wie Diagnosen), etc.
</sect2>



</sect1>
<!--
=============================================================================
-->
<sect1>berblick ber die Daten eines Patienten<label id="tag-pat-overview">

<sect2>Variante 1 - Dr. Colberg
<p>
Ich mchte beim Aufruf eines Patienten zunchst rasch einen berblick ber
***alle*** aktuell anstehenden Probleme bekommen. Dies mssen nicht nur
medizinische Diagnosen nach ICD 10 sein, sondern natrlich auch Probleme im
sozialen Umfeld, organisatorische Aufgaben usw.
Dazu wre es unter Qualittsgesichtspunkten sehr sinnvoll, optional ein
(Behandlungs-)ziel zuordnen zu knnen.

Davon abgesetzt sollten derzeit nicht <em>aktive</em> 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 Verknpfung zu einem
flexiblen Recall-System erstellen lassen, z.B. fr Nachsorgetermine (darunter
verstehe ich, dass das System auch 3 Tage vor dem Recalltermin anspringt,
wenn die Patientin zufllig vorbeikommt).

Die Diagnosen sollten sich wahlweise nach Prioritt oder nach Kausalitt
sortiert anzeigen lassen.

Weiterhin sollte es mglich sein, ber die medizinischen Diagnosen auf
passende Befunddaten zugreifen zu knnen. 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 mchte ich die laufenden &ldquo;Prozeduren&rdquo; wie Medikation (mit
Dosierung), andere Behandlungen, Mitbehandlungen von Kollegen (!),
Selbstbehandlungen im berblick haben, wiederum abgesetzt von frheren /
abgeschlossenen Behandlungen, OPs etc.

Auf Mausklick knnte hier z.B. eine bersicht ber die letzten Verordnungen
des betr. Medikaments herausgesucht und eine Rezepterstellung ausgelst
werden, oder auch eine Berechnung des Medikamentenbestandes des Pat.

Mit einem solchen System wrde man die unbersichtliche &ldquo;elektronische
Karteikarte&rdquo; kaum mahr brauchen und wrde die Mglichkeiten der EDV erst
richtig nutzen. Gerade als Hausarzt arbeitet man oft an vielen Problemen
gleichzeitig, daher wre eine solche problemorientierte Dokumentation m.E.
sehr sinnvoll.

Mit dem Komplex Abrechnung/Liquidation mchte ich mich brigens erst im
Anschluss an den Patientenkontakt befassen. Dies sollte in einer eigenen
Maske geschehen, in der die &ldquo;echten&rdquo; Diagnosen aus o.g. Patientenbersicht
wahlweise als im laufenden Quartal abrechnungsrelevant markiert werden knnen.

Ein Vorschlag zur Raumaufteilung meinerseits:

<itemize>
<item>Stammdaten incl. Foto 8%
<item>Versicherungsdaten 2%
<item>Cave-Eintrge 5%
<item>Problemliste mit Diagnosen usw. 30%
<item>Medikation 30%
<item>ausstehende Dinge 25%
</itemize>
</sect2>

<sect2>Variante 2 - Karsten Hilbert
<p>
Nach Wahl des Patienten (per Suche, aus Warteliste, gesteuert von
Fremdprogramm) wird eine definierbare Auswahl der
Patientendaten angezeigt. In den meisten Fllen wird dies
eine bersicht zum Patienten sein. Diese soll der raschen Orientierung
ber den Patienten vor Anzeigen der Gesamtkartei dienen. Einige wenige
limitierte Funktionen knnen direkt integriert sein (z.B.
Wiederholungsrezept).

Ich mchte dort folgendes sehen (im Sprechzimmer, daher z.B. keine Anzeige, ob KVK vorhanden):

<itemize>

<item>Stammdaten
    <itemize>
    <item>evtl. Photo
    <item>Name
    <item>Geschlecht
    <item>Adresse
    <item>Kontaktmglichkeiten
    </itemize>
</item>

<item>Versicherungsdaten
    <itemize>
    <item>Art der Kasse (privat/gesetzlich)
    <item>Name der Kasse (...)
    <item>existieren offene BG-Flle ?
    </itemize>
</item>

<item>Cave-Eintrge
    <itemize>
    <item>Allergien
    <item>eigene Hinweise/Kurznotizen
    <item>zu beachtende Medikation
    <item>Schwangerschaft
    <item>Eintrgen mu ein Verfallsdatum zugeordnet werden knnen
	<itemize>
	<item>&ldquo;nie&rdquo; (z.B. &ldquo;Atemnot nach Ketoconazol&rdquo;)
        <item>&ldquo;in nn Tagen/Wochen/Monaten&rdquo; (z.B. &ldquo;ist schwanger&rdquo;)
	<item>&ldquo;beim nchsten Besuch&rdquo; (z.B. &ldquo;nach Haustier fragen&rdquo;)
	</itemize>
    </item>
    </itemize>
</item>

<item>medizinische Problemliste/Letzter Kontakt
    <itemize>
    <item>Diagnosen/Episoden
	<itemize>
	<item>jnger als konfigurierbares Hchstalter, auer als chronisch markierte
	<item><tt>STRG-I</tt> zeigt Detailinfos
    	    <itemize>
    	    <item>alle zugehrigen Behandlungstage
    	    <item>abhngig von Diagnose: welche Untersuchungen liegen (nicht) vor
    	    </itemize>
	</item>
	</itemize>
    </item>
    <item>wann zuletzt deswegen
    <item>ggf. hierarchisch geordnet (von mir zugeordnet)
    <item>dieser Bereich sollte (in der Tab-Reihenfolge) beim Aufruf der bersicht gewhlt sein
    </itemize>
</item>

<item>Medikation
    <itemize>
    <item>zuletzt verschriebene oben bzw. markiert
    <item>warum verschrieben (ein/zwei Worte, mssen von mir zugeordnet worden sein)
    <item>wann verschrieben
    <item>ob lt. Packungsgre/Einnahmefrequenz alle oder nicht
    <item>dieser Bereich sollte nach Aufruf der bersicht durch einmal <tt>Tab</tt> erreichbar sein
    <item>Markieren mit <tt>Leertaste</tt> und z.B. <tt>Strg-D</tt> erzeugt ein neues Rezept
    </itemize>
</item>

<item>ausstehende Dinge (Recall, Todo, Termine)
    <itemize>
    <item>Impfungen
    <item>sonstige Dinge, die zu tun sind
    <item>wenn Termin vorhanden: wie lange berschritten/wie lange noch bis hin
    <item>Wiedervorlage von Diagnosen (Frequenz mu von mir zugeordnet werden)
    </itemize>
</item>

</itemize>

<p>
Mit <tt>TAB</tt> kann man zwischen den Bereichen wandern. Mit Cursor-hoch/runter
ggf. in Listen in den Bereichen wandern. Mit <tt>STRG-I</tt> mehr Informationen
zum jeweiligen Eintrag in der Liste im Bereich aufrufen.

Von jedem Eintrag sollte man direkt in den kontextabhngigen ausfhrlichen
Teil der Detaildaten verzweigen knnen. Es sollen hier also keine
ausgebufften nderungsmglichkeiten vorhanden sein, wohl aber direkte
Verzweigungen in den jeweiligen Bereich.

Von hier gelange ich per <tt>ENTER</tt>, <tt>F3</tt>, o.. in die elektronische Kartei.
Per <tt>F2</tt> geht es in die Abrechnung. Per <tt>Strg-F</tt> zur Formularbersicht,
per <tt>Strg-B</tt> zum Befundarchiv, ...

Mittels <tt>ESC</tt> rotiert man durch die Abfolge bersicht des aktuellen Patienten,
die Suchmaske fr Patienten, den heutigen Terminkalender (falls aktiv) und
die Warteliste (falls diese aktiv und nicht leer ist).

</sect1>
<!--
=============================================================================
-->
<sect1>Patientendaten im Hausbesuch

<p>
Dr. Wilfried Behrendt schreibt:

Als Hausarzt habe ich grosses Interesse an einer Mglichkeit,
patientenbezogene Daten aus der Praxis-EDV vor Ort greifbar zu haben.
Dies knnte mittels eines Reportgenerators bewerkstelligt werden, der eine
whlbare Selektion von Patientendaten entweder auf Papier ausdruckt oder per
Schnittstelle (seriell,USB,IR o..) an ein Notebook oder Pocket-PC
bertrgt. Stellt man sich diese Schnittstelle bidirektional vor, so
wren vor Ort vorgenommene und erfasste nderungen (nderungen der
Medikation, etc.) anschliessend wieder in die Praxis-EDV bertragbar.
Was dringend zu beachten ist: die Mobilitt beim Hausbesuch lsst nur
kleine, leicht transportable Hardware zu. Selbst ein Laptop ist mir
da schon zu unpraktisch, wohingegen die Pocket-Pcs dieses Problem
nicht aufwerfen (dafr haben sie keine Tastatur!). Die Firma
promedico hat wohl schon eine Windows-basierte Lsung entwickelt,
aber es gibt ja bereits Linux fr 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 mglich. 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-Rckfluss bleibt also
zunchst noch unbefriedigend, aber die Mglichkeit aktuelle
Informationen zum Hausbesuch mitnehmen zu knnen ist doch ein
ntzliches Feature.

Darber hinaus lassen sich fr o.a. Reportgenerator sicherlich noch
jede Menge weiterer ntzlicher Einsatzmglichkeiten denken.

mfg, Dr. Behrendt

Es lassen sich folgende Kriterien ableiten :

<itemize>
<item>Export von Patientendaten auf Papier oder als Datei
<item>das Dateiformat mu textbasiert sein, um alle Zielgerte zu untersttzen
<item>es sollten 3 Formate untersttzt werden
    <itemize>
    <item>maschinenlesbar strukturiert
	<itemize>
	<item>zum Einsatz auf einem vollwertigen portablen Rechner
	</itemize>
    </item>
    <item>HTML
	<itemize>
	<item>fr portable Gerte mit Browser
	</itemize>
    </item>
    <item>ASCII
	<itemize>
	<item>fr sonstige Gerte
	</itemize>
    </item>
    </itemize>
</item>

<item>es sollten Gruppen von Patienten fr typische Hausbesuchsrunden
    definierbar sein, z.B. alle Bewohner eines bestimmten Heimes

<item>Hausbesuchsexport von Patientendaten soll die Daten in der Praxis
    nicht gegen Bearbeitung sperren, es soll aber eine Warnung
    angezeigt werden

<item>innerhalb der Mglichkeiten der portablen Technik soll ein
    Rckflu von Daten mglich sein

<item>der Datenrckflu mu die Daten zusammenfhren, nicht Versionen
    berschreiben, es soll also ein paralleles ndern der Daten
    mglich sein -- soweit das technisch lsbar ist

<item>die Software eines PDA sollte das Ausdrucken von Formularen
    auf dem patienteneigenen Drucker ermglichen (ja ja, das
    Treiberproblem ...), z.B. per USB, Infrarot, BlueTooth oder
    Wireless LAN

<item>ein PDA sollte mglichst gleich eine Mglichkeit zum Einlesen
    und bertragen der Chipkarte in die Praxis-EDV aufweisen (gibt
    es dafr PCMCIA-Karten ?)
    <itemize>
    <item>ein Problem hierbei knnte die Zertifizierungspflicht sein
    </itemize>
</itemize>

Eine ntzliche Minimallsung ist aber schon die Exportmglichkeit
der derzeit aktuellen Daten der Praxis zur Mitnahme zum Hausbesuch.

</sect1>
<!--
=============================================================================
-->
<sect1>Medizinisches Dokumentieren

<p>
Es klingt sinnvoll, zunchst mit nicht zulassungspflichtigen Programmteilen anzufangen.
Das wre im Wesentlichen die medizinische Dokumentation.

<sect2>Modellvorstellung
<p>
<itemize>
<item>Problemliste/Zielliste
    <itemize>
    <item>kann identisch werden mit Episodenliste
    <item>aktiv vs. inaktiv
    <item>nicht nur medizinisch (Diagnosen), auch Soziales, Syndrome, etc.
    <item>ggf. zugeordnete Daten
    <item>Wiedervorstellungsautomatik je KH-Bild
    </itemize>
</item>

<item>Episodenstruktur
    <itemize>
    <item>analog Niederlande
    <item>http://www.phcsg.org.uk/conferences/cambridge1998/westerhof.htm
    <item>Komplettfassung, aber nur in Niederlndisch
    </itemize>
</item>
</itemize>

<descrip>
<tag>Episode:</tag>Zeitdauer eines Gesundheitsproblems im Zustand &ldquo;aktiv&rdquo;

<tag>Kontakt:</tag>
ein Arztbesuch wegen eines oder mehrerer Probleme

<tag>Teilkontakt:</tag>
Bearbeitung <em>eines</em> Problems whrend eines Arztbesuches.
In der el. Kartei durch mehrere Eintrge dargestellt.

<tag>Zeile:</tag>
Eine physikalische Zeile mit Patientendaten in der elektronichen
Kartei. Eine oder mehrere Zeilen bilden einen Eintrag.

<tag>Eintrag:</tag>
Kleinste, nicht weiter ohne <bf>Sinn</bf>verlust 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.
</descrip>

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 &ldquo;Problemliste&rdquo; 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 hher ansetzen:
Mehrere Episoden gehren zum gleichen grundlegenden                                                                    
gesundheitlichen Problem, z.B. Problem insulinpflichtiger                                                                
Diabetes Mellitus mit mehreren Episoden zur Kontrolle der                                                                
Einstellung, einer etwas schwerwiegenderen Entgleisung durch                                                             
einen &ldquo;unvorsichtigen Urlaub&rdquo; und eine Episode einer                                                                     
infizierten Wunde am Unterschenkel, dazu noch eine Episode                                                               
&ldquo;Vorstellung beim Augenarzt&rdquo;.                                                                                            
                                                                                                                         
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 hinzufgen, da ein                                                           
relationales Datenbanksystem die Trennung von Inhalt und                                                                 
Ansicht frdert, so man sich an gute Designkriterien hlt                                                            
(Normalisierung etc.). Das niederlndische System, das                                                                 
klassische System, das Weed-System - das sind eigentlich nur                                                             
<em>Darstellungsweisen</em> derselben Daten, vorausgesetzt, das
zugrundeliegende Datenmodell ist wohldefiniert.                                                                          
                                                                                                                         
Die herkmmliche Kartei (also tabellarisch chronologisch) ist                                                          
dann einfach: &ldquo;Zeige ALLES von ANFANG bis ENDE&rdquo;.

<tscreen>
<verb>
> Darberhinaus sind die Systeme ausgesprochen abrechnungsorientiert: man kann
> z.T. nur Diagnosen eingeben, die auch &ldquo;abgerechnet&rdquo; werden knnen, die
> Diagnosen lassen sich nicht kausal oder nach Prioritt sortieren, die
> aktuellen &ldquo;Quartals&rdquo;-Diagnosen werden beim Quartalswechsel gelscht, als habe
> die KV-Abrechnung den Patienten geheilt. Welch ein Schwachsinn!!                                                       
</verb>
</tscreen>

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 Eintrge bei der Abrechnung,                                                            
anstelle da fr die Abrechnung bestimmmte Diagnosen in der                                                        
Kartei markiert werden. Letztere Vorgehensweise steht ganz                                                             
oben auf meiner Liste fr GNUMed.                                                                                      

<tscreen>
<verb>
> 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 durchfhrt.                                                  
</verb>
</tscreen>

IMHO sind die Eingabemedien (Tastatur, Maus) aber auch durch                                                             
Papier und Stift immer noch relativ leicht zu schlagen. Es                                                               
wird eben die Hard-/Software &ldquo;Gehirn&rdquo; wesentlich unmittelbarer                                                           
und noch dazu mit den Rohdaten eines Patienten gefttert. Eine                                                         
EDV mu eigentlich immer erraten, was die Software im Gehirn                                                           
als nchstes 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 Strung durch Schreiben auf                                                                      
elektronischer Oberflche (evtl. gleichzeitig auf Papier).                                                             

<tscreen>
<verb>
> Ich mchte beim Aufruf eines Patienten zunchst rasch einen berblick ber                                                                                                              
> ***alle*** aktuell anstehenden Probleme bekommen. Dies mssen nicht nur                                             
> medizinische Diagnosen nach ICD 10 sein, sondern natrlich auch Probleme im                                                                                                                   
> sozialen Umfeld, organisatorische Aufgaben usw.                                                                        
</verb>
</tscreen>

Hier zeigt sich schon ein subtiles Problem, dem viele von uns                                                            
verfallen sind: Was kmmert uns eigentlich der ICD (auer am                                                         
Ende des Quartals auf dem Konto) aus medizinischer Sicht ?                                                               
Natrlich nichts ! Eine solche Kodierung sollte m.E. (fast) vllig                                                   
unsichtbar fr den Anwender ablaufen und den                                                                           
<em>Dokumentations</em>proze nicht beeinflussen. Im Gegenteil kann                                                           
der Gedanke &ldquo;ICD10&rdquo; im Hinterkopf die Dokumentation sogar                                                                
verflschen.
</sect2>
<!--
=============================================================================
-->
<sect2>Stammdaten des Patienten

<p>

<sect3>Verwandschaftsverhltnisse

<p>
Es soll mglich sein, zwischen beliebigen Patienten Beziehungen herzustellen und
diese mit bestimmten Bezeichnungen zu versehen. Dabei sollen biologische und soziale
Beziehungen mglich und abgrenzbar sein. Bei Vorliegen einer Beziehungsrichtung soll
das Programm automatisch die Gegenrichtung erkennen und nutzen. Beziehungsbume sollen
grafisch darstellbar und in definiertem Textformat (XML ?) and Fremdprogramme
bergebbar sein (z.b. Stammbaumanalyseprogramme). Als mglicherweise hilfreich
erwiese sich eine Schnittstelle zu einer Datenbank mit Erbkrankheiten (&ldquo;Mendelian
Inheritance in Man&rdquo; ?) mit Mglichkeit der der Darstellung der 
Erkrankungswahrscheinlichkeiten im Stammbaum.
</sect3>
</sect2>




<sect2>fortlaufende Dokumentation in der Sprechstunde
<sect3>Variante Karsten Hilbert
<p>
Zugegebenermaen ein durchaus altbackener Ansatz, aber dafr mit deftiger
Intelligenz (sofern sie funktioniert). Entstanden aus dem tglichen 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 Eintrge. Das Datum wird pro Tag nur einmal
angezeigt. Ist der Zeitabstand zwischen aufeinanderfolgenden Eintragungen grer
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. Zustzlich wird die Tageszeit
vor der jeweils vorhergehenden Eintragung angezeigt. Optisch wird die Tageszeit
unaufflliger als das Datum dargestellt. Durch Drcken der Tabulatortaste in der
Datumsspalte oder lngerem Schweben mit dem Mauszeiger ber der Datumsspalte
werden zugehrige Detailinformationen angezeigt:

<itemize>
<item>Datum
<item>Tageszeit
<item>zur Zeit des Eingebens gewhlter Benutzer
<item>Typ des Eintrags (Anamnese, Befund, Therapie, Diagnose, etc.)
<item>zugehrige Episode
</itemize>

Das Eingeben eines anderen Datums in der Datumsspalte funktioniert laut der
Beschreibung fr das Datumsfeld, die auf http://www.gnumed.org zu finden ist.

Mittels <tt>ENTER</tt> gelangt man von der Datumsspalte in die nchste Spalte. Von dort
gelangt man mittels <tt>POS1</tt> wieder in die Datumsspalte, sofern man in der nchsten
Spalte bereits ganz links steht.

Die zweite Spalte von links zeigt fr jede Eintragung eine der Markierungen
A, B, T. Jede Eintragung schliet, bezogen auf den Typ, mit dem Zeilenende ab.
 Abrechnungsziffern werden nicht (oder doch: konfigurierbar, dann &ldquo;L&rdquo;)
angezeigt. Diagnosen haben keine eigene Gruppe. Weitere Gruppen knnen frei
definiert (z.B. X=Rntgen), sowie die genannten Markierungen umdefiniert werden.
Mit <tt>TAB</tt> erhlt man wieder Detailinformationen:

<itemize>
<item>alle aus der Datumsspalte
<item>weitere mgliche Gruppen mit Krzel und Beschreibung
<item>per word-wheel kann man eine andere Markierung whlen
</itemize>

Gibt es mehrere Zeilen desselben Typs, so werden diese untereinander angezeigt,
wobei der Typ wie beim Datum nur einmal angezeigt wird. Fgt man der Kartei
eine Zeile hinzu, wird diese als weitere Zeile dem internen Gesamtfeld fr
diesen Typ an diesem Tage hinzugefgt. Es mu freilich eine Mglichkeit geben,
bei Mehrfachbehandlung am selben Tage, Zeilen gleichen Typs als nicht
zusammenhngend zu definieren. Grob kann das ber einen konfigurierbaren
Zeitabstand erfolgen.

Die dritte Spalte enthlt die eigentlichen Eintrge. Hier steht freier oder
strukturierter Text, Querverweise oder Mewerte. Per <tt>ALT-A/B/T</tt> wird der
Typ des Eintrags fr die gesamte Zeile neu gewhlt. Vorgewhlt ist bei Aufruf
der Kartei die Episode des vorhergehenden Aufrufs. Per <tt>ALT-E</tt> wird die
Episode gewhlt. Per word-wheel kann dann aus den bei diesem Patienten
vorhandenen Episoden und der arztbezogenen Diagnosenliste gewhlt werden.
Eintragungen, die lter als 6 Monate (konfigurierbar) sind, werden
eingeklappt und nur das Datum und die Bezeichnung der Episode angezeigt.
Solche Eintrge knnen per Doppelklick oder <tt>ENTER</tt> aufgeklappt
werden. Eintrge der aktuell gewhlten Episode werden jedoch fr die
letzten 2 Jahre (konfigurierbar) aufgeklappt. Per Funktionstaste kann
man folgendes auf-/zuklappen:

<itemize>
<item>alles Episoden
<item>alle auer die aktuell gewhlte
</itemize>

<descrip>
<tag>Markieren ...</tag>
... kann man mit der Maus oder mit <tt>SHIFT+Cursor-Links/Rechts</tt>, wobei
mit <tt>SHIFT+STRG+Cursor-L/R</tt> wortweises Markieren mglich ist. Per Maus
markiert Halten und Ziehen je nach Position. Doppelklicken markiert das
angezielte Wort. Dreifachklicken markiert die gesamte Zeile. <tt>SHIFT-EINFG</tt>
kopiert den markierten Texte in die Zwischenablage. <tt>SHIFT-ENTF</tt> verschiebt
in die Zwischenablage und lscht. <tt>STRG-EINFG</tt> fgt aus der Zwischenablage
ein. <tt>ENTF</tt> lscht markierten Text.

<tag>Bewegen ...</tag>
... kann man sich wie folgt: <tt>Cursor links/rechts</tt> - inneerhalb der Zeile.
Keine Wirkung am Zeilenanfang/-ende. <tt>Cursor rauf/runter</tt> nchste/voherigen
Zeile auer erste/letzte. <tt>Bild rauf/runter</tt> einen Bildschirm rauf/runter.
<tt>STRG+BILD rauf/runter</tt> oder <tt>STRG+POS1/ENDE</tt> - erste/letzte Zeile.
<tt>STRG+Cursor links/rechts</tt> springt wortweise in der Zeile. <tt>POS1</tt> geht zum
Anfang der Zeile und von dort zum Anfang der jeweils vorhergehenden Spalte.
<tt>ENDE</tt> geht zum Ende der Zeile. <tt>Enter</tt> ffnet eine neue Zeile mit gleichem
Datum, neuer Zeit und gleichem Typ der vorhergehenden. Verlassen einer
leeren Zeile (keine Eintragung) lscht diese.

Markieren und Bewegung geht vergleichbar oder exakt so im gesamten Programm.

<tag>Autokomplettierung ...</tag>
... ist (teilweise kontextabhngig) 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 fr 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 verndert die
Komplettierung entsprechend dem jeweils getippten Anteil. <tt>Leertaste</tt> und
Interpunktionszeichen entfernen die Komplettierung und beenden das
getippte Wort. <tt>ENTER</tt> bernimmt den Komplettierungsvorschlag. Weitere
Komplettierungsvorschlge sind per word-wheel whlbar.

<tag>Makros und Platzhalter ...</tag>
... sind natrlich hier, wie berall, aktiv. <tt>STRG-M</tt> oder <tt>STRG-ENTER</tt>
fhren 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 Rntgen, aber nicht in
z.B. Anamnese-Zeilen) greift die ...

<tag>... automatische Diagnosenerkennung</tag>
Bei Beenden eines Wortes (Leerzeichen, Interpunktions-
zeichen, Zeilenende) wird dieses einem Puffer hinzugefgt. Der Puffer wird
darauf geprft, 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 geprft. Gibt es jetzt einen Treffer,
wird der Anteil der Zeile, der dem Pufferinhalt entspricht, intern als
&ldquo;Diagnose&rdquo; 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 <tt>Tabulator</tt>
ist, sofern man auf einer Diagnose steht, Detailinformation abrufbar:

<itemize>
<item>ICD-Code
<item>relevanter ICD-Pfad (Kapitel, etc.)
<item>offizieller ICD-Text
<item>Aufruf von relevanten Fachinformationen
</itemize>

Man kann natrlich auch Teile des Textes markieren und per <tt>ALT-D</tt>
zur Diagnose erklren. Solche Diagnosen werden der Diagnosenliste
hinzugefgt. Dabei wird geprft, ob durch Weglassen von Fllworten
(der, die, das, von, etc.), Ausklammern von Zahlen (_5._ Finger,
Jahresangaben), bersetzen von Anteilen (&ldquo;V.a.&rdquo; <-> &ldquo;Verdacht auf&rdquo;,
&ldquo;Z.n.&rdquo; -> &ldquo;Zustand nach&rdquo;, &ldquo;bds.&rdquo; <-> &ldquo;beidseits&rdquo;) zu einer vorhan-
denen Diagnose mit ICD-Code gelangt werden kann.
</descrip>

<p>
In Zeilen vom Typ &ldquo;Befund&rdquo; greifen verschiedene Mechanismen der
Befundungsuntersttzung. Eine mengesteuerte, baumartige Befundung
ist per Tastenkrzel aufrufbar. Eine topologische grafische
Befundung (siehe dort fr Details) ist ebenfalls so startbar.
Von dieser wird ein textueller Kurzbefund zurckgeliefert. Dieser
und ein Querverweis auf die berlagerungsgrafik der Befundung werden
gespeichert. Externe Befundungssoftware kann gestartet werden (AODT,
MeDOC, o..). Vordefinierte Schlsselworte rufen Aktionen hervor:

<itemize>
<item>&ldquo;APGAR&rdquo; oder &ldquo;GCS&rdquo; ffnen entsprechende Masken
<item>&ldquo;Finger&rdquo;, &ldquo;Fing.&rdquo;, &ldquo;Dig&rdquo; o.. ffnen eine Abfrage &ldquo;rechts/links&rdquo; und &ldquo;1-5&rdquo;, sofern diese Angaben nicht schon vor &ldquo;Finger&rdquo; stehen
<item>&ldquo;Tetanus&rdquo;, &ldquo;Tet.&rdquo;, &ldquo;Td&rdquo; o.. lsen aus: &ldquo;aktuell (&tilde;)&rdquo;, &ldquo;Boosterung erfolgt&rdquo;, &ldquo;zuletzt &tilde;&rdquo; (eigentlich gehrt diese Angabe unter &ldquo;Anamnese&rdquo; - der Mechanismus mte also auch dort greifen, ggf. mit anderen Schlsselworten)
<item>&ldquo;Monitoring&rdquo; erzeugt &ldquo;Zeit: &tilde;:&tilde;, RR: &tilde;/&tilde;, Puls: &tilde;, SpO2: &tilde;%&rdquo;
</itemize>

Die Tilde &ldquo;&tilde;&rdquo; wirkt &ldquo;magnetisch&rdquo; auf den Cursor. Bei Einfgen von
Text mit Tilde wird der Cursor auf der Tilde positioniert, diese
gelscht und getippter Text eingefgt. <tt>Enter</tt> springt zur nchsten
Tilde und von der letzten zum Ende des eingefgten Textes.

Mit <tt>F2</tt> geht es zur Abrechnung. Je nach Stammdaten ist Kasse oder
privat voreingestellt. Weiteres Drcken von <tt>F2</tt> rotiert durch die
Abrechnungsarten:

<itemize>
<item>privat -> BG -> privat
<item>Kasse -> BG -> privat -> Kasse
<item>Reihenfolge konfigurierbar
</itemize>

Mittels <tt>ALT-S</tt> (<tt>ALT-F</tt> ?) wird bei Kassenpatienten der jeweilige
Schein (Fall ?), also Notfallschein, Abrechnungsschein oder
berweisungsschein, etc. gewhlt. Per <tt>ALT-D</tt> kann man Diagnosen
aus der Kartei zuordnen, die dann auf Verschlsselung geprft werden.
Bei Fehlen wird sofortige Verschlsselung per Suche/Zuordnung
ermglicht. 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 gehrenden medizinischen Karteieintrge
eingeblendet werden. Das Gleiche fr den aktuellen Tag bei Anlegen
einer neuen Zeile. Eingegebene Ziffern werden sofort _komplett_ auf
Regelverste geprft.

Mit <tt>STRG-F</tt> geht es zur Gesamtauswahl der Formulare, wobei die
hufigsten (konfigurierbar) per <tt>(SHIFT+)F5/6/7</tt> erreichbar sind
(jeweils Blanko/komplett - je nach Konfiguration).
</sect3>

<sect3>Variante Dr. Hahn
<p>
Fr mich auch der wichtigste Punkt! Aus leidvoller Erfahrung weiss 
ich wie wichtig es ist, bereits hier sorgfltig darber nachzudenken, 
was Dokumentation bedeutet. Darber gehen bekanntermassen die 
Meinungen sehr auseinander. Was soll dokumentiert werden und wie ?

Hier kommt auch die Frage: wie gebe ich ein, Krzel, Autotext etc., 
knnen, mssen Schlssel hinterlegt werden, wie finde ich bestimmte 
Dinge wieder?

Da ich sehr hufig wissenschaftlich arbeite, bin ich darauf angewiesen, 
aus meinen Patientendaten bestimmte Gruppen (Diagnosen, Prozeduren 
etc.) wiederzufinden. Das kann aber auch in der &ldquo;normalen&rdquo; Praxis 
ntig und sinnvoll sein. So kann die Kenntnis der Anzahl von z.B. 
insulinpflichtigen Diabetiker oder chronisch Kranken etc. manchmal 
vielleicht ntzliche Argumentationshilfe gegenber der KV sein.

Ich kenne prinzipiell drei Eingabemglichkeiten:

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 spter wieder Felder dazufgen) 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 knnten Standards wie Diagnose, aktuelle Therapie, Rntgen, Sono
etc. fest verankert, andere frei definierbar sein.

So wrde 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 fhren:

<descrip>
<tag>Anamnese</tag>
Patient klagt seit 3 Tagen ber Schmerzen in der re. Hand.
Bekannte rheumatoide Arthritis, Gicht, Herzinsuffizienz.
<tag>Befund</tag>
DS ber A1-Ringband 3 und 4 re
<tag>Diagnose</tag>
TVS 3und 4 re
<tag>Therapie</tag>
Injektion mit Cortison und LA
<tag>ICD</tag>
M65.3
</descrip>

Sicher gibt es da Mglichkeiten, die Eingabe noch einfacher zu gestalten.
Man msste sich nur an feste fr alle akzeptable Konventionen halten. Sicher
kommen da von den Programmieren noch andere Ideen.

Das Datenbankmodell sollte so offen sein, dass das nachtrgliche Einfgen von
Feldern mglich ist. Denn in zwei Jahren muss oder mchte ich sicher etwas
anderes dokumentieren als ich es heute tue.
</sect3>

<sect3>Variante Dr. Colberg
<p>
Entscheidend ist fr mich die erste Zuordnung (Episoden), die es bisher bei
Praxis-EDV noch nicht gibt. Diese ist unabhngig vom Datentyp und sollte
daher auch getrennt erfolgen. Wer sie nicht braucht, bekommt einfach alle
Eintrge einem Default-Problem zugeordnet.

Aus meiner Praxis-Erfahrung heraus knnte ich mir z.B. folgende
Benutzerschnittstelle vorstellen:

Der Benutzer sieht ein Text-Eingabefeld, z.B. tabellarisch aufgebaut wie die
elektronische Karteikarte. Darber befindet sich ein Aufklappmenue mit dem
ersten Eintrag &ldquo;alle&rdquo;, danach &ldquo;neues Problem&rdquo;, danach die bislang bei dem
Patienten definierten Probleme. Dieses Auswahlmenue sollte in den
Einstellungen auch abschaltbar sein (dann wird alles default zugeordnet).

Man whlt nun das anstehende Problem und bekommt nur noch die entsprechenden
Eintrge angezeigt.

Anschlieend gibt man seinen Text ein, den man per Tastenkrzel noch einem
der Datentypen zuordnet.

Ein anderer Vorschlag wre, in einer schmalen (abschaltbaren!) Spalte hinter 
oder vor den Befundeintrgen die Abrechnungsziffern einzugeben oder 
wenigstens anzuzeigen. Man knnte sich dadurch evtl. eine eigene Maske 
&ldquo;Abrechnung&rdquo; (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 untersttzen wollen, sollte 
man vielleicht zwischen 2 grundstzlichen Darstellungsarten umschalten knnen.

Zum einen chronologisch/althergebracht:

<verb>
- 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 erhhen
- 12.12.2001  +  s  Belastbarkeit etwas besser
              +  o  gluc 160
              +  o  Beindeme rcklufig

                 ^
                 Kategorisierung nach SOAP-Modell (nur als Beipiel, man
                 knnte auch andere Eintrge ermglichen)
^             ^
2 Knotenebenen (+ und - : Baumknoten)
</verb>

Zum anderen episoden-/problemorientiert:

<verb>
-  Diabetes mellitus Typ IIb

   06.12.2001  +  s  gestern selbst BZ 240 gemessen
               +  o  gluc 183
               +  a  Glibenclamid auf 2-0-1 erhhen
   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  Beindeme rcklufig

^              ^
2 Knotenebenen erforderlich, evtl. eine weitere fr das Datum
</verb>

(Ich glaube, mit diesem kleinen Beispiel wird der Vorteil der 
problemorientierten Dokumentation schon deutlich. Man stelle sich mal 5 
gleichzeitig bestehende Probleme vor...)
</sect3>

<sect3>Sonstiges

<p>
<itemize>
<item>Import von Werten aus Fremdprogrammen
<item>weitestmglich automatische Fhrung des EHR
<item>Sofortanzeige: Sofortige Anzeige wichtiger Informationen beim Aufruf
    des Patienten. Risikopatientenberwachung, Impfkontrolle, Nachsorge.
<item>Recallverfahren, durchzufhrende Leistungen.
<item>AODT - Basisdokumentation ambulantes Operieren: elektronische 
    Erfassung der Dokumentationsbgen und Ausgabe auf Diskette zur 
    Einreichung bei der KV
</itemize>

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 knnen.
</sect3>
</sect2>



<sect2>grafisch gesttzte topologische Dokumentation
<p>
<verb>
topologische Dokumentation
          Lizenz
               diese Beschreibung steht unter der Design Science Licence (http://dsl.org/copyleft/dsl.txt)
          interaktive, schematische Zeichnungen der menschlichen Figur
          Begrenzung auf klinische &ldquo;Auenansicht&rdquo;
          verschiedene Krperbautypen
               Sugling
               Kleinkind
               Kind
               Erwachsener
               Senior
               Mann
               Frau
               Dysproportionierung aufgrund bestimmter Krankheiten
               kachektisch
               schlank
               athletisch
               adips
          Werkzeug &ldquo;Vergrerung&rdquo;
               nur in Stufen
               Frontalansicht:
                    Gesicht
                         Auge
                              Werkzeug &ldquo;Pupillengre&rdquo;
                              Werkzeug &ldquo;Achsabweichung&rdquo;
                         Mund
                         Nase
                         Ohr
                         Gebi
                         Rachen
                    Thorax
                         Mamma
                    Abdomen
                    Inguinalregion
                    Perinealregion
                         mnnl./weibl. sekund. Geschlechtsorgane
                         Analregion
                              Werkzeug &ldquo;Uhr&rdquo; fr das Einzeichen von Hmorrhoiden
                    Bein
                         Oberschenkel frontal
                         Knie frontal
                         Unterschenkel frontal
                         Fu dorsal
                         Zehen
                    Arm
                         Schulter
                         Oberarm
                         Ellenbogen
                         Unterarm
                         Handgelenk
                         Hand
                         Daumen
                         Finger
                         Faust
               Rckansicht
                    Nacken
                    Rcken
                         Wirbelsule
                         Schulter
                         Lumbalregion
                    Glutealregion
                    Analregion
               Seitansicht
                    Schulter
                    Hfte
                    Sprunggelenk
               Kopf von oben
          Werkzeug &ldquo;Drehen&rdquo;
               nur stufenweise in &ldquo;Ansichten&rdquo;
               in jeder Vergrerungsstufe
                    falls sinnvoll
                    bezogen auf jeweilige Region
               Sicht von dorsal
               Sicht von frontal
               Sicht von lateral
                    Fechterstellung
               Sicht von cranial auf Schdel
               gynkologische Sicht
               Steinschnittlage (?)
          Werkzeug &ldquo;Ebenen&rdquo;
               in jeder Vergrerung/Ansicht einblendbar
               auch mehrere berlagerbar
               nach Einblendung &ldquo;Aktivierung&rdquo; von Details mglich
               innere Organe
                    z.B. Druckschmerz, Resistenz, Elastizitt, Tastbarkeit, Gre
               Muskeln
                    z.B. Schmerz, Kraftverlust
               Gelenke
                    z.B. Entzndung
                    Werkzeug: Neutral-Null-Methode
               Sehnen
                    z.B. Ri, Entzndung
               Knochen
                    z.B. Fraktur, Tumor, Entzndung
               Dermatome
                    z.B. Sensibilittsausflle
               Hautspaltlinien
               Fortleitungsorte (Organ <-> Schmerz auf Krperoberflche)
               Krperoberflche
                    z.B. Berechnung fr Verbrennungen durch Aktivierung
                    Schemata
                         altersgruppenabhngig
               Lymphknotenstationen
                    z.B. LKS, Lymphome, etc.
          Werkzeug &ldquo;Notiz&rdquo;
               freie Notizen zu gewhltem Detail
               pro Detail vordefinierte Textblcke auswhlbar
          Werkzeug &ldquo;Detail hinzufgen&rdquo;
               Naht
               Narbe
                    reizlos
                    Keloid
               Raumforderung
               Entzndung
                    Schwellung
                    Rtung
                    Schmerz
                    berwrmung
               Hautvernderungen
                    Blase
                    Lichenifikation
                    Atrophie
                    Ulkus
                    Varizen
                    Tumor
               Schmerz
                    Druckschmerz
                    Berhrungsschmerz
                    auch ber &ldquo;Aktivierung&rdquo; von Objekten in Ebenen eingebbar
                    aber auch freie Schmerzlokalisation notwendig
               intestinales Stoma
          per Zoom auf Teildarstellungen
          Werkzeug &ldquo;Befunderstellung&rdquo;
               XML-Format oder ASCII
               generieren von Text aus visuell eingegebenem Befund und Notizen
     genealogische Dokumentation

- Dokumentationen
Dokumentationsbedrftige Ziffern. Abfrage mu automatisch bei Ziffer
angezeigt und mit Inhalt vorgegeben werden
</verb>
</sect2>


<sect2>Dokumentenarchiv
<p>
(Text, Bild, Video, Audio)

(US, R, Scans, EKGs, ...) - in Entwicklung

Zuordnung von Individualbriefen (Befundarchiv)

<verb>
Dokumentendatenbank
          sane (sourceforge) scannen
          gocr (sourceforge) OCR
               asynchrone Erkennung auf server
               Wiedervorlage
               wordbox
               aspell

- Rntgennummer
Angabe der Rntgennummer und des Befundes
Zugriff auf Bildarchivierung (welche?).

- Bild-Archivierungsprogramm
Anbindung eines Praxisarchiv-Servers mit Scanner und
Datenbernahme verschiedener Bildquellen,
eingescannte Befunde der Kollegen, Rntgenbilder,
Video-Aufnahmen, Digitale Kamera etc. und Zuordnung
zum Patienten.
</verb>
</sect2>


<sect2>Diagnostizieren
<p>
<verb>
Diagnosen/ICD
               Quartals- und Dauerdiagnosen beim Patienten
               maskierbare Diagnosenteile ([xxx])
               arbitrre Zuordnungsmglichkeit von Diagnosentexten und ICD-Codes
               keine Anwenderberhrung mit ICD (auer Meldung fehlende Zuordnung Code <-> Diagnose)

- Diagnosen
Volltext-Eingabe mit ICD-Dateizugriff und -bernahme. Eigene Diagnosenstammdatei hinterlegt mit mglichen Abrechnungsziffern und Medikamentenvorschlgen, ICD.

- Dauerdiagnosen
Automatische Zusteuerung zu jeder Abrechnung / quartalsbergreifend ; ICD (Handling wie Diagnosen).

- Diagnosendatei (ICD)
Fachrichtungsbezogene Diagnosendatei mit ICD-Eintrag.
Internat. Classif. of Deseases ICD-Schlsseldatei.
</verb>
</sect2>

<sect2>Therapieren
<p>
- Stationre Angaben:
Behandlungsdauer, Krankenhaus, Inhalt KHS-Einweisungsschein etc...

- Therapie:
Angaben zur verordneten Therapie / Dauertherapie / Therapiewechsel.

- Vorsorgeuntersuchung:
Ergebnisse der Vorsorgeuntersuchung und Hinweise zur Hufigkeit, Recalleintrag.
</sect2>


<sect1>Drucken von Formularen
<p>
In einem zweiten Schritt knnte man dann die Formulardruckfunktion und als Grundlage dafr die Patientenstammdatenverwaltung in Angriff nehmen.
Hier wrde erstmals Genehmigungsbedarf bestehen.

Ein Formulargenerator wre sicher eine tolle Sache in Anbetracht der regional unterschiedlichen und stndig sich ndernden Formulare.
Ideal wre, wenn jeder Benutzer ein damit selbst generiertes Formular per Mailingliste an andere Anwender verschicken knnte!

Aus meiner Sicht ist der Formulardruck auch zweitwichtigste Prioritt.
Ein Formulargenerator wre absolut genial.
Insbesondere mit den Mglichkeiten sich mit anderen Anwendern auszutauschen.
Was macht man denn den halben Tag: Formulare ausfllen.
Ich warte gerade auf die Formulare fr die neue Heilmittelverordnung (seit ca. 3 Monaten).
Wenn ich einen Generator htte wre die Sache schon 7 Tage vor Termin fertig gewesen.

Beim Formulardruck wre eine gewisse eingebaute Intelligenz ntzlich:
So mssten sich hufig 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 msste es einen Generator geben, der eine Generierung von Standardbriefen mit standadisierten Inhalten aus vorhandenen Daten (siehe Dokumentation) zulsst.


Ein Modul, da sich um den Formulardruck kmmert. Dies hat zwei Teile: ein Modul fragt die Daten vom Anwender/von der elektronischen Kartei ab. Dieses Modul kann es in mehreren Ausfhrungen geben: GUI mit Formulardarstellung, Text, Skript (fr Massendruck oder
Wiederholungsdruck), fr Windows, Linux, Mac, ... Das zweite Modul hat eigentlich keinen Schimmer von den Formularen, sondern ldt 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 fr welches Formular - vom Drucken berhaupt nichts...) Die Module an sich sollten Open Source sein, die Formulartemplates wiederum wren eine Einnahmequelle fr eine Firma - und zu Recht. Wie man schon bemerkt, knnen die Module auch auf getrennten Rechnern laufen.

unabhngiger Formulargenerator, der per BDT/GDT mit den Praxisprogrammen in Verbindung steht

<verb>
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 fr 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 huslicher Pflege
               Krankengeldbescheinigung

ZUSATZ:
Formulardruck
          reportlab
          ProForma
          GNUe Forms
          Blankoformulare von KBV

- Formulardruck / Formulargenerator
Gngige Formulare mssen enthalten sein. Fr weitere Formulare, Atteste, mu ein Formulargenerator enthalten sein, ber den diese erfat werden knnen (z.B. bei
KV-Bezirks-individuellen Formularen).
</verb>
</sect1>
<!--
==============================================================================================
-->
<sect1>Nutzen von Labordaten
<sect2>Darstellung
<p>
Markierung von Werten auerhalb Normbereich:

<itemize>
<item>durch &ldquo;+++&rdquo; oder &ldquo;---&rdquo;
<item>durch &ldquo;!&rdquo;
<item>durch farbliche Hervorhebung
<item>durch anderen Zeichensatz, grere Schrift, anderen Stil (fett, kursiv, ...)
<item>Konfigurationsfrage
</itemize>

Individuell vernderbare Reihenfolge der Testergebnisse in Profilen mu mglich sein.
Ausgelieferte, vorgefertigte Profile drfen beim Update praxisspezifische nie berschreiben.
Es mu ein Profil &ldquo;alle Werte&rdquo; geben.
Beim Patienten sollte das zuletzt gewhlte Profil eingestellt bleiben.

Alternative: &ldquo;Intelligente&rdquo; Sortierung der Testreihenfolge:

<itemize>
<item>generell nur Krzel, fr die ein Ergebnis vorliegt, werden zeilenweise angezeigt
<item>Sortierungreihenfolge nach dem jngsten vorhandenen Ergebnis
<item>bei bestimmter Taste in einer bestimmten Spalte: Sortierung so, da Zeilen mit
      Ergebnissen in dieser Spalte (am entsprechenden Tag) direkt untereinander stehen
<item>manch einer mag dies nicht
<item>sollte als Pseudoprofil &ldquo;automatische Sortierung&rdquo; aufrufbar sein
</itemize>

Wenn weitere Spalten (Zeitpunkte) mit Labordaten auerhalb des Bildschirms vorliegen: 
Markierung der betreffenden Zeile mit &ldquo;&gt;&rdquo;, &ldquo;+&rdquo;, &ldquo;&rarr;&rdquo; o.. am rechten Bildschirmrand

Wenn weitere Zeilen mit Laborwerten unterhalb Bildschirmrand vorliegen: 
Markierung der betreffenden Spalten mit &ldquo;Y&rdquo;, &ldquo;v&rdquo;, &ldquo;V&rdquo;, &ldquo;+&rdquo;, &ldquo;&darr;&rdquo; o.. am unteren Maskenrand. 
Bei pathologischen Werten andersfarbig oder anderes Symbol, z.B. &ldquo;!&rdquo;.

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 
&ldquo;alle medizinischen Daten im Zeitraum&rdquo; mit auftauchen.

Siehe auch <url url="http://linuxpraxis.multiservers.com/os-pms/pms-main.html" name="linuxpraxis.multiservers.com/os-pms/pms-main.html"> unter &ldquo;Labor&rdquo;

Unabhngig von der Benennung eines Labortests in einem bestimmten Labor mu in der Praxis 
die Mglichkeit vorhanden sein, mehrere Testkrzel zu einem Test zu gruppieren. 
Dadurch knnen 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 mssen dabei 
allerdings je nach Quelle des Ergebnisses gespeichert werden.
</sect2>


<sect2>Speicherung
<p>
Dieses Kapitel gehrt z.T. in das Dokument Design.

<verb>
          Testkrzeldatenbank
               pro Labor
                    Labor-ID
                    Testkrzel in Labor
                    Testkrzel in Praxis
                    Normalwerttabellen
                         Frauen
                         Mnner
                         Kinder
                         (Senioren)
                         (Altersgruppen)
                         methodenspezifisch ! (also ca. laborspezifisch)
                    Notiz
               praxisintern
                    Testkrzel in der Praxis
                    Name des Tests ausgeschrieben
                    zugeordnete GNR (nur auf LDT anwendbar)
                         EBM
                         GO-96
                         BG-GO
                         (GO-88)
                    quivalente Testkrzel (notwendig ? - da pro Labor schon vorhanden)
                    Notiz
</verb>

Normalwertreferenzen mssen zum Laborergebnis zugeordnet bleiben, da mit Wechsel der
Analysemethode andere Bereiche vorliegen knnen !!

In der Datenbank mu also beim Ergebnis eine Referenz auf den Testverfahrensdatensatz vorhanden sein.
Testverfahren drfen dann nie gelscht, sondern nur als alt markiert werden.

Tabelle &ldquo;Labortest&rdquo;

<itemize>
<item>Krzel, z.B. Hb
<item>volle Bezeichnung, z.B. &ldquo;Hmoglobin&rdquo;
<item>Kommentar
</itemize>

Diese Tabelle stellt die Tests so dar, wie es die jeweilige Praxis wnscht.
Auf diese Weise knnen Tests mit unterschiedlichen Krzeln aber gleicher
Bedeutung (z.B. nachdem man das Labor gewechselt hat oder weil das Labor eine
zustzliche Methode fr den gleichen Wert eingefhrt hat und
den alten Test genauer benennen mute) zusammengefhrt werden.

Diese Tabelle soll in jeder Praxis vorkommen. Natrlich
wrde ich niemandem zumuten wollen, diese Tabelle von Hand anzulegen.
Beim Import von Labordaten wird das Krzel aus der LDT-Datei
genommen. Es wird geprft, ob diesem laborspezifischen Krzel
schon eine praxisspezifische Bezeichnung zugeordnet ist. Wenn
nicht, wird dies an Ort und Stelle vorgenommen. Dabei wird das
Krzel des Labors als Praxiskrzel automatisch vorgeschlagen.
Ebenso die Langbezeichnung, die im LDT mitgeliefert wird. Im
gnstigsten Falle besttigt man nur mit <tt>&lt;ENTER&gt;</tt>.
Natrlich werden zur Entscheidungsfindung alle Praxiskrzel angezeigt,
die in Krzel oder Volltext &ldquo;Hb&rdquo; oder &ldquo;Hmoglobin&rdquo; anzeigen.
Man kann direkt in die Liste der Praxiskrzel zum Suchen
verzweigen. Man kann selbstverstndlich immer einfach das
Laborkrzel bernehmen. Dann hat man die herkmmliche
Situation. Mancher mag das sogar <em>immer</em> so wollen und
folglich eine Option in der Konfiguration wnschen (z.b. wenn
man seit Menschengedenken nur ein Labor nutzt).

Tabelle &ldquo;laborspezifischer Test&rdquo;
<itemize>
<item>Labor, z.B. &ldquo;Labor Dr. Mustermann, Musterstadt&rdquo;
<item>Laborkrzel, z.B. &ldquo;Hb   1&rdquo;
<item>volle Bezeichnung, z.B. &ldquo;Hmoglobin, bestimmt mit Gert XY&rdquo; - wie im LDT vom Labor geliefert
<item>volle Bezeichnung, z.B. &ldquo;Hmoglobin&rdquo; (wie in der Praxis, siehe Tabelle &ldquo;Labortest&rdquo;)
<item>Normalbereich weiblich
<item>Normalbereich mnnlich
<item>Normalbereich Einheit    
<item>Kommentar
</itemize>

Diese Tabelle beschreibt einen Test, wie er fr 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 Hinzufgung
bei Import einer LDT-Datei geflllt werden.

Ein automatischer Prflauf kann des Nachts auf dem Server
Diskrepanzen zwischen Praxis- und Laborkrzeltabellen
ermitteln.

Inwieweit mu man die Normalbereiche weiter differenzieren (Senioren, Kinder,
Altersgruppen) ?

<tscreen><verb>
> Ich wrde es mit den Normalbereichen nicht bertreiben. Es gibt zwar bei 
> bestimmten Werten groe Abweichungen fr 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 bertrgt bei solchen komplexen 
> Werten oft einen lngeren Kommentartext.
</verb></tscreen>

Das ist exzellent zu wissen. Es mu also eher ausreichend
Platz fr den Laborkommentar in der Tabelle &ldquo;Laborergebnis&rdquo;
vorliegen.

Tabelle &ldquo;GNR fr Labortest&rdquo;
<itemize>
<item>volle Bezeichnung, z.B. &ldquo;Hmoglobin&rdquo; (wie in der Praxis, siehe Tabelle &ldquo;Labortest&rdquo;)
<item>EBM, GNR aus dem EBM
<item>GNR GO 88
<item>GNR GO 96
<item>GNR GO BG
</itemize>

Diese Tabelle wird beim Abrechnen von Laborwerten whrend des
Imports benutzt.

<tscreen><verb>
> Die GNR werden doch in der LDT-Datei mitbertragen?!
</verb></tscreen>

In der Tat, sie haben recht. In der Vorgngerversion 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.

<tscreen><verb>
> Sinnvoll wre eine solche Tabelle allerdings bei der Korrektur von Fehlern, 
> wenn das Labor z.B. mal wieder GO-Ziffern bei einem Kassenpatienten 
> abgerechnet/bertragen hat.
</verb></tscreen>

Das erleben wir auch hin und wieder. Ich werde also die
bertragenen GNR in der Tabelle &ldquo;GNR fr Labortest&rdquo; sammeln
und *bei Abweichung* den Anwender benachrichtigen. Das sollte
dann die fehlerhaft bertragenen abfangen.

Tabelle &ldquo;Laborergebnis&rdquo;
<itemize>
<item>Patienten-ID (zu welchem Patienten gehrt das Ergebnis)
<item>Krzel, z.B. &ldquo;Hb&rdquo; - wie in der eigenen Praxis verwendet, siehe Tabelle &ldquo;Labortest&rdquo;
<item>Abnahmedatum
<item>Ergebniswert
<item>Einheit des Ergebnisses
<item>Grenzwertindikator (Markierung des Labor von pathologischen Werten)
<item>Laborkommentar, z.B. &ldquo;Hinweis auf stattgehabte Borrelieninfektion&rdquo;
<item>eigener Kommentar (&ldquo;ach Quatsch ... :-)&rdquo;)
<item>Labor-ID (aus welchem Labor stammt das Ergebnis)
<item>Probennummer (welche Nummer hatte die Probe im Labor)
</itemize>

Diese Tabelle enthlt die eigentlichen Ergebnisse. Die letzten
beiden Felder erlauben die Rckverfolgung in Problemfllen.
Mancher mchte das Abnahmedatum, ein anderer das Datum des
Imports.


Tabellen fr 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 lt sich leider schlecht automatisch erkennen. Oder haben
Sie dazu mglicherweise eine Idee ?

Man knnte einige Plausibilittsprfungen vornehmen.

> Hierbei wre es ntzlich, falsch zugeordnete Labordaten noch nach dem Import 
> vom falschen auf den richtigen Patienten bertragen zu knnen (falls
> KV-konform).
OK, werde es vormerken. Hier erweisen sich dann evtl. die
Felder &ldquo;Labor-ID&rdquo; und &ldquo;Probennummer im Labor&rdquo; als ntzlich
(zum Ermitteln des richtigen Patienten auch nach lngerer
Zeit).

> Apropos Zuordnung: Die Vergabe der Labor-IDs knnte etwas eleganter vor sich 
> gehen. Wie wre es mit einem optionalen Barcodeleser?
Den kann man doch auch bei TM anschlieen ? Im Prinzip
funktioniert das analog einer Tastatur: Der Leser liest und
schiebt es in den Computer. Der denkt dann, jemand htte was
getippt und schreibt es an die Stelle, wo gerade der Cursor
steht. Das geht dann mit jeder Software, wenn das
Betriebssystem einen Treiber fr den Barcodeleser hat. Eine
elegantere Lsung wre allerding, wenn die Software anhand des
eingelesenen Barcodes selbst entscheiden knnte, was damit zu
tun ist. Z.B.: Nummern vom Format &ldquo;4341zzzzBBzzzzzz&rdquo; 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 Mglichkeiten, die bei Bedarf implementiert
werden sollten.
</sect2>

<sect2>Import
<p>

<itemize>
<item>mehrere Labore pro Praxis mssen untersttzt werden
<item>Import und bertragung mssen unabhngige Programme sein

<item>bertragung per Diskette
<item>bertragung per Datenleitung
    <itemize>
    <item>kein einheitliches Protokoll bei den verschiedenen Laboren
    <item>bereits Perlprogramm vorhanden
    <item>sollte per Hand auslsbar sein
    <item>sollte auf Wunsch nachts automatisch erfolgen knnen
    <item>externes Programm (nicht GNUmed-intern), Skriptsprache zur leichten Anpassung empfehlenswert
    <item>per Modem, ISDN oder TCP/IP
    <item>anschlieend Bereitstellung zum Import
    </itemize>
</item>
<item>Praxissoftware sollte bei Einloggen bestimmter Benutzer auf zum Import bereitliegende Labordateien hinweisen
<item>Import soll mehrere Quellpfade + Dateinamenmasken fr Labordateien erlauben
    <itemize>
    <item>wenn nur eine Datei auf Pfad + Maske pat: Import automatisch starten
    <item>wenn mehrere passen: Auswahl erlauben mit Sonderpunkt &ldquo;alle nacheinander&rdquo;
    </itemize>
</item>
</itemize>

Ablauf bei LDT-Verwendung:
<verb>
- ggf. Entschlsselung (KBV-Kryptomodul)
- Plausibilittsprfung
  - ist einsendendes Labor in Praxis schon bekannt ?
    - Neuanlage des Labors anbieten
  - absendendes Labor anzeigen
  - Adressaten (empfangenden Arzt) anzeigen
  - fast nur Sichtprfung durch Anwender sinnvoll
- Lesen eines Datensatzes
  - betreffenden Patienten bzw. ID-Nummer anzeigen
  - Prfung, ob Datensatz identifizierbar
    - Zuordnung Nummer <-> Patient oder Datensatz enthlt 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 &ldquo;LDT-Warteliste&rdquo;
        - wird beim nchsten Import erwhnt
      - nach Zuordnung auch Patientennamen anzeigen
  - Lesen eines Testergebnisses
    - Konfiguration Zeitpunkt fr Ergebnis: Abnahme Probe, Eingang Labor, Zeitpunkt Ergebnis, Zeitpunkt Import
    - ggw. bearbeiteten Test mit Datum anzeigen
    - Krzel noch nicht in laborspezifischer Liste:
      - Identitt von &ldquo;Krzel&rdquo;, &ldquo;Bezeichnung&rdquo; und &ldquo;Normbereich&rdquo;
      - Hinweis an Nutzer
      - Suche/Darstellung evtl. passender Krzel in vorhandenen Krzeln
      - Abfrage, ob &ldquo;neues Krzel&rdquo; oder &ldquo;gendertes Krzel&rdquo;
        - neu: neu anlegen
	- gendert: neu anlegen, aber in Gruppe des alten Krzels in praxisspezifischer Liste aufnehmen
	- Import relevanter Felder (Normalwerte, Bezeichnung, etc.)
    - Krzel noch nicht in einer Gruppe der praxisspezifischen Liste:
      - Hinweis an Nutzer
      - Suche/Darstellung evtl. passender Krzel in vorhandenen Krzelgruppen
      - Zuordnung zu oder Neuanlage einer Krzelgruppe durch Nutzer
        - Import relevanter Felder (Bezeichnung, etc.)
	- Verzweigung in Datenbank bei fehlenden Feldern
    - Prfung, ob zu importierende Testdaten schon beim Patienten vorhanden
      - Identitt 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
    - Prfung, ob ggw. bearbeitetem Test GNr zugeordnet ist
      - je nach Versicherungsart des Patienten GO/EBM
      - GNr fehlt:
        - Nutzerabfrage und ggf. Verzweigung in EBM/GO-Datenbank
    - Prfung, ob zu importierende GNr. mit laborspezifisch fr diesen Test gespeicherter GNr. bereinstimmt
      - ggf. Korrektur anbieten
        - Korrektur der gespeicherten GNr.
	- Korrektur der zu importierenden GNr.
    - Prfung, ob zu importierende GNr. schon abgerechnet wurde
      - Identitt von Datum und GNr
      - Nutzerabfrage bei schon vorhandenen GNr mit Anzeige vorhandener + Datum
    - importieren
  - Lschen aller Zuordnungen Probe/Patient mit Status &ldquo;Endbefund&rdquo;
    - Nutzerabfrage
    - Konfigurationseinstellung
- Lschen der Importdatei
  -  Archivierung bereits nach bertragung
- Sammelliste &ldquo;pathologische Werte&rdquo; bearbeiten
  - wenn pathologische Werte vorhanden
    - Abfrage, ob angezeigt/gedruckt werden soll
  - keine pathologischen Werte
    - Hinweis an Nutzer
</verb>

<verb>
Formate
                    LDT
                         verschlsselt
                         unverschlsselt
                         Zertifizierung erforderlich
                         Pflichtformat
			 Textformat der KBV
			 www.kbv.de -> xDT
			 seit 1997 vorgeschrieben
                    (Bonner Modell)
                         obsolet
                         ggf. fr alte Gertesoftware
                         offiziell nicht mehr zulssig
                    andere
                         sollten vor Import in LDT konvertiert werden
                    ELV
                         bermittelung von Testkrzeln, etc. durch das Labor
</verb>

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:

 &ldquo;Die Laborwerte fr HBA1c, HS, GLU, HB vom 11.11.2004 aus dem Labor TESTLABOR
 sollen fr den Patienten Musterfrau, Ilona, geb. 11.11.1999 importiert werden.
 Folgende Patienten aus meiner Datenbank passen auf die Patientendaten des Labors.
 Bitte whlen Sie den richtigen Patienten aus !&rdquo;
</sect2>


<sect2>Export
<p>
<itemize>
<item>Export nach auen und programmintern
<item>programmintern ber Platzhalter
<item>Direktansprung des Laborblattes mit Auswahl von Daten fr Arztbrief, etc. aus anderen Programmteilen
<item>extern als ASCII-Tabelle fr Textverarbeitungen
<item>extern als LDT bzw. XML
<item>andere Formate knnen per Konvertierung aus LDT/XML erzeugt werden
</itemize>
</sect2>


<sect2>sonstiges

<p>
<verb>
Labor
          mgliche Ablufe
               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
                    zugehrige Probennummer
               Erfassungsmglichkeiten
                    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 Laborgerte
                    &ldquo;automatisch&rdquo; von &ldquo;intelligenten&rdquo; Laborgerten vor Ort
                         z.B. Clinitek 100,
                         manche Gerte liefern den Namen (und ggf. die ID) mit
                    KVK-Lesegert
               logische Trennung
                    wichtig wegen Zuordnungskollision
                    je Arzt
                    je Labor, an das Proben versandt werden
                         Fremdlabore
                         Eigenlabor (Gerte)
</verb>
</sect2>
</sect1>
<!--
==============================================================================================
-->
<sect1>Planen von Aufgaben/Zeit - Terminkalender Patienten
<p>
<verb>
Ein Terminkalender fr Patiententermine soll eine offene Schnittstelle haben, 
umd den Abgleich mit persnlichen Terminplanern (zum Beispiel auf PDAs) zu
ermglich.

Es sollte eine Integration zwischen Warteliste (was eigentlich ist das Anderes
als die Seite &ldquo;Heute&rdquo; des Terminkalenders ... ?) und Terminkalender vorhanden sein.

Es mssen Ressourcenbeschrnkungen bercksichtigbar sein:
 - Rume
 - Gerte
 - rzte

Es wre sicher interessant, wenn sich Patienten einige Termintypen per WWW
oder per Sprachcomputer am Telefon selbst geben lassen knnten. Dabei mu
es mglich sein, da ein Termin bei berschreiten von Ressourcenanforderungen
(Zeit, Kosten) erst von einem Praxismitarbeiter endgltig besttigt werden mu,
woraufhin dann eine Zusagebenachrichtigung z.B. per SMS oder E-Mail an den
Patienten gesendet werden knnte.


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 knnen, weil die entsprechende 
  Ressourcengruppe bereits anderweitig belegt ist (Sehr rgerlich 
  im Patientenkontakt: Oh tut mir leid der Termin ist doch nicht mglich....).
* umstndlicher und nicht skalierbarer Ausdruck der Terminzettel; 
  Bemerkung wird nicht gedruckt.
* Termine sind in der bersicht unter Umstnden 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 mglich
* Ein mehrfach verschiedene Terminlnge ist nicht realisierbar
* Eine generelle Sperrung bestimmter Termine (z.B. 10:15 
  Teepause o..) bzw. von Pufferterminen ist nicht mglich
* Es ist nicht mglich bestimmte Termine erst zu einem
  bestimmtem Zeitpunkt vor der Vergabe freizugeben (Akuttermin
  frhestens 24h vor Vergabe freigegeben)
* Es knnen Termine vergeben werden, die eigentlich nicht
  existieren ( Versuchen Sie mal an einem tag mit vollen TK
  einen Termin zu vergeben (-> Terminvergabe zum gewnschten
  Zeitpunkt nicht mglich; mchten den den nchsten freien
  Termin um 23:00 Uhr vergeben...?)


Herr Dr.Elisat stellte folgende Kriterien auf:

Da ich mich mit dem Problem seit lngerer Zeit beschftige mchte
ich fr die Kolleginnen und Kollegen, die sich mit dem Gedanken
tragen, eventuell einschlgige Software einzusetzen, einen Katalog
an sinnvollen Funktionen und Mglichkeiten, die ein solches
Programm haben sollte, in dieses Forum stellen. Vielleicht hilft 
es, die Auswahl zu erleichtern.

Natrlich ist und bleibt die Rezeptionskraft mit     
zwanzigjhriger Praxiszugehrigkeit, die jeden       
Patienten und seine Eigenheiten kennt, das           
Nonplusultra. Aber wenn die einmal lnger krank wird,
doch noch heiratet und wegzieht, in Rente geht       
oder... Lieber nicht daran denken. Dann ist          
vielleicht ein adquates Programm doch eine groe    
Hilfe. Ich meine jedenfalls, da die Terminvergabe in
rztlichen und zahnrztlichen Praxen eine Ttigkeit  
ist, die durch eine sachgerechte EDV-Lsung          
wesentlich verbessert und erleichtert werden kann.   
                                                     
Qualitativ: Die vom Behandler fr den Termin         
gemachten Vorgaben werden exakt eingehalten, die vom 
Patienten gewnschten (geforderten) Optionen werden  
bestmglichst bercksichtigt, umfassende             
Informationen ber den Patienten, der einen Termin   
nachfragt, stehen bei jeder Terminvergabe zur        
Verfgung. Aus diesem Grund ist ein solches Werkzeug 
interessant fr jede Praxis.                         
                                                     
Quantitativ: Eine Kraft kann problemlos wesentlich   
mehr Termine (fr mehr Behandler) korrekt verwalten, 
wenn ein gutes Terminvergabeprogramm benutzt wird.   
Aus diesem Grund ist ein solches Werkzeug sinnvoll   
fr groe Praxen bzw. Praxisgemeinschaften.          
                                                     
Ohne Zweifel hat die gelungene Terminvergabe einen   
extrem wichtigen, in der Regel aber stark            
unterschtzten Einflu auf den Praxisablauf. Hier    
sollen nur der Imagegewinn der Praxis, der sich aus  
kurzer Wartezeiten fr die Patienten ergibt, und die 
wesentlich geringere Belastung des Praxisteams       
infolge des gleichmigeren Arbeitsflusses erwhnt   
werden.                                              
                                                     
Um diesen Effekt zu erreichen, sind an das           
Terminvergabeprogramm einige Forderungen zu stellen, 
ohne deren Realisierung Terminmanagement Stckwerk   
bleibt.                                              
                                                     
- Einfache Bedienung und automatische schnelle und   
zutreffende Terminvergabe den Wnschen des Patienten 
entsprechend, um diese Ttigkeit zu erleichtern und  
auch weniger qualifiziertem Personal zugnglich zu   
machen.                                              
                                                     
- Gute bersichtlichkeit und schnelle                
Suchalgorithmen, um Terminberschneidungen,          
Anschlutermine (bei mehreren Behandlern, einmal     
kommen, zwei Termine wahrnehmen) und Kettentermine   
vergeben zu knnen.                                  
                                                     
- Notizbuch- und Wiedervorlagefunktion fr die       
Patienten, damit der aktuelle Informationsstand fr  
alle Mitarbeiter nutzbar wird.                       
                                                     
- Durchgehende Benutzerkontrolle fr alle Aktionen,  
um Fehlbedienungen zuzuordnen und abstellen zu       
knnen.                                              
                                                     
- Uneingeschrnkte Mehrplatzfhigkeit fr dezentrale 
Terminvergabe in den Sprechzimmern und in groen     
Netzwerken.                                          
                                                     
- Direkter Zugriff auf die Stammdaten des            
Abrechnungsprogramms, um Doppeleingaben und          
zustzlichen Aufwand zu vermeiden.                   
                                                     
                                                     
Im Einzelnen sollten folgende Merkmale vorhanden     
sein:                                                
                                                     
Frei definierbare Vorgaben fr 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 fr jeden Tag               
unterschiedlich mit mindestens zwei Pausen fr jeden 
Wochentag definierbar sein.                          
                                                     
c) Behandlungsarten mssen fr jeden Behandler mit   
zugehriger Vorgabedauer (Defaultzeit) individuell   
einstellbar sein. Whrend der Terminvergabe mu diese
Vorgabezeit problemlos variiert werden knnen.       
                                                     
d) Auerdem mu es mglich sein, bestimmten          
Behandlungen bestimmte Sprechzimmer zuzuweisen, weil 
mglicherweise nur dort notwendige Gerte etc. fr   
diese Behandlung zur Verfgung stehen. Diese Vorgaben
mssen bei der automatischen Terminvorgabe abgeprft 
werden. (exklusive Zimmer- bzw. Ressourcenzuordnung) 
                                                     
e) Um &ldquo;Zwischendurchtermine&rdquo; wie z.B.                
Schmerzpatienten etc. verwalten zu knnen, sollten   
Sammelblcke an beliebigen Stellen der               
Behandlungszeit realisiert werden knnen. Hier kann  
man manuell Kurztermine eintragen. Bei der           
automatischen Terminvergabe werden diese Zeiten nicht
bercksichtigt.                                      
                                                     
f) Fehlzeiten (Urlaub, Fortbildung...) unter         
automatischer Bercksichtigung der gesetzlichen      
Feiertage mssen fr jeden Behandler beliebig        
einstellbar sein.                                    
                                                     
g) Fr gelegentlich auerhalb der normalen           
Arbeitszeit anfallende Behandlungen sollten          
Sonderzeiten anlegbar sein.                          
                                                     
Schichtarbeitszeitregelungen sollten ber das        
wchentliche Wechseln der Arbeitszeiten hinaus       
mglich sein (mindestens drei unterschiedliche       
Wochenarbeitszeiten in beliebiger Reihenfolge und mit
beliebigem Wiederholungsintervall).                  
                                                     
Umfassende Bearbeitungsfunktionen:                   
                                                     
a) Grundstzlich mssen alle Mglichkeiten bei der   
Terminvergabe vorhanden sein, die auch bei Benutzung 
von Terminkladde, Bleistift und Radiergummi genutzt  
werden knnen. Daher ist die Vergabe von Primr- und 
Sekundrterminen zur Realisierung von                
Terminberschneidungen und Doppelbelegungen          
unerllich.                                         
                                                     
b) Den grten Nutzen bringt die automatische        
Terminsuche nach allen denkbaren Vorgaben wie vom    
Patienten gewnschte Auswahl der ihm genehmen Tage   
und Uhrzeiten sowie Termine nach/vor einem bestimmten
Datum. Fr den Fall, da automatisch kein freier     
Termin gefunden werden kann, mu jederzeit auf die   
manuelle Vergabe gewechselt werden knnen.           
                                                     
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             
mglicherweise auf Grund von Spezialisierung         
gemeinsam einen Patienten versorgen, so mu eine     
automatische Anschluterminvergabe bei einem zweiten 
Behandler unter Bercksichtigung einer maximalen     
Wartezeit zum Vortermin mglich sein.                
                                                     
e) Bestimmte Behandlungen laufen in mehreren         
Sitzungen nach einem gleichbleibendem Schema ab.     
Diese Behandlungen mssen zum Gegenstand einer       
Kettenterminvergabe von maximal sechs                
Einzelbehandlungen unter Bercksichtigung minimaler  
und maximaler Abstnde zu den Vorbehandlungen gemacht
werden knnen.                                       
                                                     
f) Besonders wichtig: Nach erfolgter                 
Kettenterminvergabe das perfektes Handling           
(Neuvergabe, Verlegen, Lschen einzelner oder        
mehrerer Termine) der verbleibenden Terminkette, wenn
es im Zuge der Behandlung zu Terminverschiebungen    
oder Terminversumnissen 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 knnen, damit, falls andere       
Patienten Termine absagen, diese angeboten werden    
knnen.                                              
                                                     
h) Das Lschen und Verlegen von Terminen sowie die   
Verlngerung/Verkrzung der Einbestellzeit mu       
einfach und schnell zu bewerkstelligen sein.         
                                                     
i) Auf einer Bildschirmseite des Monitors sollte die 
gesamte grafische Tagesanzeige fr einen Arbeitstag  
angezeigt werden knnen. Dabei mu der Zeitraum von  
mindestens acht Stunden bei einem minimalem Intervall
(= kleinste Zeiteinheit = krzester Termin) von fnf 
Minuten dargestellt werden knnen.                   
                                                     
j) Unverzichtbar ist das automatische Erstellen von  
&ldquo;Kollisionsdatenbanken&rdquo; fr Termine, die nach Eingabe
von Fehlzeiten oder durch nderung der Arbeitszeiten 
verlegt werden mssen. Die Bearbeitung solcher       
Ereignisse mu schnell und einfach vorgenommen werden
knnen. Dazu gehren die telefonische                
Benachrichtigung des Patienten mit direkter Verlegung
bzw. Lschen des Termins und die schriftliche        
Benachrichtigung der nicht telefonisch erreichbaren  
Patienten ber eine Serienbrieffunktion.             
                                                     
k) Natrlich mu bei Rcknahme der eingetragenen     
Fehlzeit die Rekonstruktion der Termine aus der      
Kollisionsdatenbank, soweit sie nicht schon gelscht 
oder verlegt wurden , mglich sein.                  
                                                     
l) Fr die Patienten mssen sowohl Bemerkungen als   
auch Wiedervorlagen angelegt werden knnen. Nach     
diesen zustzlichen Informationen zum Patienten mu  
nach zeitlichen und inhaltlichen Vorgaben gesucht    
werden knnen.                                       
                                                     
m) Weiterhin soll die Anzeige von Bemerkungen und/   
oder Wiedervorlagen vor einer Terminvergabe          
automatisch erfolgen knnen. Wichtig sind die        
Wiedervorlagensuche bei Programmstart und beliebig   
erweiterbare Textbausteine fr sich wiederholende    
Eingaben.                                            
                                                     
n) Ntig sind ferner umfangreiche Druckfunktionen fr
Etiketten, Terminzettel, Terminbuch, Reportlisten,   
Kalenderfunktion mit Anzeige von Feiertagen,         
Fehlzeiten und Terminvorgabezeitrumen, sowie ein    
kontextbezogenes Hilfesystem.                        
                                                     
                                                     
Sicherheits- und Kontrollfunktionen:                 
                                                     
a) Passwortschutz und Zugriffsregelung durch         
abgestufte Benutzerrechte. Ob der Benutzer die fr   
eine bestimmte Aktion erforderlichen Rechte besitzt, 
sollte durch die Abfrage eines nur dem speziellen    
Benutzer bekannten Krzels erkannt werden knnen     
(alternativ sollten Fingerabdruckscanner bzw. Karten 
nutzbar sein). Es ist jederzeit nachvollziehbar,     
welcher Mitarbeiter einen Termin vergeben, zuletzt   
bearbeitet oder andere Daten verndert hat.          
                                                     
b) Umfangreiche Plausibilittsprfung aller          
relevanten Aktionen zur Vermeidung von Fehleingaben. 
                                                     
c) Auerordentlich wichtig: &ldquo;Crash-Programm&rdquo; 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 erfater Daten.            
                                                     
Die hier aufgefhrten Eigenschaften beschreiben den  
notwendigen Funktionsumfang. Ohne Zweifel sind noch  
viele Mglichkeiten da, weitere Aufgaben zu          
integrieren und bestehende zu erweitern.


Herr Dr. Bauer merkte an:

Ich suche fr meine kardiologische Bestellpraxis einen Terminplaner
mit fr jedes Sprechzimmer taktbarer Zeiteinteilung, automatischer
Ablaufplanung fr Neu- oder Kontrollpatienten und besonders wichtig
mit Recallsystem. D.h., der Terminplaner schreibt mir automatisch
die Terminerinnerungsschreiben fr einen bestimmten Zeitraum fr 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 wre dieses
Problem gut zu beherrschen.

Falls dann noch der Terminplaner eine Statsitik-Mglichkeit hat
und mir sagt, ob ich in meinem Budget mit meiner Planung bin, wre
das natrlich das i-Tpfelchen.


ZUSATZ:
Bestellsystem/Terminkalender
          MDSchedule (OIO)
          RFC fr Scheduling/Calendaring

- Tagesliste / Tagesprotokoll / Tagesstatistik
zum kompletten berblick zum Tagesgeschehen in den verschiedenen Praxisbereichen,
berblick ber die Vollstndigkeit der eingetragenen Leistungen mit Direktsprung
zu gelisteten Patienten
</verb>
</sect1>
<!--
==============================================================================================
-->
<sect1>Nutzung von Medikamentendaten

<p>
Im Wesentlichen sollen Medikamentendaten zwei Zielen dienen:

<itemize>
<item>Verschreiben von Therapien
<item>Informationen ber Medikamente fr den Anwender
</itemize>

<sect2>Verschreiben von Therapien

<p>
Rezeptiert werden die verschiedensten Dinge:

<itemize>
<item>Medikamente als Fertigarzneimittel
<item>Zubereitungen (Tees, Salben, etc.)
<item>Heil- und Hilfsmittel
<item>physio-, ergotherapeutische und logopdische Behandlungen
<item>kurze Bescheinigungen
</itemize>

Zum Verschreiben von Medikamenten braucht man mindestens
folgende Angaben:

<itemize>
<item>genaue Bezeichnung des Medikaments (Markenname)
<item>Wirkstoff bzw. pharmakologisch aktive Komponenten
<item>verfgbare Strken je Dosierungsart
<item>verfgbare Zubereitungsarten
<item>verfgbare Packungsgren (N1 - N3)
<item>aktueller Preis (zum Preisvergleich)
</itemize>

Fr diese Daten sind regelmige Erneuerungen notwendig, am
besten ber das Internet, etwa 14-tgig.

Weitere bedeutsame Angaben:

<itemize>
<item>Rezeptpflichtigkeit
<item>Btm-Rezeptpflichtigkeit
<item>Zuzahlungsbetrag fr den Patienten
<item>Zusatzstoffe
</itemize>

Verschiedene Mechanismen erleichtern das Rezeptschreiben
ungemein:

<itemize>
<item>Anzeige von CAVE-Eintrgen
<item>automatische Prfung auf WeWi/KoInd/SchwSch/Allerg
<item>hinterlegte Dosierungsanweisungen
<item>Anzeige des aktuellen Medikamentenbudgets
<item>bei Wiederverordnung Berechnung, wie lange letzte
<item>Verordnung noch gereicht htte
<item>bernahme vorheriger Verordnungen mit minimalem Aufwand
    mit Warnung bei Arzneimitteln, die nicht mehr im Handel sind
<item>einheitliches Formular fr BG/Kasse/Privat mit deutl.
    Darstellung des Kostentrgers
<item>Makros fr Kurztexte
<item>bequeme Handhabung der Zuzahlungsbefreiung
<item>strukturiertes (also wiederverwertbares) Speichern von
    Dosierungsanweisungen
<item>Vorschlag von quivalenzprparaten im Preisvergleich
<item>Prfung gegen Negativ-/Positivlisten
</itemize>

Hier mssen Entwicklungen wie elektronischer Medikamentenpass
und Generika-/aut-idem-Regelung im Auge behalten werden.

Die grundlegendsten Medikamentendaten fr 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.
</sect2>

<sect2>Arzneimittelinformationen

<p>
Fr den Anwender ist es sehr hilfreich, wenn fr die verfgbaren
Arzneimittel weiterfhrende Informationen zum Abruf bereitstehen.
Diese dienen dann einer detaillierten Therapieentscheidung und
auch zur Information ber von anderen rzten verordnete Medikamente.

Nicht alle Informationen mssen vor Ort gespeichert sein. Bestimmte
Dinge knnen einfach mit dem Internet verlinkt werden, beispielsweise
komplette Monographien.

Fr Medikamente wren das

<itemize>
<item>Kontraindikationen
<item>Zusammensetzung mit allen Stoffen (Allergieprfung)
<item>detaillierte Dosierungsempfehlungen (Kinder, Erwachsene,
    Senioren, Nieren/-Lebererkrankte)
<item>Wechselwirkungen
<item>Hersteller mit Kontaktinformationen
<item>Antidote
<item>Wirkmechanismus/-spektrum (Antibiotika)
<item>Schwangerschaft/Stillzeit
<item>optische Indikation (die groe gelbe Kapsel, Herr Doktor)
</itemize>

Aber auch andere Informationen sollten im Programm nahe der
Rezeptfunktion zu finden sein, so etwa eine Liste der Zuordnung
Leistungsnummer <-> Verfahren bei der Physiotherapie fr BG-Flle
oder der Leistungskatalog fr besondere Heilbehandlung bei BG
oder auch der Heil- und Hilfsmittelkatalog bei Kassenbehandlung.
</sect2>


<sect2>Ablauf einer Verordnung

<p>
Ich wnsche mir _eine_ Taste zum Aufruf einer Verordnung. Z.B.
bedeutet <tt>F5</tt> immer &ldquo;Rezept starten&rdquo;. Danach erscheint ein
kleines Men:

<tscreen>
<verb>
 .----------.
 | 1 Normal |  (= Kasse/Privat je nach Patient)
 | 2 BG     |
 | 3 Privat |  (nur bei Kassenapatienten)
 `----------'
</verb>
</tscreen>

Die Typen sind mit der Zahl oder dem Buchstaben aufrufbar oder
mit dem Balken ber die Pfeiltasten auswhlbar. Also:

<verb>
F5+1     -> normales Rezept fr diesen Patienten (entweder Kasse oder Privat)
F5+n     ->    -- &rdquo; --
F5+Enter ->    -- &rdquo; --
</verb>

In dieser ersten Menzeile wird in Klammern angezeigt, was fr
diesen Patienten &ldquo;normal&rdquo; bedeutet &ldquo;= Kasse&rdquo; oder &ldquo;= Privat&rdquo;.

Mancher wird bevorzugen, da die Zeile &ldquo;BG&rdquo; nur dann angezeigt
wird, wenn auch ein offener BG-Fall existiert. Andere werden
bevorzugen, diese Mglichkeit immer zu haben, soda bei Auswahl
derselben der offene BG-Fall aktiv wird, ein geschlossener wieder
geffnet oder ein neuer angelegt wird (mu im Einzelfall jeweils
abgefragt werden). Bei Neuanlage sollte die Wahl der BG natrlich
gleich fr den H-Arzt-Bericht nutzbar gespeichert werden.

Die letzte Zeile macht natrlich nur bei Kassenpatienten Sinn
(Pillenrezept, etc).

Man kann als Alternative zum Weglassen von nicht-zutreffenden
Zeilen diese auch graumeliert und nicht whlbar anzeigen. Insbesondere
bei Auswahlmglichkeit ber Ziffern ist das sinnvoll, um die
Zuordnung von Rezepttyp zu Auswahlziffer zu erhalten.

Ein Blanko wird folgendermaen gedruckt:
<tt>F5 + 1/n Enter> + STRG-D</tt> (bzw. eben die Taste zum Auslsen
des Drucks) -> Abfrage, ob mit oder ohne Datum/Stempel.

Die Unterscheidung in &ldquo;Medikamente&rdquo;, &ldquo;Physiotherapie&rdquo;, &ldquo;Ergotherapie&rdquo;,
&ldquo;Logopdie&rdquo; und &ldquo;Bescheinigung&rdquo; wnsche ich mir erst bei der
eigentlichen Auswahl des Rezeptinhalts. Die Eintrge in der
patientenspezifischen Liste der bisherigen und der arztspezifischen
bevorzugten Verordnungspunkte sind markiert als &ldquo;Medikament&rdquo; oder
&ldquo;Physiotherapie&rdquo; etc. Bei Wahl eines Eintrags werden die anderen
Eintragstypen fr die Auswahl fr dieses Rezept gesperrt, soda auf
ein Rezept nur gleiche Typen gelangen knnen. Das Formular stellt
sich angepat auf den Typ des Eintrags etwas unterschiedlich dar.
Physiotherapie als BG-Leistung sollte ber sprechende Eintrge mit
Hinterlegung der Leistungsnummer whlbar sein.

Bei Verordnung von mehr als drei Medikamenten entstehen automatisch
mehrere Rezeptdruckauftrge.

Man kann auf <tt>SHIFT-F5</tt>, <tt>ALT-F5</tt> und <tt>STRG-F5</tt> ja noch hufige
Rezeptuntertypen legen.

Es mte sich konfigurieren lassen, ob standardmig der Stempel
eingedruckt werden soll oder nicht.
</sect2>



<sect2>Mgliche Datenquellen

<p>
MATERIAL:

Eine Medikamentendatenbank. Diese mu immer sehr aktuell sein, daher ist die Datenlieferung wieder eine
kommerzielle Angelegenheit - zu Recht. Zwischenupdates natrlich wie bei IFAP bers Internet. Dieses Modul knnte 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 [Aktualitt !! Ich sage nur: Betablocker und Herzinsuffizienz !], ATC, PZN, ...) und der kostenpflichtig auf dem neuesten Stand gehalten wird oder ein binr geliefertes Programm, da die Finanzierung ber Werbung der Pharmaindustrie ermglicht (wie zur Zeit beim IFAP).

fr die Medikamentendatenbank gibt es mehrere Mglichkeiten:

AMIS: vom Bundesamt fr Arzneimittel ber DIMDI und KBV verfgbar.
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
Oberflche, soweit ich wei.

IfAp:
Dann gibt es den IfAp-Index. Er ist weitverbreitet und ist gut
aufbereitet. Er hat eine Oberflche fr DOS und eine fr Windows.
Er luft im DOSemu (mit leichten Unbequemlichkeiten fr 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 gendert und das Einspielen der Updates enthlt 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 auszuwhlen als die
der Konkurrenten. Hinweis: Beim IfAp ist das m.W. noch NICHT
so, was sehr fr den IfAp spricht (moralisch zumindest).

Medikamentendatenbank
<itemize>
<item>AMIS
<item>IFAP
<item>Gelbe Liste IMP
<item>Rote Liste
<item>Scholz- Datenbank
<item>ABDA mit quartalsweisem Update (Preisaktualisierung)
<item>Budgetstatistik
<item>Medikamente
<item>Medikamentendatei mit bernahmefunktion fr Rezept und Statistik
<item>Eingabemglichkeit freier Text (mit Preis fr Statistik)
<item>Statistische Ausklammerung der rztemuster
</itemize>

</sect2>
</sect1>
</sect>
<!--
=================================================================================
-->
<sect>technische Details<label id="sect-tech-details">

<sect1>Verarbeitung von Chipkarten (KVK)
<p>
<itemize>
<item>auch Privatpatienten knnen eine Chipkarte haben
<item>Chipkartendaten sollten getrennt von den &ldquo;wahren&rdquo; Stammdaten gespeichert
      und nicht als autoritativ angesehen werden
<item>Fehler, die erfahrungsgem auf KVK vorkommen:
    <itemize>
    <item>falcher Name (Name/Vorname vertauscht, falsch buchstabiert)
    <item>falsches Geburtsdatum
    <item>falsche Adresse (z.B. veraltet)
    <item>falsche Krankenkassendetails
	<itemize>
	<item>es gibt eine amtliche Korrekturtabelle, die bercksichtigt werden mu
	</itemize>
    </itemize>
</item>
<item>das Einlesedatum der Chipkarte mu fr den Anwender unvernderlich
      gespeichert werden, sonst ist keine EDV-Abrechnung zulssig :-))
<item>ungltige Karten mssen abgewiesen werden; bei Patienten mit solchen
      Karten darf theoretisch nicht einmal mehr ein kassenrztliches Formular
      gedruckt werden, allerdings kann (und mu) aus anderen (medizinischen nmlich)
      dann ein Ersatzverfahren zur Anwendung kommen
<item>fr die KVDT-Abrechnung sollte die Adresse auf der Chipkarte verwendet
      werden, nicht die mglw. abweichende richtige in der Stammdatenbank
</itemize>

Gnstig wre 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 ausgelst werden sollen.

Das htte den Vorteil, da der Server selbst keine
Zwischenspeicherung vornehmen mu.

<verb>
KVK
               Cherry-Tastatur
               andere Lesegerte
               Suchen von Patienten mit KVK
               automatisch Markierung &ldquo;vorgelegt&rdquo; bei Suche
               Kreuzprfung KVK-Daten <-> Stammdaten in Datenbank -> Update bei Differenz
               KVK-Gltigkeitsprfung
               neuen Patienten anlegen mittels Einlesen der KVK (im Dienst)

Kartenterminals
          CT-API
          KVK - zunchst am wichtigsten
               Tastaturen
                    Cherry
                         braucht Kernelpatch zum Ansteuern
                         untersttzt read-on-insert wahrscheinlich nicht
                    Preh Commander
                    beide &ldquo;zertifiziert&rdquo;
               serielle Gerte
                    einheitliche API (CT)
                    wenige Modelle
                    einige Modelle &ldquo;zertifiziert&rdquo; -> Gesetzeslage ?
                    viele andere Billigmodelle z.B. bei Conrad
               mobile Gerte
                    seriell anschliebar
                    per Adapter-KVK an normales Gert anschliebar
                         verhlt sich wie normale KVK beim Lesen
                         Batchmodus zum Einlesen untersttzen !
               kvk-server
                    speichert gelesene Daten als XML,
                    sysctl, CLI, pipe,
                    --demon
                         startet sich als demon,
                         liest Daten, sobald Karte gesteckt,
                    --read-kvk
                         CLI-Interface fr direktes Lesen einer Karte,
                    --quit
                         stoppe demon
                    --reload
                         lade Konfiguration neu
                    API
                         identify
                              liefere Identifikation (XML)
                                   Version
                                   Gert + Version
                                   Schnittstelle
                         get-kvk
                              liefert ersten vorhandenen Datensatz
                              setzt &ldquo;geliefert&rdquo;-flag
                         delete-kvk
                              lscht ersten vorhandenen Datensatz
                              &ldquo;geliefert&rdquo;==true -> lschen
                              &ldquo;geliefert&rdquo;!=true -> &ldquo;force&rdquo;==true -> lschen
                         delete-all
                              lscht alle vorhandenen Datenstze
                              &ldquo;geliefert&rdquo;==true -> lsche
                              &ldquo;geliefert&rdquo;!=true
                                   &ldquo;force&rdquo;==true -> lsche
                                   &ldquo;force&rdquo;!=true -> return error
                         read-kvk-now
                              versuche jetzt, eine KVK aus dem Gert einzulesen
          Kreditkarten
          HCPP
          HBCI
          PAM
          Medizinische Speicherkarten

- CHIP-Karten-Anschlu
Software und Hardware sind auf die von der KV gelieferten Lesegerte bzw. Drucker eingestellt - Verarbeitung der verschiedenen Karten (KVK und PKA).
</verb>
</sect1>

</sect>
<!--
=================================================================================
-->
<sect>sonstiges
<p>
<verb>
3.7 Verarbeiten von Text
________________________

Eine Textverarbeitung. Gibt's zuhauf fr Linux. Braucht ggf. ein paar
Erweiterungen, um komfortabel Platzhalter aus der Praxis-EDV zu
untersttzen und zum skriptgesteuerten Erstellen von Arztbriefen,
Befundberichten, ...

Textverarbeitung
               Platzhalter fr 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 Adredatei (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 gefllter 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 fr spteren 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 spteren 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 bentigten Zeit (Zeitdauer bei Gesprchsleistungen)

- Fallwertstatistik
Anzeige des eigenen Durchschnittes im Vergleich zur Fachgruppe in Bezug auf Einzelziffer / Zifferngruppen.

- Praxisbudgetstatistik
Auswertung der Auslastung des Praxis-Budgets (grn),
Auswertung der Auslastung der Zusatzbudgets (gelb),
Bercksichtigung der Flle die nicht budgetiert werden,
Bercksichtigung der fallzahlabhngigen Faktoren bei der Errechnung der Budgetgrenzen (Fallzahlwippe),
Anzeige freier Kapazitten / berschreitung.

- Laborstatistik
Anzeige Laborverbrauch und im Verhltnis zum Budget (z.B. O I).

- Medikamentenstatistik
Anzeige Medikamentenverbrauch / pro Patient / nach Altersstufen / Indikation ...

- Patientenprofilstatistik
Auswertung Patientenbestand nach Geschlecht, M/F/R, Altersstruktur ect... / Begrndung.

- Diagnosenstatistik
Hufigkeit der Diagnosen im Quartal und Vergleichsmglichkeit zu anderen Quartalen / Begrndung.

- Veranlassungsstatistik
Auswertung nach Kassenart - AUs, berweisungen, Krankenhauseinweisungen.

- freie Statistik
Selektion, Auswertung und Auflistung der Anzahl bestimmter Begriffe aus der Patientenkartei.

- Dokumentations-Statistik
Hufigkeit best.Begriffe, z.B.berweisungen d. Kollegen, Krebspatienten, Sonderflle ..

- Betriebswirtschafts-Statistik
Auswertung erbrachte Leistungen in Bezug auf Ertrag, Selbstkosten, Umsatzsanteil..,
Hochrechnung auf das Quartal,
Simulation bestimmter Einflsse auf das Praxisergebnis,

- Statistik, vorhandene Fallzahlen
Anzahl Krankenscheine/ VK und deren Verteilung auf Kassengruppen und Scheinarten

- Tagesstatistik
Auswertung der Leistungen des gewnschten Arbeitstages / Errechnung Arbeitszeit abgerechn. Leistungen.

- Zeitaufwandsstatistik
Quartals- / Tages-Auswertung der fr die Erbringung der rztlichen Leistungen bentigten Zeit (z.B. bei Gesprchsleistungen),
Dokumentation bei Leistungen mit Zeitvorgaben (z.B.10).

- Praxis-Bereichsstatistik
Auswertung der verschiedenen Praxisbereiche oder Differenzierung nach Arzt bei Gemeinschaftspraxen (Mandantenfhigkeit).


3.9 Kommunizieren
_________________

Eine E-Mail-Schnittstelle. E-Mail-Programme sind das tglich Brot von Linux. Es fehlen ggf. noch ein paar Sicherheitsfunktionen (VCS, HCPP) und Schnittstellen (VCS, KDT) zum Praxisprogramm.
sicherer E-Mail-Server fr die Praxen mit Verschlsselung (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 fr Mitteilungen von jedem Arbeitsplatz zu Arbeitsplatz,
eMail zu anderen Partnern ber Online-Dienste,
Befundbermittlungen 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,Prfung). Die notwendigen Datenformate sind frei verfgbar, ein Prfmodul (sogar im Quellcode) und das Kryptomodul (Binrversion, luft 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, fr die notwendige Pflege und Updates auch Gebhren zu bezahlen. Die Schnittstellenimplementationen sollten Open Source sein (meinetwegen BSD-Lizenz, soda jemand gegenber der KBV verantwortlich zeichnen kann fr die Konformitt), die aktuellen Daten aber braucht es nur gegen Gebhr zu geben. M.E. wre es wnschenswert, 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 ausschlielich um die Abrechnung kmmern und nicht um andere Dinge. Nach Quartalsende und Abrechnung wrden die Abrechnungsdaten zur Archivierung an das
Hauptmodul bergeben. Von dort knnten Sie zur Vorquartalsauswertung, zur Korrekturabrechnung, etc. ggf. wieder zurckgereicht werden. Ich wrde mir dieses Modul so minimalistisch wie sinnvoll mglich wnschen.

Abrechnung:
Der Vorschlag einer kassenrztlichen Verrechnungsstelle
ist derzeit nicht vom Abrechnungschaos realisierbar.
Es gibt aber gengend Anbieter, die zertifiziert sind.
Es sollte sich sicherlich einer finden lassen, der ein
Modul zur Regelwerkprfung bereitstellt (keine Oberflche,
nur ber Pipes/Sockets o. ansteuerbar). Nach anfnglicher
Portierung wrde das im Rahmen seiner eigentlichen
Softwarepflege einfach abfallen. Kann ruhig auch was
kosten.

Rechnungslegung fr Privatpatienten (existiert, mu aber an Privatabrechnung angepat werden)

Kassenabrechnung
               Tagesliste
               Online-Regelwerk bei Eingabe
               Prflauf zu beliebiger Zeit
               Fehlersuchfunktionen
               Suchmasken fr vergessene/eingetragene GO-Nr.
               Prfmodul, Kryptomodul
               automatische Warnung bei fehlender 1
               Automatik fr Wegegeldzonen
               KV-Spezifika zumindest vom Anwender einpflegbar
               Statistik
                    Arztgruppe
                    Ermchtigung
                    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 vernderbar
               Berechnungszeitraum frei whlbar
               Einzelerstellung pro Patient
               Druck von Mahnungen

Abrechnung
          APW
          David/X
          Apris/Open

- Abrechnungsarten
Ambulant, Stationr, Notfall/Vertretung, Privat, BG
Privatrechnungen nach EBM sollten ebenfalls mgl. sein.

- Abrechnungsziffern
Vorgabe und Direktkontrolle des Eintrages unter Bercksichtigung der Gebhrenordnung des Kostentrgers nach BM/EGO/GO.
Die Mglichkeit 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 mssen einstellbar sein.

- Zifferndatei GO
diverse Faktoren, Begrndungen, besondere Kosten 10 GO, Sachkosten/Regelwerk,
Angaben in DM und EURO mglich.

- Kostentrgerstammdatei
Kostentrgerstammdatei der KBV integriert,
zustzlich die Verschiedenen &ldquo;Privaten Kostentrger&rdquo;,
Datei aller Kostentrger mit 5-stelliger Kassennummer und Institutionskennzeichen.

- ICPM
Verzeichnis der durchzufhrenden Leistungen im Krankenhaus.

- Heil- und Hilfsmittel
Heil- und Hilfsmitteldatei mit Preisangaben,
bernahmefunktion fr Verordnung und Statistik.

- Fehlerkontroll-Liste
auf Drucker und Anzeige am Bildschirm mit Direktkorrekturmglichkeit in Patientendaten.

- Kassenabrechnung
KVrichtlinienkonforme Erstellung des Datentrgers,
Abrechnungszeitpunkt unabhngig vom Behandlungsdatum,
KBV- Zulassungsnummer.

- ADT-Prfmodul KBV
Der Einsatz des KBV-Prfmoduls zur berprfung des ADT-Disketteninhaltes ist Vorschrift (KBV),
Aufruf und Durchfhrung aus dem Abrechnungsprogramm heraus,
Prfmodul wird mit Quartalsupdate geliefert,
Ausdruck der Prfprotokolle,

- ADT-Kryptomodul KBV
Verschlsselung der Abrechnungsdaten in einigen KV-Gebieten Vorschrift.

- Privatabrechnung
Abrechnung der Privatpatienten zeitraumbezogen - Zeitraum bel. Whlbar,
Regelprfung, Einzel-, Gesamtabrechnung, Zahlungseingnge, Mahnverfahren, unterschiedliche Faktoren, Begrndungstexte, besondere- und Sachkosten, Verwendung der Daten der
PKV-Karte,
Rechnungen wahlweise EURO, DM oder EURO und DM.

- Abrechnung ber Privatrztliche Verrechnungsstelle
PAD-Schnittstelle (Diskettenabrechnung PVS oder Online-bertragung der Abrechnungsdaten via ISDN).

- BG-Abrechnung
Berufsgenossenschaftliche Abrechnung - Rechnungserstellung an die BG incl &ldquo;Besondere Kosten nach 10 GO&rdquo;,
Unfallberichtschreibung - Nachschaubericht der eigenen Fachrichtung.


3.11 Nutzen von Gerten
_______________________

Gertetreiber (KVK-Leser, Kleinstlaborgerte) - teilweise in Entwicklung

- Anschlumglichkeit fr Digitalisierbrett und Mausbedienung,Virtuelle Maus
Mit gewnschten Begriffen selbst programmierbar / als alternative Eingabemedien fr Anwender, die nicht gerne mit der Tastatur arbeiten.

- Spracheingabe
Spracherkennung zur Texterfassung und Systemsteuerung.
Vorhandener medizinischer Wortschatz.
</verb>

</sect>








<sect>sonstiges 2
<p>
<verb>
3.12 Sichern von Daten
______________________

juristisch beweisbar unvernderbare 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 geschtzt werden mssen.

- 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 Arbeitspltzen),
automatische Dunkelsteuerung bzw. Abschalten des Zugriffs beim Verlassen des Arbeitsplatzes oder nach einer vorgegebenen Zeit,
individuelle Zugangskontrolle mittels Passwort / Mitarbeiterkennung.


3.14 Unsortiert
_______________

- Kostentrgeranzeige
Krankenkassen, BGs und private Versicherungstrger incl. der 
unterschiedlichen Abrechnungsbestimmungen /-Faktoren der einzelnen Kostentrger.
Suchfunktionen nach Name, Nummer, Suchort

- Hausarztanzeige
Vermerk des Hausarztes in den Stammdaten,
Erfassungsmglichkeit einer Adressdatei der umliegenden
rzte und Krankenhuser,
zur automatischen Briefschreibung (Tastendruck) gekoppelt mit
Patient und Textverarbeitung

- Direktkontrolle bei der Eingabe
Ziffernein- und -ausschlsse, Begrndungen, Uhrzeiten

- Standardbausteine fr hufig wiederkehrende Begriffe
Rezept, Abrechnungsschein, AU, berweisung, Krankentransport,
Bescheinigungen, Kollegenbriefe mit der Mglichkeit auf
Standard-Bausteine zurckzugreifen,
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 Mglichkeit eines
monatlichen Vergleiches der eigenen Daten mit den Daten anderer
Praxen der gleichen Fachrichtung durchzufhren, um rechtzeitig
besondere Entwicklungen der eigenen Praxis erkennen zu knnen.

- Patientenanmeldung im Sprechzimmer
Patient kann von der Rezeption an best. Arbeitspltzen angemeldet werden.
Weitermeldung an andere Arbeitspltze von jedem Arbeitsplatz aus.

- Makrofunktion/Behandlungsdaten
Erfassung eines kompletten Behandlungsschemas, unter einem Befund-Krzel
knnen Sie sich zustzlich zu Ihren Standard-Befundtexten weitere
Datenkategorien vorschlagen lassen.
- z.B. Ziffern, Diagnosetexte, Medikamente, Therapie usw....

- Automatische Patientenvorlage
Tagesliste, Fehlerprotokoll, Selektionsliste, Laborbertragung
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),
Ergnzungs-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 Verknpfungen gleichzeitig.
Abspeicherbare Standardselektions-Vorgaben,
Negativselektion nach nicht vorhandenen Eintrgen,
Kombination mit Listenausdruck und Serienbrief.

- Mahnung Krankenscheine / Vorlage Versichertenkarte
Ausdruck/Anzeige als Telefonliste, Adressetiketten
und Verwendung der Daten fr Endlosbriefe.
Prfliste der Flle mit Ersatzverfahren,

- Mahnung Privatrechnungen
Offene Posten-Liste - Bercksichtigung Mahnstufen bzw.
geleistete An- oder Teilzahlungen.

- Gemeinschaftspraxis
Einstellung des Systems zur Bearbeitung bei Gemeinschaftspraxen.
ACHTUNG:
Sonderregelung bei fachbergreifenden Gemeinschftspraxen
(Besondere Kennzeichnungspflicht der abgerechneten Ziffern -
KV-Vorschrift beachten),
Bercksichtigung besonderer Faktoren fr die Praxisbudget-Statistik
(Faktorerhhung).
Getrennte statistische Auswertungen (Mandantenfhigkeit) und
gemeinsame Abrechnung.
Entstehen Zusatzkosten in Bezug auf Softwarepflege und Softwaremodule??.

- Praxisgemeinschaft/
Einstellung des Systems zur Bearbeitung bei Praxisgemeinschaften
(Mix Gemeinschaftspraxis und Praxisgemeinschaft auch mglich ?).
ACHTUNG:
Besondere Bestimmungen in Bezug aus den Datenschutz mssen beachtet werden.
Entstehen Zusatzkosten in Bezug auf Softwarepflege und Softwaremodule??.

- BDT - BehandlungsDatenTrger
Ist der BDT im Lieferumfang des Programmes enthalten?
Ausgabe der Patientendaten im BDT-Format zur bernahme in andere
Systeme (Abklrung: eigene Krzel, Texte, Befundbausteine etc.).
Anbindung weiterer Programme/ bzw. medizinischer Gerte ber die BDT-Schnittstelle.

- GDT - GerteDatenTrger
Gertedatentrger-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 fr 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
programmbergreifend, individuell durch Anwender einstellbar zur
Abkrzung von sich wiederholenden Eingaben oder Programmsprngen,
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 fr 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
(Gegenberstellung 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 Arbeitspltzen und Druckern
gleichzeitig verschiedene Programme laufen knnen.

- Multitasking
Parallelbearbeitung div. Programme auf mehreren Ebenen
innerhalb eines Arbeitsplatzes unabhngig voneinander.
Dieses ist besonders fr die Praxen wichtig, bei denen telefonisch
durchgestellte Patientendaten zwischendurch eingesehen werden
mssen, ohne da der gerade aufgerufene Patient verlassen,
oder das Statistikprogramm abgebrochen werden mu.
hnlich wie im Fernsehen knnen unabhngig von einander
verschiedene Programme laufen, die Sie per Knopfdruck umschalten knnen.

- Multiprocessing
Abarbeiten lnger dauernder Durchlaufprogramme im Hintergrund
whrend am selben Arbeitsplatz im Vordergrund weitergearbeitet
werden kann . z.B. Durchfhrung der Abrechnung im neuen Quartal.

- Parallelprocessing Fremdprogramme
Nutzung externer Programme wie DATEV, Bank/Geldverkehr,fremde
Textprogramme, Impfprogramme, Diagnoseuntersttzung, Bildschirmatlas
etc. im gemeinsamen Parallelbetrieb mit dem laufenden
Praxisverwaltungsprogramm aus der Patientenkarte heraus.

- DOS-Kompatibilitt
In Verbindung mit Multiuser-, Multitasking- und
Multiprocessingfunktion an allen Arbeitspltzen, lt Ihnen den
Freiraum fr andere Programme und deren Nutzung. Eine
Beschrnkung auf die nur vom Softwarehaus gelieferten
Arztprogramme gibt es nicht - die grte Programmbibliothek
der Welt gibt es unter DOS - diese knnen Sie nutzen.

- Archivsystem
Archivierung nicht mehr bentigter Patientendaten mit
direktem Zugriff aus der Patientenkartei heraus.

- Offene Praxis EDV Vorschlag zur Dokumentation von Jrgen 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-
mglichst genau formuliert und immer wiederaktualisiert.
Was ntzt es einem wenn in der offiziellen ICD 10 im Diagnosentext
Bsartige Erkrankung weibl Brustdrse&rdquo; o steht Das sagt uns wenig. Da
wir nur sehr wenig Platz fr die Diagnosen haben mssen wir extremAbkrzen damit
alle wichtigen Dauerdiagnosen dokumentiert werden. Leider knnen 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 fr Dos genauso wie fr multitasking Programme.
Die Diagnosen sollte per ziehen und Ablegen kopierbar sein in jedes andere
Programm.

Wir mssen leider in extremen Krzeln schreiben bei uns sieht das dann so aus:

CaMastektomie bds 98u99 RadChem postOP

oder

CaMastektomie r 78 Lympharmdem

Nur diese Krzel knnen wir leider den anderen Kollegen nicht immer anbieten,
dann mssen wir es wieder verlngern. Diese Info ist aber die wichtigste und sie wird
stndig aktualisiert.
Unsere Diagnosedatei ist bereits auf 8300 Diagnosen angestiegen.
Weiter wre es wichtig bereits ausgeschlossen Verdachts-
diagnosen ersehen zu knnen Dies ist besonders bei Somatoformen Strungen 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 heit das dann KHK ZnA m
Coro wenn bei dem Pat. mit einer Herzkatheter Untersuchung
eine Herzkranzgeferkrankung 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 krperliche
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 mte insbes
bei anlagebedingten oder erblichen Riskofaktoren die auch auftauchten mssten.Die
Berufsanamnese fehlt auch.

Wenn die Diagnosen und Ausschludiagnosen auch noch an einem Homunkulus sichtbar
wren wre das vielleicht auch hilfreich.Beim Aufsuchen mit dem Mauszeiger wrde
dann der Facharztbefund aufklappen schn wrs und so praktisch.
                     Gre von Jrgen Saucke


Software/Oberflche: 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 fr die eigene Fachrichtung im Umfang enthalten,
Facharztmodul/Grundbestnde 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 (unabhngig vom Patienten)

BDT-Schnittstelle
Im-/Export
gesamt/pro Zeitraum

5.3 Nutzen von kommerziellen Programmen
_______________________________________

Verschiedene Bereiche, besonders in der Inhaltspflege
halte ich keineswegs fr einen Open Content Ansatz geeignet
(siehe oben). Dort wre der Platz fr kommerzielle Anbieter.
Oder auch bei Administration, Wartung, Infrastruktur
(VPN, SSL, SSH fr Mail).


5.4 Nutzen von HDTF Services
____________________________

(CORBAmed)

Siehe:
http://www.omg.org
http://www.openemed.org


6 Einfhrungsstrategie
______________________

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
Prfung verlangt, ferner bei jeder diesbezglichen nderung im Programm.

Interessant sind die Kapitel Spezialprfungen, kombinierte Systeme und
Individualprfungen.

Demnach ist es durchaus mglich, Programmteile verschiedener Hersteller
zusammenzusetzen, aber auch das erfordert eine neue Zulassung des
&ldquo;gesamthaften Abrechnungssystems&rdquo;.

Ferner kann sich jeder Vertragsarzt sein eigenes Progrmmchen genehmigen
lassen, er ist dann selbst Softwareverantwortlicher (!). Fr die Prfung ist
dann u.U. die lokale KV zustndig.

Grundstzlich drfte das Problem &ldquo;Softwareverantwortlicher&rdquo; damit lsbar
sein. Den offenen Quelltext halte ich nicht fr 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
mglich sind.


6.2 Reihenfolge der Entwicklung
_______________________________

- erstmal vorrangig auf rztliche, medizinische Nutzung ausrichten

Diese Reihenfolge ist nicht festgeschrieben. Wir halten sie nur
gegenwrtig fr am sinnvollsten.

1) Medizinische Dokumentation
2) Formulardruck

Es klingt sinnvoll, zunchst mit nicht zulassungspflichtigen Programmteilen
anzufangen, das wre im wesentlichen die Dokumentation. Dabei halte ich es
fr besonders wichtig, ein gutes Datenbankdesign zu entwerfen. Vielleicht
kann ich hierzu auch als Anwender noch Hinweise geben (ich beschftige mich
gerade mit der Theorie relationaler DB).

In einem zweiten Schritt knnte man dann die Formulardruckfunktion und als
Grundlage dafr die Patientenstammdatenverwaltung in Angriff nehmen. Hier
wrde erstmals Genehmigungsbedarf bestehen.

Ein Formulargenerator wre sicher eine tolle Sache in Anbetracht der regional
unterschiedlichen und stndig sich ndernden Formulare. Ideal wre, wenn
jeder Benutzer ein damit selbst generiertes Formular per Mailingliste an
andere Anwender verschicken knnte!

Die KV-Abrechnung sollte dann als nchstes implementiert werden.
Dabei kann man vielleicht nochmal differenzieren zwischen einer reinen
Datenbanktabelle fr 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 wre (siehe oben).

Inwieweit ein kommerzieller Hersteller sein Abrechnungsmodul zur Verfgung
stellt, wei ich nicht. Schlielich hat Microsoft auch keine C-Compiler oder
Bibliotheken zur Entwicklung von Linux beigesteuert ;-)

Denkbar wre am ehesten ein kleinerer Anbieter, der noch nicht von einem
groen Softwarehaus geschluckt wurde und noch etwas Idealismus mitbringt.

Ansonsten wre an dieser Stelle bereits eine kleine Gruppe (>10) ernsthaft
interessierter Anwender notwendig, die sich die Zulassungsgebhren teilen.

Die Privat- und BG-Abrechnung lsst sich dagegen (vielleicht auch als
Vorlufer) wohl aus der Klasse (KV-)Abrechnung ableiten, mit Anbindung an
eine Textverarbeitung fr die Rechnungen.



Behandlungsdaten/Abrechnung/Verordnung:
kleine Karteikarte: begrenzt auf Ziffern. Diagnosen, Rezepte, Bemerkungen
fr den Einstieg - erweiterbar auf elektronische Kartei


6.3 Mglichkeiten zur &ldquo;Markteinfhrung&rdquo; - der Weg auf den Rechner des Anwenders
_______________________________________________________________________________


6.4 Partnerschaften
___________________

UVT-Verband
PVS-Verband
KVen
KBV
ZI
&ldquo;kleinere&rdquo; Anbieter und Einzelzulassungen
 - wer hat Adressen ?

Woher _knnte_ Widerstand zu erwarten sein ?
- jetzige Marktfhrer bei Praxis-EDV

7 Hardware Infrastruktur
________________________

Rechner

Bildschirme
touch screen fr Selbsteingabe von Anamnesebgen durch Patienten

KVK-Gerte

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 Sicherheitsmanahmen: 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
               Arbeitspltze

servertechnik
          backups brennen, digital notary
          failsave
          encrypted fs
          journalling
          raid 1
               controller fr root partition
               software fr 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 fr die neue Software geeignet?

Knnen unsere Daten problemlos bernommen werden?
- BDT-Schnittstelle beim Altsystem verfgbar?
- Was kostet die Ausgabe der Daten im BDT-Format?
- Handelt es sich um eine BDT-Schnittstelle nach dem aktuellen Standard oder um eine frhere Version?

Was kostet die bernahme der Daten ins Neusystem?

Knnen die Daten komplett bernommen werden oder gibt es Einschrnkungen (z.B. VK-Einlesedatum, VK-Daten, Privatpatienten, individuelle Bausteine, Texte etc.).
- Eventuell vorherigen Test durchfhren !!

Welcher Zeitpunkt ist fr eine Umstellung geeignet?
- Teminabsprache zur Umstellung genau festlegen
- Kann die Umstellung auch im laufenden Quartal erfolgen?
- Ist auch eine Schulungskraft zum Zeitpunkt der Umstellung verfgbar?


Welchen Inhalt sollte ein Softwareservice Vertrag haben?

- Oft stellt sich heraus, da ein vermeintlich gnstiger SoftwareserviceVertrag aufgrund zustzlich ntiger Eweiterungen oder nicht enthaltener Leistungsmerkmale im Nachhinein wesentlich teurer sein kann als ursprnglich angenommen.
- der Vertrag fr die Anwender-Programm-Pflege sollte folgende Positionen ohne Aufpreis enthalten:

- Update infolge KV- und Gesetzesbestimmungen,
- Update der Programme auf den laufenden Stand (inkl. Kosten fr Datentrger),
- Neuentwicklungen und Verbesserungen im Programm,
- Anpassungsprogramme an genderte Hardwarekonfigurationen,
- Zugriff auf die Hotline (Software- und Hardwarehotline,
- Sonderzugriff-Hotline (Rckruf/ Kurzschulungen am Telefon),
- Datenlieferungen Medikamentendatenbank,
- Datenlieferungen Kostentrgerdatei,
- Datenlieferung Gebhrenordnungen,
- Datenlieferung Diagnosedatei (ICD),
- Datentrger, Porto und Verpackung,
- Wartung der Sonderprogramme fr bestimmte Fachrichtungen,
- Wartungskosten fr Laboranbindungen, Homecomputing, etc.,
- Instandsetzung beschdigter Anwenderdateien (gegebenenfalls vor Ort),
- Dokumentationen zu allen Programmen und Programmnderungen,
- Handbuch bei Neuauflagen/ Handbuch-Ergnzungslieferungen,
- Umstellung auf andere Praxisform (ohne Zusatzkosten fr Praxisgemeinschaft, Gemeinschaftspraxis)
- Quartalsweise Kndigungsmglichkeit
- Monatliche/Quartalsweise Beitragszahlung nach Ablauf des Leistungsmonats

- Der Vertrag sollte inklusive aller Kosten fr die bentigten Datentrger, Transport und Verpackung ausgelegt sein. Bei Fernbertragungen 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 - &ldquo;GNU's Not UNIX&rdquo; 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 - &ldquo;Java Server Pages&rdquo; 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 &ldquo;Swing&rdquo;.
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 &ldquo;Wissensarchiv&rdquo; per Samba bereitstellen
dort werden Dokumente (doc, html, pdf, txt, rtf, ps) frei abgespeichert
auf Wunsch Aufteilung in Verzeichnisse mglich, aber nicht notwendig
nchtliche Indexierung per Glimpse
Suche im Archiv per Formular im Browser in LAN der Praxis
ist nicht als &ldquo;formelles&rdquo; Archiv fr Patientenbriefe, etc. gedacht
z.B. laxe Sicherheit, Datensicherung und Integrittskontrolle

QuickQuack Pflichtenheft/Requirements: siehe Website

&ldquo;Der Computer-Fhrer fr rzte&rdquo;, Ausgabe 1999
</verb>
</sect>

<sect>Anhnge
<sect1>GNU Free Documentation License
<p>
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 &ldquo;free&rdquo; 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 &ldquo;copyleft&rdquo;, 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 &ldquo;Document&rdquo;, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as &ldquo;you&rdquo;.

A &ldquo;Modified Version&rdquo; 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 &ldquo;Secondary Section&rdquo; 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 &ldquo;Invariant Sections&rdquo; 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 &ldquo;Cover Texts&rdquo; 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 &ldquo;Transparent&rdquo; 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 &ldquo;Transparent&rdquo; is called &ldquo;Opaque&rdquo;.

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 &ldquo;Title Page&rdquo; 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, &ldquo;Title Page&rdquo; 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 &ldquo;History&rdquo;, 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 &ldquo;History&rdquo; 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 &ldquo;History&rdquo; 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 &ldquo;Acknowledgements&rdquo; or &ldquo;Dedications&rdquo;, 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 &ldquo;Endorsements&rdquo;. Such a section may not be included in the Modified Version. N. Do not retitle any existing section as &ldquo;Endorsements&rdquo; 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 &ldquo;Endorsements&rdquo;, 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 &ldquo;History&rdquo; in the various original documents, forming one section entitled &ldquo;History&rdquo;; likewise combine any sections entitled &ldquo;Acknowledgements&rdquo;, and any sections entitled &ldquo;Dedications&rdquo;. You must delete all sections entitled &ldquo;Endorsements.&rdquo;

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 &ldquo;aggregate&rdquo;, 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 &ldquo;or any later version&rdquo; 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.
</sect1>

<sect1>Danksagungen

<p>
<verb>
Hier sind Menschen und Firmen aufgelistet, die nicht zum eigentlichen
Entwicklerteam gehren, sich aber um das Vorwrtskommen offener
Projekte in der Medizin verdient gemacht haben.

Private E-Mail-Adressen sind bewut nicht aufgefhrt.

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 fr 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 fr die kassenrztliche Versorgung in der Bundesrepublik
 - http://www.zi-koeln.de/ZIK/themen/arznei/werm-11.htm
 - stellte Testdaten der Medikamentendatenbank AMIS intern fr
   Programmierzwecke zur Verfgung (keine Weitergabe an Dritte
   mglich, bitte von Anfragen absehen !)

Frau D. Brcher von der
rztlichen Verrechnungsstelle Bdingen GmbH
 - http://www.pvs-buedingen.de
 - stellte die Definition des Datenformats zur Einreichung von
   Privatrechnungen auf Datentrgern bereit

Herr Jrg Garritzmann
 - mailto:j.garritzmann@gmx.de
 - stellte seine guten Kontakte in der Praxis-EDV-Branche zur Verfgung und
   vermittelte schwer beschaffbare Informationen

Frau H. Krger-Brand
Beilage &ldquo;PraxisComputer&rdquo; des Deutschen rzteblattes
 - http://www.deutsches-aerzteblatt.de
 - ermglichte die Verffentlichung einiger Artikel zur Materie

Firma Krake Softwaretechnik
 - http://www.krake.de
 - ermglichte Einblick in den Quellcode der Privatliquidationssoftware Bub
</verb>
</sect1>
</sect>

</article>