Zusammenarbeit mit Abrechnungs-Software in Deutschland

Hier möchte ich Vorstellungen zur Zusammenarbeit zwischen einer Abrechnungs-Software (in Deutschland zertifiziert) und GNUmed entwickeln.

Für Diskussionen schlage ich das Forum "vondoczudoc" vor (dort Lesen ohne Anmeldung möglich, im GNUmed-Forum in "hippokranet" ist bereits für das Lesen der Beiträge eine Anmeldung bei hausarzt.de/facharzt.de erforderlich). Die dort gesammelten Erkentnisse werde ich versuchen, hier einzuarbeiten. Bei vondoczudoc ist als Startbeitrag auch der Ausgangs-Stand dieser Vorstellungen dokumentiert.

Hanfried Gehlig, 30. August 2009

Prämissen
GNUmed ist selbst nicht als Abrechnungssoftware konzipiert. Es gibt jedoch Gedanken zu Abrechnungsfragen, zusammengefasst im Abschnitt (topic) "Billing". Diese lassen sich nicht direkt auf die deutschen Verhältnisse übertragen. Der hiesige Zertifizierungs-Moloch erscheint deutschland-typisch, seine Berechtigung und Notwendigkeit sollte immer wieder aktiv in Frage gestellt werden. Gleichwohl muss man ihm derzeit nachkommen, um ein Abrechnungsprogramm in Deutschland für Kassenabrechnung benutzen zu dürfen.

Die Entwicklung einer eigenständigen Abrechnungsfunktionalität von GNUmed wäre ein Mammutprojekt und insofern wohl unrealistisch. Wenn wirklich die Ressourcen auf dem amtlichen (zertifizierungspflichtigen) Gebiet ausgelagert werden sollen - der Idee in Sebastian Hilberts Brief von 2007 entsprechend (siehe unter "KVDT"): die Arbeit der amtlichen Anpassungen nur einmal für viele Anwender durchzuführen und dann für Anwender anderer Programme gegen Lizenzkosten bereitzustellen - benötigt man die Verfügbarkeit dieses Abrechnungsprogrammes jederzeit (nicht nur zur Zeit einer zu erstellenden Abrechnung). Eine diskontinuierliche Bereithaltung eines solchen Abrechnungsprogrammes würde erfordern, innerhalb von GNUmed den gesamten Bereich der Abrechnungsscheinerstellung und -Verwaltung detailliert abzubilden - dann wäre es aber ein Leichtes, aus diesen Informationen auch eine Abrechnungsdatei allein aus den in GNUmed vorhandenen Informationen zu erstellen (was wohl auch die Verpflichtung zur kompletten Zertifizierungsorgie und selbst ohne diese mindestens die Notwendigkeit der quartalsmäßigen Aktualisierungen nach amtlichen Vorgaben bedeutet).

Um in Deutschland kassenärztliche und privatärztliche Abrechnung zu ermöglichen, muß in diesem Sinne eine Zusammenarbeit mit einem zertifizierten (KBV-zugelassenen) Abrechnungsprogramm entwickelt werden. Dazu gehören:
  1. Strukturen der Zusammenarbeit zwischen GNUmed und einem Abrechnungsprogramm
  2. Anpassungen von GNUmed für das sinnvolle Handling dieser Zusammenarbeit
  3. Anpassungen des Abrechnungsprogramms / der Abrechnungsprogramme, um diese Zusammenarbeit zu ermöglichen
  4. Zusätzliche Features, die GNUmed aufweisen sollte, um den Gewohnheiten des abrechnenden Arztes in Deutschland entgegenzukommen
  5. Desweiteren wäre eine Formularbedruckung von Seiten GNUmed zu entwickeln, die die nichtamtlichen Formulare betrifft (einige amtliche Formulare müssen m.E. zertifiziert werden, daher sollten diese aus dem Abrechnungsprogramm heraus generiert werden). Ein Formularkopf wie bei deutschen Kassenformularen üblich sollte jedoch auch von GNUmed direkt erzeugt werden können.
  6. Das Handling Externer Listen und Programme, die sowohl von GNUmed als auch vom Abrechnungsprogramm angesprochen werden, muss aufeinander abgestimmt werden, was die Anbindung von Programmen wie OpenOffice, Dicom-Viever o.ä. sowie von Datenbanken wie für z.B. Medikamente, Diagnosen, Gebührenordnungen betrifft. Diese sollen sowohl von GNUmed als auch von einem Abrechnungsprogramm aus in identischer Weise benutzt werden können, wobei gleichartige Funktionen von beiden Programmen durch vergleichbare Bedienungselemente angesteuert werden sollen (z.B. Tastatureingabe), um nicht je nach Stand des Arbeitsschrittes oder des Programmes unterschiedliche Bedienung vergleichbarer Funktionen lernen zu müssen.

Dabei ist es sinnvoll, die innerhalb von GNUmed anzupassenden Bereiche so zu entwickeln, daß sie auch Abrechnungsfunktionen in anderen Ländern unterstützen können. Daher sollte die Dokumentation der abrechnungsrelevanten Informationen in GNUmed sehr variabel (flexibel) gestaltet werden, wobei durch ein Kommunikationsmodul zwischen der Abrechnungs-Software und GNUmed jeweils für die gewünschte Abrechnungsart die Zusammenarbeit zwischen Abrechnungssoftware und GNUmed strukturiert wird.

Die Entwicklung dieses Kommunikationsmoduls und der mit den dortigen Entwicklern abgesprochenen Anpassungen innerhalb von GNUmed und des Abrechnungsprogrammes wäre Aufgabe einer zu gründenden - möglichst genossenschftlich organisierten - Vereinigung von Ärzten und EDV-Fachleuten, an der GNUmed und das Abrechnungsprogramm mindestens ideell beteiligt sein würden. Hierfür wurde die Domain Arzt-Programm.de aktiviert, wo die Ideen aus vondoczudoc und hippokranet bald zusammengeführt und innerhalb eines geschlossenen Bereiches für die konkrete Entwicklung vorbereitet werden können.

Strukturen der Zusammenarbeit
GNUmed und das Abrechnungsprogramm sollen Veränderungen des aktuellen Patienten parallel vollziehen. Das heißt:
  1. Wenn der Benutzer im Abrechnungsprogramm arbeitet und dort einen konkreten Patienten aufruft, soll dieser Patient auch in GNUmed aktiviert werden, dies nach Wahl des Benutzers in der bestehenden Instanz von GNUmed oder in einer neu zu öffnenden Instanz (die Begrenzung auf eine definierte Zahl von Instanzen sollte möglich sein). Das Kommunikationsmodul übermittelt dem Abrechnungsprogramm, welche Patienten in wieviel Instanzen (sessions) von GNUmed aktiviert sind und übernimmt den Wechsel des aktiven Patienten in der bestehenden Instanz von GNUmed (sofern "multi-session" bei GNUmed nicht gewünscht ist, dann wäre nur eine Session offen) oder aktiviert diejenige Session von GNUmed, die dem aktivierten Patienten entspricht bzw. eröffnet eine neue mit dem im Abrechnungsprogramm aktivierten Patienten bzw. (bei erreichter begrenzter Zahl offener Sessions) löscht die am längsten geöffnete Session, um eine neue eröffnen zu können. Wenn der konkrete Patient in GNUmed noch nicht bekannt ist, soll er dort automatisch entweder neu angelegt oder als Namens-/Adressen-Veränderung bei einem bereits existierenden Patienten eingetragen werden.
  2. Wenn der Benutzer in GNUmed arbeitet und dort einen konkreten Patienten aufruft, soll dieser Patient auch im Abrechnungsprogramm aktiviert werden und das Kommunikationsmodul soll an GNUmed die Informationen melden, ob für diesen Patienten aktive und frühere Abrechnungsscheine existieren. Falls keine aktiven Abrechnungsscheine existieren, soll in GNUmed angeboten werden, per Einsprung in das Abrechnungsprogramm dort einen aktiven Abrechnungsschein zu erstellen.
  3. Einträge von Ziffern oder Diagnosen innerhalb von GNUmed sollen direkt auch als Abrechnungsziffern und Abrechnungsdiagnosen im Abrechnungsprogramm eingetragen werden, Grunderkrankungen als Dauerdiagnosen. Dazu müßte entweder eine Anbindung der offiziellen Diagnosen-Datei mit ICD10-GM-Verschlüsselung bzw. Gebührenordnungs-Datei (EBM/GOÄ/BG-GOÄ/HzV/IV) an GNUmed erfolgen oder die Auswahl der Diagnosen/Ziffern erfolgt jeweils über das Abrechnungsprogramm mit daraufhin direkter Übertragung in die darauf wartende Eingabemaske von GNUmed. Hier müßte dann die Zuordnung dieser übertragenen abrechnungsrelevanten Angaben zu den bestehenden oder ggfs. neu anzulegenden Episoden (den Grunderkrankungen zugeordnet) gelöst werden. Wenn die Auswahl direkt in GNUmed erfolgt, muß das Kommunikationsmodul veranlassen, daß die Zuordnung der abrechnungsrelevanten Informationen im Abrechnungsprogramm zu einem der aktiven Abrechnungsscheine erfolgt und ggfs. zwecks Dokumentation nach GNUmed (als Parameter der Ziffern-/Diagnosendokumentation...) übergeben wird.
  4. Da viele dieser amtliche Listen in Form von XML-Dateien geliefert werden, wäre für die Anbindung dieser Datenbestände (...an das Abrechnungsprogramm und/oder das Kommunikations-Modul?) ein direktes Ansprechen der amtlich gelieferten XML-Dateien wünschenswert, weil dadurch der Aufwand beim Aktualisieren sinken wird.
  5. Kürzelverwaltung sollte sowohl für Abrechnungs-Ziffern, Diagnosen als auch für Medikamente und Textbausteine (usw.) möglich sein. Dies kann vom Abrechnungsprogramm oder vom Kommunikationsmodul ermöglicht werden.

Anpassungsbedarf
In ärztlicher Arbeit ist man überwiegend gewöhnt, innerhalb einer chronologisch geordneten Karteikarte zu dokumentieren und abzurechnen. GNUmed arbeitet innerhalb eines Strukturbaumes aus Grunderkrankungen und Krankheitsepisoden. Ein chronologisches Kartei-Journal kann bisher lediglich in Form einer Druckvorschau exportiert werden.

Hier halte ich es zur Förderung der Akzeptanz innerhalb der Anwender in Deutschland für dringend erforderlich, daß dieses chronologische GNUmed-Kartei-Journal bis zu einer Eingabe-Funktionalität weiterentwickelt wird, die anstelle der jetzigen Art der episoden-bezogenen Daten-Eingabe alternativ benutzt werden kann. Vorschläge zur Ablauf-Strukturierung einer solchen Eingabe in einem eingabefähigen Kartei-Journal von GNUmed sind in Vorbereitung, zusätzlich auch Vorschläge zur Erweiterung der Eingabemöglichkeiten der jetzigen GNUmed-Dateneingabe-Masken für abrechnungsrelevante Daten.

Diese Entwicklung einer Eingabe-Funktionalität des chronologischen Kartei-Journals von GNUmed wäre in Absprache mit GNUmed sicherlich auch eine Aufgabe für die Entwicklergruppe im Rahmen der zu gründenden (genossenschaftlichen?) Entwickler- und Unterstützer-Gemeinschaft.

Weitere Anpassungen innerhalb von GNUmed beträfen die Bereitstellung der Möglichkeit, in der GNUmed-Datenbank die abrechnungsrelevanten Informationen wie z.B. ICD10-Verschlüsselung zur Diagnose, Ziffer mit Parametern, Betriebsstättenzuordnung, evtl. auch Verfeinerungen bei der Arztzuordnung - jeweils mit Zeitstempel wie bei GNUmed bereits üblich - dokumentieren zu können.

Die Labordatenübertragung nach GNUmed direkt oder die Abfrage der in dem Abrechnungsprogramm übertragenen Labordaten wäre ein weiterer wichtiger Entwicklungspunkt.

Anpassungsbedarf von Seiten eines Abrechnungsprogrammes kann erst beurteilt werden, wenn eine konkrete Zusammenarbeit betrachtet werden kann.

Wieviel von diesen Gedanken im Verlaufe der Diskussion und Entwicklung abgewandelt werden muß, um realisiert werden zu können, kann noch niemand wissen. Ich wünsche mir jedoch, daß dabei möglichst wenig Kompromisse nivellierender Art stattfinden.

(to be continued)

-- GehligBS - 30 Aug 2009
Topic revision: 13 Apr 2010, SebastianHilbert
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark