Thesen: schlankes Programm = modularer Aufbau

[wahnfried]

IDEALVORSTELLUNG:

Ein SCHLANKES PRAXISPROGRAMM impliziert, nur die Funktionalität zu installieren, die benötigt wird.

Das bedeutet: ein MODULARER AUFBAU des Programms ist nötig.

Der Datenbank werden die verschiedenen Module zu Kassenabrechnung, Medikamentenverwaltung, Chipkartenverarbeitung, eDMP, IV-Verwaltung in den verschiedenen Varianten, HzV-Verwaltung, Privatabrechnung, Textverarbeitung, Psychotherapie-Verwaltung, Vorsorge-Verwaltung, Dokumenten-Import (usw.) beigefügt bzw. zur Seite gestellt, diese kommunizieren jeweils mit der Datenbank und bei Erfordernis auch untereinander OHNE DASS das Fehlen eines dieser Module die Arbeit eines anderen Moduls behindert.

Jeder Anwender entscheidet selbst, welche Module beim Installieren des Programmes einbezogen sind und kann nachträglich jederzeit ein weiteres Modul dazu-installieren. Wer keine DMP durchführt, braucht das Modul nicht (und analog...). Aufgaben mit der Vorgabe einer elektronischen Kommunikation (Abrechnungs-Daten-Versand) stellen diese Daten in einer Form zur Verfügung, die vom Kommunikationsmodul weiterverarbeitet werden kann.

Die Textverarbeitung hätte wiederum entsprechende Kommunikationsschnittstellen zu mehreren Office-Linien, die nach Bedarf programmiert werden.

Die Medikamentenverwaltung kann über frei programmierbare Schnittstellen mit jetzigen und zukünftigen Medikamenten-Datenbanken kommunizieren. (Wegen der Menge an Arbeit für die Zertifizierungs-Maßnahmen wird der Aufwand zeitlich verteilt werden, d.h. nach und nach realisiert werden müssen.)

Auch Kommunikationstechnologien sollen auf einer einheitlichen und offengelegten Schnittstellenbasis beruhen, die es ermöglicht, die Art der Kommunikationsanbindung frei zu wählen oder dafür eine Verbindung zu schaffen.

Die Darstellung am Monitor sollte durch "skins" sowie durch die Möglichkeit zum Aktivieren und Deaktivieren bestimmter optionaler Anzeige-Elemente veränderbar sein. Auch dies impliziert ein Modul (das allerdings nicht optional ist) für Anzeige-Funktionalität.

Grüsse, Wahnfried

(wer hat in welchen Programmen etwas von diesen Ideen wiedergefunden?)

[shilbert]

Ein modularer Aufbau ist bei fast allen Programmen prinzipiell möglich. Ich vermute die Hersteller installieren alles auf einen Rutsch weil sonst pausenlos Anwender anrufen würden warum Modul X,Y,Z fehlt. Eine Abhängigkeit von Modulen untereinander ist eher selten. Meist sind es weninge Grundmodule auf die andere Programmfunktionen aufbauen.

Bei heutigen Festplattenpreisen und Prozessorleistungen wird zunehmend weniger auf Optimierung geachtet. Entwickler haben üblicherweise sehr schnelle Rechner weil die Programmkomplilierung oft schnelle Rechner braucht.

Beispiel GNUmed (wiki.gnumed.de): Komplett modular, Funktionalität ist in Plugins gegliedert. Installiert wird alles Komplett. Kann jederzeit geändert werden. Man definiert pro zugreifendem Arzt welche Plugins und damit Funktionalität gestartet wird. Officeanbindung existiert derzeit nur für OpenOffice. Alle Paket mit entsprechenden Kommunikationseinrichtungen können angebunden werden. Wie das geschehen kann ist offengelegt.

Die Medikamentendatenverwaltung hängt in erster Linie von dem Medikamentendatenbankhersteller ab. GNUmed könnte das aber die Schnittstellen sind seiten der Medikamentendatenbankfirmen nicht öffentlich.

Als Kommunikationsstandard schlage ich XMPP vor. Der ist öffentlich, weit verbreitet und lizenzkostenfrei. Datensicherheit bei der Übertragung kann gewährleistet werden. Datenübertragung kann von Arzt zu Arzt oder via Zwischenserver erfolgen.

Die änderbare Anzeige am Bildschirm ist anspruchsvoll. Das realisiert man eleganterweise mit XML-basierten Oberflächen (Schlagwort, nicht trivial) oder mit festen aber verschiebbaren Elementen (advance user interface, http://videos.kirix.com/labs/2009-06-30 ... i-demo.htm)

Mindestens genauso wichtig ist aber die Datenbank. Das Datenbankschema also das Schubladensystem sollte gut strukturiert sein (dazu gibt es unzählige wissenschafftliche Vorarbeiten) und die Datenbank muss sicher und geeignet sein. Idealerweise handelt es sich nicht um eine Datenbank die von einer Firma allein hergestellt und abhängig ist.

Die gesetzlichen Vorgaben verlangen stetige Updates. Idealerweise würden diese als ein modulares Abrechnungsmodul angeboten. KVen sollten gemeinsame eine Abrechungsmodul programmieren und an Hersteller lizensieren. Dann könnten sich die Hersteller auf medizinische Programmfunktionen konzentrieren.

[DerEchteFreund]

Idealerweise sollte man den Datenbankzugriff über einen OR-Mapper kapseln, somit hält man sich die zugrunde liegende Datenbank unabhängig.

[wahnfried]

Idealerweise sollte man den Datenbankzugriff über einen OR-Mapper kapseln, somit hält man sich die zugrunde liegende Datenbank unabhängig.

Hallo EchterFreund,

ich nehme an, daß das eine Art "Verteilerkasten" ist, bei dem die Datenbank-Einträge des Programms in für verschiedene Datenbanken verständliche Formen übersetzt werden können?

Soetwas sollte es auch auf der Ausgabe-Seite geben (für Darstellung per Browser oder direkt auf dem gerätezugeordneten Bildschirm, dies ggfs. in verschiedenen "skins": siehe auch der diesbezügliche Hinweis auf Informationen zur Realisierbarkeit im Beitrag von S.Hilbert.

Viele Grüsse, Wahnfried

[DerEchteFreund]

Ein OR-Mapper ist der Brückenschlag zwischen objektorientierter Entwicklung und relationalen Datenbanken. Es erlaubt dem Entwickler, direkt wie gewohnt in Objekten zu entwickeln und nicht jedes mal das Rad der Datenbankkapselung neu zu erfinden. Nebenbei hat man dann noch das Gimmick einer groben Datenbankunabhängigkeit.
Das Frontend sollte letztendlich nur auch ein solches sein, also wirklich nur für die Darstellung genutzt werden.
Typische 3-Tier Applikation:

1. Persistenz / Datenbank
2. Geschäftslogik
3. Präsentation

Erstere wäre quasi der OR-Mapper, Schicht 2 ließe sich wunderbar in Webservices umsetzen (was jetzt nicht bedeutet, dass das im Internet laufen muss!).
Worauf die Präsentation letztendlich läuft ist dann quasi egal (QT, Java, Browser, Flex, etc..), da diese nur die Informationen der Geschäftslogik darstellt und die Eingaben zur Verarbeitung zurück liefert...

Letztendlich eine sehr interessante Sache, aber vergessen wir nicht den Aufwand der dahintersteckt. Wer schonmal die GDT/BDT/LDT-Satzbeschreibung gelesen hat, weiss was schon alles allein zu einer Geräteanbindung bzw. Laborimport gehört...

[shilbert]

Eine solche Trennung ist bei GNUmed bereits Standard. Da programmiert der Oberflächenprogrammierer gegen eine Mittelschicht, die die Datenbankzugriffe gegen die Oberfläche kapselt. Sollte sich am Datenbankschema mal was ändern wird die Mittelschicht angepasse und die Oberfläche funktioniert ohne Änderung weiter.

Weboberflächen sind hipp aber ne Geräteanbindung zu programmieren nicht gerade trivial. Daher muss ich eine Software auf eine Oberflächenvariante beschränken (aber alle anderen möglichst offen lassen).

Genau das ist bei GNUmed schon umgesetzt. Wie gesagt wenn jemand ein Abrechungsmodul als solches Modul bereitstellt könnten man mit GNUmed binnen kürzester Zeit abrechnen.

Sebastian Hilbert

[hdb]

Einfach mal intramed agesehen? Auch die Folgekosten will man ja im Griff haben.

Viele Grüße

[Johnny]

Modulare Aufbau?

Vergessen wir eines nicht, nachdem dieser thread schon in die Jahre gekommen ist, nun gibt es diese Modulartät bei TM z.B. in Form von Zusatzprogramme (z.B. Visiodoc, Impfdoc ) oder als Facharztzusatzmodul (z.B. Gyn Modul)
Und die Folge: Dafür wird natürlich zusätzlich die Hand aufgehalten.

Gruß aus Kiel

Johnny

[DrHJvdB]

Da stimm ich zu: wenn die Modularität nur dazu dient, den Umsatz des Herstellers zu erhöhen, deckt sich das nicht mehr mit einer kollegialen Firmenphilosophie!

[schmidt-dietrich]

Wieder Zustimmung.
Auch weigern sich beide Platzhirsche die Schnittstellen offenzulegen (was eingentlich gesetzlich nicht erlaubt ist)... daher kein einfacher Austausch Arzt-zu-Arzt ...