Inhalt
LQ-Recorder
Programming
Colours & Notes
Literatur
Links
Neues?
Dr. med. Jörg-Michael Sigle
Beiträge zu Elexis
Open Source Praxis-Software
(This page is only available in German.)
Aktueller Status
Inzwischen habe ich mein msword_js MS-Word-Interface schon seit vielen Jahren fertig entwickelt.
Es läuft seit Fertigstellung völlig stabil.
Es funktioniert mit allen getesteten Versionen von Microsoft Word (mindestens 2003 bis etwa 2013), basiert auf der Jacob API und kann demnach die Office-Anwendungen bidirektional kontaktieren. Ein direktes Manipulieren von MS Office Dateien oder eine Beschränkung auf die mit XML-Dateiformaten arbeitenden Versionen von Office gibt es hier nicht.
Meine anderen Erweiterungen wurden bis zur Elexis Version 3.7 js 64-Bit portiert und sind so ebenfalls seit vielen Jahren produktiv und stabil im Einsatz.
Meine Elexis-Version ist verfügbar unter: https://github.com/jsigle
Ein weiteres Nachführen meiner Beiträge auf die Version 3.9 folgt voraussichtlich, sobald ich Zeit und Ruhe dafür finde.
Die weiter unten folgenden Inhalte dieser sind demgegenüber sehr veraltet.
Diese Seite...
...bietet Verbesserungen der Elexis Kernsoftware, Druckvorlagen, Hilfsprogramme, Anleitungen oder Erfahrungsdokumentation.
Meine Beiträge entstanden aus meiner Beratung der Lungen-Schlaf-Praxis von Dr. Jürg Hamacher in Bern - lösen also Probleme, die dort im Alltag gesehen wurden.
Das Update für die Adress-Suche wurde von Medelexis übernommen; das NOAText_jsl und einige der anderen Erweiterungen sind inzwischen in Niklaus Gigers elexis-bootstrap Repository enthalten.
Die entsprechenden Arbeiten zusammen mit Niklaus Giger haben Dr. Peter Schönbucher und Dr. Stefan Henzi unterstützt. Es braucht nämlich immer noch einiges an Code Review, putzen von Kommentaren & Monitoring-Code, Erstellen von Patches, ggf. Dokumentation - selbst wenn eine neue Funktion entwickelt oder ein technisches Problem gefunden und behoben ist. Aus diesem Grund mache ich alles Neue erst einmal hier zugänglich.
Selbstverständlich freue ich mich auch sonst über jede Unterstützung, Weiterempfehlung und Anregung.
Bitte besuchen Sie auch einmal www.ql-recorder.com (elektronische Patientenfragebögen, off-line/on-line, mit u.a. SQL-, Perl-, WWW-, GDT/LDT- und HL7-Schnittstellen) und www.jsigle.com !
Lizenzbedingungen / Kosten
Grundsätzlich möchte ich das Motiv der OpenSource pflegen.
Was ich hier bereitstelle soll jedoch nur zu Testzwecken, als Machbarkeits-Demonstrator, zur Anwendung nach individueller Absprache und zum Erfahrungsaustausch dienen.
Source-Code veröffentliche ich entweder durch meinen github account (s.u.) oder ebenfalls nach Absprache.
Wenn Sie die Software produktiv verwenden - und besonders, wenn Sie durch ein von mir bezogenes Paket oder Plugin ein Element Ihres Medelexis-Abonnements ersetzen, oder dieses als Supporter Ihren Anwendern bereitstellen - würde ich mich über eine entsprechende Unterstützung meiner Arbeit durch Sie freuen.
Haftungsausschluss - keinerlei Zusicherung, Garantie oder Gewährleistung
Das Material wird bereitgestellt ohne Zusicherung der Funktionsfähigkeit, der Freiheit von Fehlern, der Nutzbarkeit für irgendeinen Zweck und unter Ausschluss jeglicher Gewährleistung. Nutzung auf eigene Gefahr. Allfällige Nutzer sollten Risiken adäquat beurteilen und selbst Vorsorge gegen Schäden treffen können.
Sofern Inhalte Ihrer Meinung nach Rechte anderer verletzten sollte - vielleicht wo ich von Dritten irrtümlich unter entsprechenden Lizenzen bereitgestellte Software weiter bearbeitet habe - bitte ich Sie um eine kurze Mitteilung. Jeder berechtigten Bitte um Entfernung von Inhalten komme ich gerne nach.
Meine Erfahrungen basieren auf von mir selbst compilierten und verbesserten Fassungen von Elexis 2.1.6 und 2.1.7.
Herzlichen Dank an:
Jürg Hamacher - den ich seit 2010 im Hinblick auf die IT in seiner Praxis berate. Dies hat meine Beschäftigung mit Elexis begründet und mir ermöglicht, etwas dazu beizutragen.
Peter Schönbucher und Stefan Henzi - die ein Treffen zwischen Niklaus Giger und mir in 04/2013 gern und sehr substantiell unterstützt haben, um einige Beiträge in den Hauptstamm der Elexis-Entwicklung zu bringen.
Niklaus Giger, Stefan Henzi, Peter Schoenbucher und Tony Schaller - für ganz individuellen Rat und freundlichen Austausch.
Der Medelexis AG - die das Update zum Adress-Plugin in 2012 honoriert hat.
Einigen weiteren Anwendern für ihre freundlichen und positiven Rückmeldungen!
Index
- Über Elexis
- Elexis_js - Ein einigermassen aktuelles Elexis mit Erweiterungen, u.a.:
- Kopieren von Kontakt-Daten in die Zwischenablage in verschiedenen Formaten von verschiedenen Orten
- Putzen der Kontakt-Daten auf Knopfdruck
- [? Prüfung von Einträgen in der Liste alter Bestellung zur Vermeidung von "Nonsense" in der Auswahlliste ?]
- Verbesserte Prüfung der Verrechnungspositionen beim Eintragen und vor dem Erstellen von Rechnungen
- Automatisches Entfernen der Rahmenlinien von Tabellen, die in Textdokumenten erzeugt wurden (z.B. Rezept)
- Verändertes Handling von CRLF am bei Übernahme von Text aus Datenfeldern, z.B. "Patient-Detail" - "Diagnosen" etc. oder "Konsultation".
Nun kann kann man Text wiederholt automatisch aus einem Datenfeld in einen Brief übernehmen lassen, und von dort wieder per copy-paste in das Datenfeld einfügen - enthaltene Umbrüche überstehen das jetzt. [...]
- Integrierte Stresstests für das Text-Plugin
- Ab Elexis 2.1.7.dev-qualifier-js-20131101 mit NOAText_jsl ab Version 1.4.18 [das sollte recht brauchbar sein]
Ab Elexis 2.1.7.dev-qualifier-js-20130625 mit NOAText_jsl ab Version 1.4.15 [noch nicht gut]
für TextDokumente in den Views Brief, Rezept, AUFZeugnis, Bestellung, Laborblatt:
Elimination von zwei Wegen, auf dem andere Versionen von Elexis und Textplugin Benutzereingaben verlieren konnten.
- Sicherstellen, dass nach Arbeiten in anderen Views die View des Textdokuments wieder aktiviert wird (Rahmenfarbe!),
wenn deren Inhalt wieder verändert wird.
In der Folge werden nachfolgende Änderungen verlässlich gespeichert.
- Automatisches Speichern von Änderungen nach festem Zeitintervall.
- Automatisches Speichern von Änderungen nach Variablem Zeitintervall, abhängig von den vergangenen Zeiten seit dem letzten erfolgten Speichern und der der letzten Benutzereingabe.
- Tatsächliches Speichern nur, wenn zuvor auch Inhalte geändert wurden.
- Omnivore_js - Ein erweitertes Dokumentenarchiv
- Bequemer und schneller Dokumentenimport ohne vermeidbare Zwischenschritte:
- Hilfreiche Meldung, wenn Namen importierter Dateien zu lang sind.
- regelbasiertes automatisches Wegarchivieren importierter Dateien.
- Automatisches Entfernen von Whitespace in Titel und Stichworten bei Import und Bearbeiten.
- Bequemer und schneller e-Mail-Versand ohne vermeidbare Zwischenschritte:
- Konfigurierbare sinnvolle Dateinamen für Temporärdateien.
- Direktes drag & drop aus Omnivore_js heraus nach Thunderbird und Outlook.
- (Siehe auch Beiträge im Elexis-Forum, Beratung zu automatischer e-Mail Verschlüsselung auf Anfrage)
- NOAText_jsl - Ein TextPlugin mit verbesserter Stabilität, kompatibel (mindestens) bis LibreOffice 3.6.2.2 (und 4.0.2 mit alternativen Bibliotheken)
- msword_js - Entwicklung eines Plugins für Microsoft Word - Prototyp mit Grundfunktionen
- Adress-Suche js - Erneute Aktualisierung - funktioniert wieder nach dem 24.11.2013
- ...
Umfangreiches weiteres Material ist vorhanden.
Über Elexis
Elexis_js - Ein einigermassen aktuelles Elexis mit Erweiterungen
Status
Aktuell (nur in Bezug auf das NOAText_jsl Textplugin):
Version 2.1.7.dev-qualifier-js-20131101, NOAText_jsl 1.4.18,
basierend auf Niklaus Gigers elexis-bootstrap von 2012-05-23.
War noch nicht gut, bitte ersetzen:
Version 2.1.7.dev-qualifier-js-20130625, NOAText_jsl 1.4.15.
Vergleich mit Elexis / MedElexis 2.1.7.1.rc4 bis rc6:
- Zusätzlich enthalten:
- Nochmals Review und Verbesserung von NOAText_jsl auf Version 1.4.18 - sowie auch der Aufrufe des Textplugins in Elexis (2013-11-01).
- Die von mir Ende April eingebrachten Beiträge sind vollständig und teils mit nochmals im Detail verbesserter Funktion enthalten: Beide Stresstests, Kopieren von Kontakten an Zwischenablage, automatisches Putzen von Kontakteinträgen, Warnungen bzw. Rückfrage bei Verrechnung von 0.00 Franken; Abbruch der Erstellung von Rechnungen für Konsultationen ohne Verrechnungsleistung, on-the-fly-Korrektur, wenn ein "Patient" nicht zugleich als "Person" markiert ist.
- Omnivore_js und NOAText_jsl robuster gegenüber ungültigen Zeichen in der Konfiguration für automatische Dateinamen; Omnivore_js korrigiert unnötigen Whitespace auch beim Bearbeiten bestehender Einträge; Drag & Drop von Omnivore_js nach Thunderbird, Outlook oder in andere Programme.
- NOAText_jsl sowie allgemeine Infrastruktur für Textplugins:
Unsichtbare Linien bei Tabellen, Zuverlässiges plus automatisches intervallbasiertes Speichern diverser Textdokumenten.
Nun kann kann man Text wiederholt automatisch aus einem Datenfeld in einen Brief übernehmen lassen, und von dort wieder per copy-paste in das Datenfeld einfügen - enthaltene Umbrüche überstehen das jetzt. [...]
Elexis_js 2.1.7.dev-qualifier-js-20131101 und NOAtext_jsl 1.4.18 setzen sich gegenseitig voraus.
- Abweichende Funktionalität:
- Stresstests: Beide enthalten; nicht in ein Plugin ausgelagert; können von Anwendern aufgerufen werden; Anzahl der Zyklen und Zugriffsrecht nicht einstellbar.
- Neue Funktionen zur Rechnungsprüfung noch nicht konfigurierbar - könnte durch ein zukünftiges Plugin auch einzeln ergänzbar sein.
- Eine Verbesserung, die Niklaus Giger zum Monitoring eines Textplugins mit separatem Fenster geschrieben hat - als Antwort auf meine Demonstration eines möglichen Datenverlusts, den ich mit o.a. Massnahmen behoben habe - ist (noch) nicht enthalten. Ich habe noch nicht angeschaut, ob das nach meinen o.a. Verbesserungen für solche Plugins noch notwendig ist.
- Diejenigen Text-Plugins ausser noatext_jsl, die in der OpenSource-Fassung enthalten sind, wurden um Stubs - und nur um Stubs - für Methoden erweitert, welche meine neue StatusMonitoring-Erweiterung voraussetzt. Die Funktionen wurden noch nicht implementiert. Wenn es jemand für ein bestimmtes Plugin alsbald haben will, ist das auf Anfrage jedoch machbar.
- Ältere Textplugins funktionieren mit dieser Fassung von Elexis_js möglicherweise nicht mehr!
(Bitte selbst genau testen oder mich bei Bedarf um Test oder Update bitten.)
Aus der laufenden Entwicklung!
Keinerlei Gewährleistung! Verwendung auf eigene Verantwortung!
Sachkundiger Anwender, eigene Funktionstests in unkritischer Umgebung und gute Backups empfohlen!
Inhalt / Hintergrund
Ich stelle hier ein installierbares Elexis 2.1.x bereit. Dieses enthält diverse Erweiterungen, die ich primär aufgrund von praktischen Erfahrungen der Lungen-Schlaf-Praxis von Dr. Jürg Hamacher in Bern entwickelt habe.
Das Paket wird voraussichtlich unregelmässig aktualisiert und richtet sich allenfalls an Leute, die es selbst installieren und ggf. erforderliche Plugins dazulegen können.
Warnung: Diesem Paket liegt eine Entwicklerversion zugrunde - einigermassen aktuell, aber nicht notwendigerweise die letzte verfügbare, und auch nicht verlässlich fehlerfrei. Bevor ich selbst ein solches Paket in die von mir betreute Praxis gebe, mache ich Screenshots aller Einstellungen, aller Perspektiven und einiger als Referenzen dienenden Bildschirme. Dann prüfe ich auf einem Testsystem mit dem Datenbestand der Praxis, ob die bisherige und die neue Elexis-Fassung bei täglich vorkommenden Aufgaben identische und plausible Ergebnisse liefern. Danach mache ich (geprüfte!) Backups von Datenbestand und alter Installation, stelle dann die produktive Software um, und prüfe, ob Einstellungen und Funktionalität auch im produktiven System bewahrt wurden, bzw. stelle verlorene Einstellungen, Perspektiven etc. wieder her. Manchmal stelle ich auch erst einen Arbeitsplatz um und schaue einige Tage, ob sich die neue Fassung bewährt. Ein ähnliches Vorgehen würde ich auch anderen empfehlen.
Wichtigste Erweiterungen:
- Kontakte-Details, Patientenliste, und Patient-Details (wg. "Hinzu") enthalten neue Menüeinträge (View- oder Kontext-Menü) und Toolbar-Buttons. Damit kann man Daten aus markierten Einträgen (einer oder auch mehrere, je nach View) in zwei verschiedenen Formaten in die Zwischenablage kopieren - schön (!) und passend (!) formatiert für eine Anschrift im Brief, oder für Fliesstext.
- Kontakte-Details enthät neuen Menüeintrag (View-Menü) und Toolbar-Button zum Putzen der Datenbankinhalte für eine, mehrere oder alle markierte(n) Kontakt(n). Es entfernt u.a. einige überflüssige Leerzeichen, Tabs oder [Return]s, homogenisiert Titel, und sorgt dafür, dass jeder Patient auch als Person markiert ist. Wenn man alle Einträge bearbeiten will: einen anklicken, dann Ctrl-a tippen. Nach dem Putzen landen geänderte Einträge mit vorher/nacher in der Zwischenablage. Das kann man in Excel oder OpenOffice / LibreOffice Calc etc. einfügen und anschauen. Ich habe auch ein Tabellenblatt mit Makro, um Änderungen dann farbig zu markieren. Das Putzen dauert ein paar Sekunden auf i5 CPU, wenn ca. 2500 Kontakte ausgewählt waren.
- Verbesserte Abrechnung: Warnungen, wenn man Tarmed oder Medikamente-BAG Positionen zu 0.00 Franken verrechnet. Warnung und Weigerung, wenn man eine Rechnung erstellen will, während eine Konsultation aus dem Fall gar keine Verrechnungsposition. Warnung und Auswahldialog, wenn mindestens eine Verrechnungsposition zu 0.00 Franken enthalten ist. Warnung und automatische Korrektur on-the-fly, wenn eine Rechnung für einen Patienten erstellt wird, der nicht als Person markiert ist.
- [Bisschen robusterer Umgang mit Ergebnissen aus der Datenbankabfrage, die alte Bestellungen anzeigt.]
- Detail-Korrekturen in manchen Dialog-Texten.
- Robusteres Handling der Konfiguration zu automatisch erstellten sinnvollen Dateinamen für Temporärdateien von NOAText_jsl und Omnivore_js
- Direktes Drag & Drop von Omnivore_js heraus zu anderen Programmen, einschliesslich Thunderbird und Outlook.
- Rezepte und andere Text-Dokumente mit Tabellen ohne sichtbare Rahmenlinien.
- Nur mit NOAText_jsl ab Version 1.4.15: Verlässlicheres Speichern von Textdokumenten: beim Verlassen des zugehörigen View, nach festen und apdaptivem Zeitintervall, und nur, wenn tatsächlich Inhalte verändert wurden.
- ...
Kompiliertes Paket - Binary distribution
Zu Inhalt und Installation bitte die Hinweise unten beachten - auch wegen enthaltenen Plugins, verwendeter Datenbank etc.
Bei Interesse werde ich später wieder ein Paket mit Installer (aus Niklaus Gigers Build Umgebung) vorbereiten.
Aktuelle Fassung:
Warnung: Diese Version von Elexis erreicht volle Funktionalität wahrscheinlich nur mit dem mitgelieferten Text-Plugin NOAText_jsl ab Version 1.4.18. Alle anderen Textplugins müssten erweitert werden. Selbst wenn eines damit so ausschaut als würde es funktionieren: Bitte auf jeden Fall testen, ob eingegebene Änderungen im Text am Ende gespeichert werden - weil ich diesbezüglich im neuen Set von Elexis + NOAText_jsl ein aktives Status-Monitoring ergänzt habe, dessen Ergebnisse vor dem Speichern auch abgefragt werden.
Verbesserungen:
- Kurz: Alle Neuerungen bis NOAText_jsl 1.4.15 - in NOAText_jsl 1.4.18 jedoch mit hoffentlich brauchbarer Stabilität.
- Die "Buchführung" zur Nutzung von OpenOffice / LibreOffice ist jetzt aktiv. Dadurch werden Verbindungen zum Office Server nach Gebrauch wieder geschlossen. Wenn die letzte Verbindung geschlossen wurde, dann wird auch das laufende Office beendet - d.h. aus dem Speicher entfernt (Fortsetzung von NOAText_jsl 1.4.11).
- Auch wenn mehrere Instanzen von Elexis - oder andere Clients - das Office gleichzeitig benutzen, wird dies jetzt sauber behandelt.
- So lange nur die View einer Dokumentenart gleichzeitig benutzt wird (Briefe, AUF-Zeugnis, Rezeptblatt...), und kein anderer Office Client läuft (Office Schnellstarter, irgendein externes Dokument im Office Writer etc.), wird OpenOffice / LibreOffice zwischen zwei in Elexis bearbeiteten Dokumenten beendet und wieder neu gestartet.
- Wenn mehrere Views mit unterschiedlichen Dokumentenarten gleichzeitig offen sind (Briefe, AUF-Zeugnis, Rezeptblatt etc., aber auch z.B. Etikettendruck, während ein Brief offen ist) wird zumindest die für jedes Dokument verwendete Verbindung zum Office Server anfangs neu geöffnet, und nach Schliessen der zugehörigen View auch geschlossen.
- Dieses Verhalten sorgt dafür, dass man typischerweise immer wieder eine frische Office-Umgebung zum Arbeiten verwendet. Das kann jeweils ein ganz neu geladenes Office für jedes Dokument sein, oder zumindest immer wieder eine neue Verbindung dorthin. Alte Verbindungen zu Office sammeln sich (hoffentlich...) nicht mehr stetig an, und es bleibt auch kein zunehmend instabiler (und dank Memory Leak grösser...) werdendes Office unausweichlich im Speicher stehen.
- Im normalen Betrieb werden soffice.bin und soffice.exe spätestens dann aus dem Speicher entladen, wenn Elexis geschlossen wird - oder schon dann, wenn in Elexis die letzte View mit einem Office-Dokument geschlossen wird (und keine anderen korrekt arbeitenden Nutzer von Office mehr vorhanden sind). Zuvor überdauerte ein aus Elexis heraus geladenes Office regelmässig so lange, bis man es mit dem TaskManager abgeschossen oder den Rechner neu gestartet hat - das passiert jetzt allenfalls noch nach Fehlern.
- Rund um die Ausgabe von Rechnungen sind ein paar zusätzliche Informationen in Dialoge eingearbeitet worden (Hinweis zu anderen Druckerqueues, zu vielleicht begrenzten Bildschirmupdates während der Ausgabe, zur Folgenummer der verarbeiteten Rechnung in der anstehenen Liste). Aus technischen Gründen ist dort die Stabilität noch nicht so weit verfolgt wie in (hoffentlich) allen anderen Nutzungen von Office, aber auch dort (hoffentlich) schon verbessert. (Und weiteres ist sicher machbar.)
Dem automatischen Laden und (!) Entladen von Office kann man jetzt im Task-Manager (und sogar z.B. mit htop in Linux!) zuschauen. Sehr entspannend. Besonders, wenn man ein paar Jahre das Gegenteil als Steinchen auf dem Herzen hatte... :-)
Derzeitige Limitationen:
- Am wichtigsten - bitte ganz dringend beachten - das entscheidet zwischen "geht" und "geht nicht":
Jede View, die ein Office-Dokument eines Typs darstellt (Briefe, AUF-Zeugnis, Rezeptblatt, Befundblatt, Laborblatt, Rechnung etc.) darf insgesamt nur einmal in allen Perspektiven enthalten sein. Wenn eine solche View in zwei oder mehr Perspektiven eingebaut wird - z.B. die View "Briefe" in die Perspektive "Patientenübersicht/Konsultation" und auch in die Perspektive "Briefe" - dann wird das NOAText_jsl Plugin den ersten Brief problemlos bearbeiten - aber das direkte Laden des nächsten Briefes wird mit einem weissen Hintergrund in der View "Briefe" enden, und mit einem soffice.bin / soffice.exe, welches (wie früher) nicht mehr entladen wird. In diesem Fall ist dann das Schliessen der entsprechenden Views und das Abbrechen des stehengebliebenen Office Prozesses im TaskManager wieder notwendig.
Das Problem wird aber sofort sichtbar, ist sofort reproduzierbar, und kann durch Entfernen der entsprechenden "doppelten" Views sofort gelöst werden. (Jedenfalls aus technischer Sicht. Wenn man eine solche View unbedingt in mehreren Pespektiven benutzen will: Alternativ die View (zuverlässig!) in der einen Perspektive schliessen, bevor sie in der anderen geöffnet wird.)
Eine Datei mit Definition geeigneter Perspektiven liegt weiter unten. [...]
- Die ViewMenu-Einträge in TextView = Briefe erlauben im Moment nur deren einmalige Benutzung. Danach muss man die View schliessen und neu öffnen - um die Stabilität des Textplugins zu erhalten. Ich zähle mit und erlaube keine wiederholte Benutzung des Fensters - so ist dieser Aspekt "nur" etwas nervig (und vielleicht übervorsichtig).
- Warnung: Wenn ich damit ein neues Dokument erstellt und dieses als Vorlage gespeichert habe - hat das wohl immer funktioniert. Jedoch sind manche Versuche fehlgeschlagen, existierende Templates umzuarbeiten und unter neuem Namen zu speichern. Mehrfach hat ein "Speichern als Vorlage..." (ohne Warnung) kein nutzbares Dokument in der Datenbank erzeugt. (Das habe ich nicht systematisch getestet oder verfolgt, nur im Rahmen der ad-hoc-Erstellung von Druckvorlagen noch bei laufender Programmierarbeit gesehen - ich weiss auch noch nicht, ob es etwas mit den aktuellen Verbesserungen im Textplugin zu tun hat, oder mehr ein Problem der Umgebung ist.) Dennoch, deshalb bitte: Templates = Vorlagen mit einer anderen Version von Elexis bearbeiten, oder bitte (!) jedes Speichern eines Templates erst an einem anderen Elexis auf Erfolg kontrollieren, bevor das Fenster mit dem gerade bearbeiteten Template geschlossen wird!
(Das trifft zum Glück nach meinen Erfahrungen nur die Arbeit mit Templates. Ich vermute, dass ein spezieller Bug in der Gegend liegt.)
- Das Ausdrucken von Rechnungen benutzt ggf. für jede Rechnung dieselbe "View" mehrfach. Wegen Interna in Elexis und Textplugin ist diese Arbeitsweise weniger stabil. Ich habe versucht, sie so weit wie möglich abzusichern - Die Ausgabe von Tarmed-Rechnungen wurde getestet; am Ende sah es eher gut aus. Aber meine Zeit war erst sehr begrenzt; hier empfehle ich dringend jedem eigene Tests.
(Wenn es einmal fehlschlagen sollte, würde das aber wohl nur ein neues Aufstarten erfordern (von Elexis, ggf. Office im TaskManager abbrechen) und keinen Datenverlust zur Folge haben - da der Rechnungsdrucker ja nur bereits erstellte Dinge ausgibt. Also viel tiefere Priorität als Briefe, Rezepte, Etiketten etc.)
- Wenn ich nichts übersehen habe, wurden alle mir vorliegenden Teile von Elexis und Plugins reviewt, die Office Dokumente bearbeiten oder drucken. Ausnahmen: Nicht übersetzen konnte ich das Plugin für den Impfplan. Mit den beiden Plugins Privatrechnung und Privatrechnung2 habe ich selbst keinerlei Erfahrung - auch noch keine Druckvorlagen erstellt gehabt, und keine Zeit darauf verwendet.
(Wenn diese jedoch dasselbe Modul für den Ausdruck benutzen, wie die Ausgabe der Tarmed-Rechnungen, könnte es gleich gut (oder schlecht) funktionieren. Deshalb: "Your Mileage May Vary.")
- Soweit sinnvolle "sprechende" Temporärdateinamen aktiviert sind, werden auch die Namen von Druckaufträgen die Angaben zum aktuellen Patienten enthalten - selbst wenn gar kein Patientenbezug besteht (Listendruck etc.) - das ist eher ein Schönheitsfehler, sollte aber beim Druck in PDF-Dateien beachtet werden.
- Vollständig funktional habe ich es erst unter Windows gesehen (dort auch entwickelt, weil Jürg Hamacher das verwendet). In Linux habe ich es erst einmal angeschaut - es schien zwar technisch zu funktionieren - nur gab es keine sichtbare Anzeige des Office Dokuments im Fensterrahmen. Den Rahmen drum herum gab es schon, Office wurde auch gestartet, die Debug/Log-Meldungen waren - je nach Version einer Bibliotheksdatei - auch korrekt, sogar eine plausible Temporärdatei wurde erstellt, UND (!!!) das Entladen von Office funktionierte ebenfalls). Vielleicht muss ich nur noch die Bibliotheksdatei mit richtigem Inhalt bereitstellen - vielleicht fehlt auch noch mehr. [...]
- Ich bin unsicher, ob ich eine Instabilität gesehen habe, wenn in den Office "Optionen" - "Allgemein" - "Speichern" - "Druckeinstellungen mit dem Dokument laden" AUS-geschaltet war. Nicht sehr wahrscheinlich, aber möglich - bitte auch hier bei Bedarf selbst aufmerksam testen.
- Möglicherweise gibt es grosse log-Files. Weil mein zum Verstehen und Fehlersuchen gedachter umfangreicher Monitoring-Output durch neuere Logging-Plugins auch in die Logfiles umgeleitet wird.
- Der hier zugrundeliegende Stand von Elexis Opensource ist 2.1.7.dev-qualifier vom Mai 2013. Weil das Text-Plugin mich vollständig belegt hat, und manche von mir dorthinein eingebrachte Änderungen (für mich dann zu) schnell weiter bearbeitet wurden, habe ich neueres bei Niklaus noch nicht nachverfolgt.
- Die von mir gemachten Änderungen an Elexis im Zusammenhang mit dem Textplugin (siehe unten zu Version 1.4.15) sind nicht identisch mit den Änderungen, die Niklaus Giger selbst auf meinen entsprechenden Hinweis für Plugins mit separatem Textfenter gemacht hat. Die resultierenden Plugins und Elexis-Fassungen sind deshalb im Moment auch nicht miteinander kompatibel.
Deshalb gilt jetzt gerade: Niklaus' Elexis braucht Niklaus' Plugins, und "mein" Elexis braucht "meine" Plugins. Von "meinen" Plugins habe ich nur NOAText_jsl 1.4.15 auf 1.4.18 gepflegt. Andere alternative Textplugins habe ich zwar so mit Platzhalter-Methoden ergänzt, dass sie mit meinen Erweiterungen am umgebenden Elexis compiliert werden können - aber die eigentlich dazu gehörende Funtkionalität innerhalb dieser Plugins nicht ergänzt. Auch deren Funktionalität habe ich nach den Änderungen in Elexis nicht getestet.
An den Limitationen werd ich voraussichtlich noch arbeiten - und gerne auch mit Niklaus nochmals für die Integration der getrennt gemachten Entwicklungen schauen. Will aber Zeitpunkt und Ergebnis noch niemandem versprechen!
Download
Elexis_js 2.1.7.dev-qualifier-20131101js / compiliert am 01.11.2013: elexis-2.1.7.dev-qualifier-20131101js.zip
Bitte beachten Sie dringend die Hinweise zu "Limitationen" und "Installation" oben und unten.
Ein paar davon bestimmen, ob es am Ende brauchbar wird!
(Ich würde die Seite hier sonst nicht einfärben wie ein gelesenes Medizinerbuch...)
Hier eine Konfigurationsdatei mit definierten Perspektiven, die insgesamt jede View zum Editieren von Office-Dokumenten nur höchstens einmal enthalten: workbench.xml
Tatsächlich liegen diese Views bevorzugt in der Perspektive "Patientenübersicht/Konsultation". Die Perspektive "Briefe" ist hingegen leer. Dies wegen oben beschriebener Limitationen - und Jürg Hamachers Präferenz, der einen Wechsel der Perspektiven eher als Overhead empfindet.
Meistens habe ich eine Dreiteilung des Bildschirms (im Querformat) benutzt. Die Views sind so verteilt, dass links die grobe Auswahl erfolgt, rechts abgestuft die Zusatzinformationen. Views, die man oft gleichzeitig benötigt, sind einigermassen angenehm über die drei Spalten verteilt. Auf Konsistenz der Positionen über die Perspektiven hinweg wurde etwas geachtet - aber Perfektion beanspruchen die Layouts sicher nicht.
Die Datei geht typischerweise nach workspace/.metadata/.plugins/org.eclipse.ui.workbench/workbench.xml - entweder unterhalb des Installationsverzeichnis, oder an einem von Ihnen konfigurierten Ort. Der Ordner workspace wird nach dem ersten Start von Elexis erzeugt - dann bitte Elexis beenden, die alte Datei umbenennen, diese hier an deren Platz legen, Elexis wieder starten und schauen ob die Perspektiven brauchbar erscheinen.
Installation
Im Moment stelle ich ein ZIP-Archiv bereit und schlage einen Ort vor, wo dieses ausgepackt werden kann. Es enthät bestimmte von mir bevorzugte Plugins in plugins. Andere habe ich nach plugins-disabled verschoben - in der Hoffnung, die Startzeit zu verkürzen und die Oberfläche einfach zu halten. Falls meine Auswahl nicht gut ist, freue ich mich über jede hilfreiche Rückmeldung.
Auf einem Win 7 System (egal ob 32- oder 64-Bit) würde ich selbst das derzeit unter c:\Programme\elexis\bin\elexis-2.1.7.20131101\ auspacken; so dass der ganze enthaltene Ordner elexis im letztgenannten Ordner drin liegt.
Es ist zwar ein 32-Bit Programm (also vermutlich: was nicht ohnehin Java Bytecode ist...), aber ich erinnere mich, dass ein Pfad mit Leerzeichen manchmal gestört hat (bei einer frühen Fassung des Installers von Niklaus - inzwischen wohl behoben, aber Leerzeichen unter Windows vermeide ich ohnehin gern). Ich habe auch erlebt, dass dieser Pfad auf deutschem und amerikanischem Windows 7 mal innerhalb des c:\Programme Ordners von Windows erschienen ist, mal ausserhalb. Trotzdem habe ich ihn beibehalten, weil er schon auf zu vielen Rechnern verwendet war. Die Stufung der Unterverzeichnisse orientiert sich an der Vorgabe von Niklaus' Installer.
Cave: Windows/NTFS spielt nicht mehr ganz mit, wenn die Länge eines vollständigen Dateinamens mit Pfad eine (ziemlich tiefe) Grenze überschreitet. Wenn Elexis gestartet wird, entstehen ggf. weitere Unterordner, deren Inhalt dieser Grenze schon nahe kommt. Wer will, kann auch nach c:\elexis\bin\elexis-2.1.7.20131101\ installieren. Vielleicht vermeidet das erst noch allfällige Komplikationen mit dem "VirtualStore"...
Für dieses Archiv habe ich alle drei Datenbank-Anbindungen für mySQL, PostGres und H2 in plugins belassen. Sie können jedoch die beiden nicht benutzten ebenfalls nach plugins-disabled verschieben.
Ausserdem wollen Sie wahrscheinlich noch eine Verknüpfung im Startmenü oder auf dem Desktop auf das ausfürbare Programm elexis.exe anlegen. Vielleicht wollen Sie einen Parameter wie -data "%USERPROFILE%/elexis" angeben [...]
Bitte nach der Installation ggf. den Inhalt von elexis.ini anpassen. Ich hab die Entsprechung zu nl=de_CH dort drin.
Compiliert wurde obiger Code mit Sun/Oracle Java JDK 1.7.0_40 32-Bit; benutzt auch mit der aktuellen JRE 1.7.0_45 32-Bit. Früher habe ich auch die 64-Bit Java-Version probiert, aber (wenn ich mich recht erinnere) nur durchwachsene Ergebnisse erzielt.
Ich habe diese Version erst nur auf Win 7 64-Bit-Maschinen getestet; wenn sie weiterhin gut ausschaut, wird sie aber auch auf einen 32-Bit XP Rechner gehen. Die vorigen Versionen haben in beiden Umgebungen gleich gut funktioniert.
Aktuell empfehle ich die Verwendung von NOAText_jsl mit OpenOffice 3.2 oder 3.3 als Ergebnis der Stresstests (Details siehe oben). Es kann sein, dass NOAText_jsl 1.4.18 auch mit anderen Offices besser zusammenarbeitet als seine Vorgänger - weil es mit den Verbindungen besser haushalten und Office auch öfter entladen sollte - soweit der Nutzer das ermöglicht. Bevor jedoch neue Stabilitätstests mit verschiedenen Office-Versionen vorliegen, würde ich bei denen bleiben, die zuvor am stabilsten waren, und gleichzeitig die kleinsten Memory Leaks (schon ohne jede Nutzung) haben. Office 4.x Support ist auf Anfrage wohl möglich - braucht den Tausch weniger Bibliotheken - aber mit dieser Version noch nicht getestet.
Bitte kontrollieren Sie nach der Installation auch die Einstellungs-Seiten (mehrere!) fürs Textplugin.
Bitte auch vor dem Starten dieses Elexis dafür sorgen, dass kein alter OpenOffice / LibreOffice Prozess mehr läft (TaskManager oder Neustart). Und beim Bearbeiten der ersten Dokumente zuschauen, wann/wie soffice.bin und soffice.exe auch wieder entladen werden. Den Office Schnellstarter lieber weglassen - wenn das Ganze dann nicht viel zu langsam wird - der verhindert nämlich das vollständige Entladen. So lange in Elexis ein einziges weiteres Office-Dokument (z.B. Rezept, während des Briefeschreibens, oder irgendeines in einem parallel laufenden zweiten Elexis) offen bleibt, hat das ohnehin den selben Effekt.
Warnung: Ein gut gemachtes Update braucht Sachkunde und Ruhe. Vorher bitte gute, geprüfte Backups machen - einschliesslich Workspace, Dokumentation/Screenshots der Einstellungen, Perspektiven etc. - Eine Liste der Plugins in .../elexis/elexis-plugins drucken, damit nacher das gleiche Set wieder verwendet werden kann. Das vorhandene Elexis nur zur Seite legen, nicht löschen. Bei Upgrades von älteren Fassungen: Release Notes für 2.1.7 dringend lesen. Funktionen von altem und neuem Elexis am besten direkt vergleichen, das Neue dafür erst einmal auf einem separaten Test-Rechner ohne irgendeine Verbindung zum Netzwerk mit lokaler Kopie der Datenbank installieren.
Warnung: Bei Verwendung von Plugins aus Niklaus' Installer und auch aus einem separat bereitgestellten ZIP-Archiv: Manche Plugins unterscheiden sich nur durch Bindestrich vs. Unterstrich im Dateinamen - in dem Fall soll die zweite Fassung aus dem ZIP-Archiv nicht noch zusätzlich in den Ordner gelegt werden, welchen der Installer erzeugt hat!
Warnung: Sollte ich jemals ein Plugin ch.elexis.support.db-shaker*.jar im ZIP-Archiv vergessen, dann löschen Sie das bitte. Es dient zum Durchmischen der Datenbank, um daraus ein Test- oder Demo-System zu erzeugen. Es erscheint als "Bombe" im Toolbar - aber dieser Knopf sollte niemals in einer produktiven Umgebung zum Herumspielen einladen.
Im von mir betreuten produktiven System entferne ich nicht benötigte Plugins, da sie allenfalls Zeit beim Starten verbrauchen und die Komplexität unnötig erhöhen. Die hier bereitgestellten Plugins sind auch nicht notwendigerweise alle fertig entwickelt.
Ich gehe davon aus, dass die von Niklaus via elexis-bootstrap öffentlich im Quellcode und mit Build-Tools bereitgestellten Plugins unter der auch sonst in Elexis verwendeten Eclipse-Lizenz stehen und hier auch in kompilierter Form erscheinen dürfen. Andernfalls bitte ich um einen entsprechenden Hinweis.
In jedem Fall würde ich potentiellen Anwendern empfehlen, die über die Hilfe einsehbaren Autoren der Plugins vorher zu kontaktieren, wenn sie ein in ihrem System neues Plugin produktiv einsetzen möchten.
Empfohlene Stabilitätstests (fürs Textplugin)
Wenn Sie die Empfehlung in Bezug auf die Office Views befolgen, sollten Sie beliebig viele (in der Datenbank vorhandene, gültige) Office-Dokumente nacheinander erstellen, öffnen und bearbeiten können. Die letzten Änderungen an einem Dokument sollten auch nach dem Ablauf gespeichert werden, den ich auf der Elexis-Developer-Liste einmal als "Experiment" beschrieben habe. Ausserdem sollten die temporären Dokumente (wenn ich es nicht wieder ausgeschaltet habe...) alle paar Minuten automatisch zwischengespeichert werden.
Damit Sie ein Gefühl dafür bekommen, probieren einmal Sie folgende Sequenz:
Korrekt funktionierendes System:
- Installieren etwa wie oben beschrieben
- Rechner starten, einloggen
- TaskManager öffnen; Prozesse; schauen, dass soffice.bin und soffice.exe NICHT laufen.
- Patient auswählen
- Vorhandenen Brief öffnen - soffice.bin und soffice.exe erscheinen im TaskManager
- View mit dem Close-Button schliessen - soffice.bin und soffice.exe verschwinden aus dem TaskManager
- Wieder einen Brief öffnen - soffice.bin und soffice.exe erscheinen im TaskManager
- In der View Rezepte (!) ein Rezept zur Bearbeitung als weiteres Office-Dokument öffnen und nicht schliessen
- Den Brief schliessen - diesmal wird Office nicht entladen, weil das Rezept es noch verwendet
- Das Rezept schliessen - jetzt wird Office entladen
- Ein Etikett drucken - Office wird geladen, das Etikett gedruckt, Office wird entladen
- Vorhandenen Brief öffnen - soffice.bin und soffice.exe erscheinen im TaskManager
- Denselben Brief nochmals öffnen - oder einen anderen - diesmal: ohne (!!) zuvor erst die View "Briefe" zu schliessen - Auch das funktioniert; im TaskManager sieht man (es geht jedoch schnell), dass auch hierfür Office entladen und wieder neu geladen wird.
- In der View "Briefauswahl" den ersten Stresstest laufen lassen - dieser lädt wiederholt den ausgewählten Brief - Office sollte jedes Mal neu geladen und wieder entladen werden. Das Office-Fenster sollte das Dokument in jedem Zyklus anzeigen.
- In der View "Briefauswahl" den zweiten Stresstest laufen lassen - dieser lädt nacheinander alle Dokumente des ausgewählten Patienten - Office sollte jedes Mal neu geladen und wieder entladen werden. (Cave: Wenn ein Dokument nicht existiert, bricht der Test ab, Dialog und Platzhalterdokument mit Fehlermeldungen erscheinen. Das ist immer noch korrektes Verhalten, bei defektem Dokument in der Datenbank. Ich bin gerade nicht ganz sicher, ob Office auch danach wieder entladen wird, sobald man die View schliesst, es könnte (jedenfalls: sollte) aber so sein.)
- Eine weitere Instanz von Elexis starten
- Auch dort einen Patienten wählen
- Abwechselnd in beiden Elexissen Office-Dokumente öffnen: Wenn insgesamt das letzte geschlossen wird, wird Office auch entladen. So lange noch eines in irgendeinem der Elexisse offen ist, bleibt Office auch geladen.
- Die Stresstests in beiden Elexissen parallel laufen lassen: Selbst wenn der erste läft, reagiert das zweite Elexis noch prompt auf die Maus etc. - man kann den zweiten Stresstest genauso gut starten, wie wenn noch keiner laufen würde. Beide laufen gut parallel, man sieht weiterhin die Display-Updates nach jedem Zyklus.
- OO Writer ausserhalb von Elexis starten. Dokument bearbeiten. Speichern unter...
- Dokumente in Elexis laden und schliessen. Es sollte funktionieren; so lange der externe OO Writer ein Dokument enthät, sollte Office im TaskManger nie entladen werden (andernfalls würde dabei auch der Writer geschlossen).
- OO Writer ausserhalb von Elexis schliessen.
- Alle Office Views in Elexis schliessen - mit dem letzten Office-Client sollte Office auch im TaskManager sichtbar aus dem Speicher verschwinden.
Wenn Sie Spass am Abenteuer haben: drucken Sie Etiketten während des Stresstests. Ich weiss nicht mehr, ob ich es probiert habe, es könnte aber gehen. (Falls nicht: Bitte um Rückmeldung...) - Ich glaube, ich habe zumindest ein Rezept währenddessen geöffnet - weil ich mich erinnere, dass ich danach kurz angedacht hatte, noch einen weiteren Stresstest in die View "Rezepte" einzubauen - so dass zwei parallele Stresstest im selben Elexis laufen könnten...
Bitte schauen Sie dennoch aufmerksam, ob und wie weit der Rechnungsausdruck funktioniert - er arbeitet intern anders und kann durchaus noch "steckenbleiben" - und dann ein Office hinterlassen, das nicht mehr automatisch entladen wird.
Bitte lassen Sie auch beim Bearbeiten von Templates Vorsicht walten - Siehe Limitationen.
Bitte beachten Sie auch die Hinweise zur Einstellung der Optionen von Office, die ich schon früher hier oder anderswo gegeben habe. Fixierte Menüs, keine offenen Office-Dialoge (Formatvorlagen, Tabellen, etc.) helfen. - Diese mögleichen Problemquellen werden allerdings zumindest teilweise von NOAText_jsl bereits abgefangen. (Ich weiss noch nicht, ob dies nach den letzen Verbesserungen überhaupt noch notwendig wäre.)
Bekanntes Problem mit Office
Wenn man den externen OO Writer öffnet, das leere Dokument etwas bearbeitet, und nicht speichert, könnte das beim Schliessen des letzten anderen Office Clients (also auch von Elexis) zum Stillstand führen. Ich glaube mich zu erinnern, dass ich genau das einmal gesehen habe, und dass es ein bekannter Fehler in Office ist, der dazu führt (Externe Anfrage nach Schliessen bei nicht gespeicherten Änderungen -- falls das (unerwartet) auch nur innerhalb von Elexis beobachtet würde, müsste dort geprüft werden, ob ausreichend "close" und "isModified=false" statements vorhanden sind).
Unbrauchbar konfiguriertes System: Mindestens eine Office-View in mindestens zwei Perspektiven
Wenn man nur schon die View "Briefe" (TextView) in zwei Perspektiven eingebaut hat - und sie in beiden Perspektiven vorhanden, aber nach dem Programmstart noch leer ist - dann kann man in einer Perspektive einen Brief öffnen - das funktioniert - aber schon das nächste Öffnen eines Briefes in dieselbe View, ohne diese vorher zu schliessen, wird stehenbleiben.
Danach muss man beide betroffenen Views (oder Elexis) schliessen und ggf. Office im TaskManager abschiessen, um wieder ein konsistentes System zu bekommen. Bevor man weiterarbeitet: Bitte sicherstellen, dass diese View nur noch in einer einzigen Perspektive enthalten ist. Und die korrigierten Perspektiven dann auch speichern, und nochmals überprüfen. Und sicherstellen, dass keine andere Instanz von Elexis (auf dem gleichen Rechner oder von einem anderen Rechner) die Konfigurationsdatei später wieder auf den unbrauchbaren Zustand umschreibt!
Sichtbare Verbesserung gegenüber Vorgängern
Das Elexis 20130605js mit NOAText_jsl 1.4.13 hatte zwar keine (kurzfristig erkennbare) Schwierigkeit mit dem Vorhandensein derselben View in mehreren Perspektiven. Allerdings wurde das in NOA eigentlich vorhandene Monitoring der Office-Benuztung mit Beenden von Verbindungen und Entladen von Office nach Benutzung dort nicht benutzt - und ein ein korrektes Handling des Beendens von Office ist (nach automatischer Suche) nicht einmal in NOA enthalten.
Bei Elexis 20130605js mit NOAText_jsl 1.4.13 hätte man im Stresstest typischerweise nicht nach jedem Zyklus ein Display-Update sehen können - der Test wäre (je nach verwendeter Office-Version) zwar durchgelaufen, aber die Anzeige nur wenige Male am Anfang und dann erst wieder nach Ende des Tests aktualisiert worden.
Beim Stresstest in mehreren Instanzen von Elexis parallel hätten Maus und Tastatur nur wenig (gefühlte) freie Rechenzeit neben einem laufenden anderen Stresstest bekommen - man hätte den Mausbutton sehr lange halten müssen, um ein weiteres ViewMenu zu öffnen. Stetige parallele Updates der Displays in mehreren Instanzen von Elexis mit gleichzeitig laufendem Stresstest hätte man allenfalls mit Java im Server-Modus sehen können - wenn überhaupt.
Nach Stunden (Arzt) bis Tagen bis Wochen (Anmeldung) im normalen Betrieb hätte z.B. der Etikettendrucker nicht mehr reagiert, oder Briefe wären nicht mehr richtig bearbeitbar geladen worden etc., und ein Beenden von Elexis und Abschiessen von soffice.bin im TaskManager (oder ein Neustart des Rechners) wäre erforderlich gewesen, um mit dem System wieder arbeiten zu können.
Vorhergehende Fassungen:
Elexis_js 2.1.7.dev-qualifier-20130625.js / compiliert am 27.06.2013:
(mit NOAText_jsl 1.4.15: technisch grosse Verbesserungen; im Praxisbetrieb noch nicht brauchbar.)
Elexis_js 2.1.7.dev-qualifier.js / compiliert am 05.06.2013 (vor Änderung Interface/API Textplugin): elexis-2.1.7.20130605-installer.jar
Plugins von elexis-bootstrap für Elexis 2.1.7.dev-qualifier.js / compiliert am 13.04.2013: elexis-2.1.7.20130605-plugins.zip
(Enthät NOAText_jsl 1.4.13 und Omnivore_js 1.4.6 - diese liegen auch unten separat zum Download)
Elexis_js 2.1.7.dev-qualifier.js / compiliert am 13.04.2013: elexis-2.1.7.20130413-installer.jar
Plugins von elexis-bootstrap für Elexis 2.1.7.dev-qualifier.js / compiliert am 13.04.2013: elexis-2.1.7.20130413-plugins.zip
(Enthät NOAText_jsl und Omnivore_js - diese liegen auch unten separat zum Download)
Omnivore_js - Erweitertes Dokumentenarchiv
Status
Aktuell: Version 1.4.6 für Elexis 2.1.7.dev-qualifier-js oder 2.1.7.dev-qualifier-js-20130625
Funktion ist ok; der Konfigurationsdialoge ist noch nicht perfekt layoutet - das liegt aber vor allem daran, dass das zugrundeliegende PreferenceDialog Toolkit ziemlich müsam zu benutzen ist und auch nicht immer das tut, was seine Dokumentation verspricht...
(Weitere Funktionalität ist geplant, vor allem: Suche in aktuell vorhandene Feldern, Volltextindex, mehr Drag & Drop, Kontextmenü zu besserer Texteerkennung.)
Weitere Infos auch hier: https://github.com/elexis/doc_de/wiki/ch.elexis.omnivore
Inhalt / Hintergrund
Elexis bietet verschiedene Plugins zum Dokumentenarchiv. Omnivore, Omnivore plus, Omnivore direct, Global Inbox, Externe Dokumente.
In der von mir betreuten Praxis hat sich folgender Arbeitsablauf aus dem Einstieg mit Elexis 1.4 ergeben:
- Schnelle Scanner wandeln viel Papier in PDFs mit mässiger Texterkennung.
- Untersuchungsgeräte (mindestens: EKG, Lufu, BGA, LQ-Recorder für Fragebögen, Schlafdiagnostik) liefern weitere PDFs oder Word-Dokumente.
- Andere Quellen liefern diverse Dateiformate.
- Da die Quellen nicht alle den Patientennamen im Dateinamen haben, braucht es eine Vorschaumöglichkeit. Die gibt's am ehesten im Windows-Ordner.
- Nach dem Zuordnen zu Patienten und Annotieren in Omnivore sollen die Quelldateien auch noch in mehrere als Datei-Archiv fungierende Ordner auf dem Server versorgt werden. Ursprünglich war das eine Notreserve, weil wir nicht wussten, wie zuverlässig Elexis funktionieren würde. Heutzutage setzt nur dort ein Volltextindexer an.
- Am wichtigsten Rechner für den Datenimport hängen zwei Monitore, damit man den/die Quellordner rechts neben einem Elexis im Vollbildschirm sehen kann.
- Oft müssen Dokumente aus Omnivore auch wieder verschickt werden.
- An einem Arbeitsplatz läft Thunderbird, an einem anderen historisch bedingt MS Outlook.
Ich hab auch im Elexis Forum etwas dazu geschrieben, insb. zum Mailen. - Eine Alternative wäre vielleicht sowas wie Paperport, aber das wäre eben noch ein weiteres externes Programm, der Bezug zum aktuell in Elexis ausgewählten Patienten ginge wohl verloren etc. - Damit könnte man vermutlich schon mal keinen Dateinamen automatisch erzeugen, wie Omnivore_js 1.4.4 das jetzt kann (s.u.).
Neue Funktionalität
Omnivore_js 1.4.6
- Direktes Drag & Drop von Omnivore_js heraus zu anderen Programmen, einschliesslich Thunderbird und Outlook.
Omnivore_js 1.4.5
- Robusteres Handling der Konfiguration zu automatisch erstellten sinnvollen Dateinamen - verbotene Zeichen werden jetzt auch dann ignoriert, wen sie in die Felder für Füllzeichen oder Trennzeichen eingetragen wurden.
- Führender und nachfolgender Whitespace wird aus den Feldern "Titel" und "Stichworte" auch beim nachträglichen Bearbeiten entfernt, nicht nur beim Importieren.
Omnivore_js 1.4.4
- Konfigurierbare sinnvolle Dateinamen: Statt omni_12345678890123456_vore.pdf heisst es z.B.: Praxis_Hippokrates_000123_Muster_Max_01.02.1934_EKG vom 2012-03-08_1234567890.pdf
- Aktuell kann man in den Dateinamen bringen:
- Konstante 1
- Patientennummer
- Name
- Vorname
- Geburtsdatum
- Dokument Titel
- Dokument Schlüsselworte
- GUID
- Zufallszahl
- Konstante 2
- Für alle Elemente ausser den Konstanten ist einstellbar:
- Füllzeichen für führende Stellen (damit z.B. einen Patientennummer immer 5-stellig erscheint)
- maximale bzw. erwünschte Anzahl der Stellen
- nachfolgendes Trennzeichen
- Dabei werden Zeichen automatisch ausgefiltert, die für Dateinamen typischerweise unzulässig sind
- Ausgefiltert werden auch wahrscheinlich unerwünschte Überbleibsel wie ein alter noa1234567890.xyz oder omni_1234567890_vore.xyz Dateinamen, der vielleicht noch in einem der Dokumentenfelder drin steht, wenn einmal eine temporäre Datei wieder in das Archiv gelegt wurde.
- Wenn man gar nichts einstellt, wird der Dateinamen im alten Format erzeugt.
- Wenn man jetzt eine Datei aus Omnivore öffnet, die man danach per e-Mail versenden oder extern speichern will, spart man sich so das ansonsten immer erforderliche manuelle Erstellen eines informativen Dateinamens. Und wenn man die temporären Dateien im Dateisystem suchen muss (so lange sie nicht gelöscht sind, oder nach Speichern einer Kopie), hat man einen dafür brauchbaren Dateinamen.
- Und trotzdem kann man einen ziemlich sicher eindeutigen (GUID) und/oder zufälligen Teil im Dateinamen belassen.
- Schliesslich kann man mit den Konstanten die eigene Praxis, einen Mitarbeiter als Absender mit Namen oder Initialen oder einen anderen Marker einbauen.
- Derselbe Mechanismus wird benutzt, wenn man Dateinamen mit der neuen Drag & Drop Funktion z.B. direkt aus Omnivore_js in einen e-Mail-Anhang zieht.
- Sollte jemand Bedarf an weiteren Feldern oder Funktionen haben, kann ich das nun auch relativ einfach realisieren.
- (Änliche Funktionalität will ich alsbald auch dem Noatext_jsl beibringen.)
- [N.B.: Mit Thunderbird kann man mehrere Attachments bequem aus Elexis in eine aus Libre- oder OpenOffice heraus erstellte Mail mit Arztbrief im Anhang hineinbringen. Mit Outlook scheint das jedoch nicht so leicht zu gehen - so lange die von LibreOffice oder Omnivore aus erstellte neue Mail offen und noch nicht versendet (oder im Drafts-Folder und geschlossen) ist, kann man anscheinend kein zweites Fenster mit einer weiteren Mail erzeugen.]
Omnivore_js 1.4.3
- Neuer Konfigurationsdialog in: "Einstellungen" - "Datenaustausch" - "Omnivore_js..." in 4 Sprachen.
- Regelbasiertes automatisches Weg-Archivieren von importierten Dateien. Man kann z.B. erreichen,...
- dass Arztbriefe, die aus dem Ordner eingang/arztbriefe hereinkommen, nach dem Import automatisch in den Ordner archiv/arztbriefe geschoben werden
- und dass sonstige Dokumente, die von eingang (mit beliebigen Unterordnern) hereinkommen, nach archiv/importiert geschoben werden.
- Das ganze erspart dem Anwender das endgütige Verschieben oder Löschen der importierten Datei.
- Und trotzdem behät man (im Gegensatz zur "Global Inbox") die komplette Funktionalität der Windows-Ordner als Quelle des Imports. Insbesondere mit Vorschau, mehreren Quellordnern und Zielordnern gleichzeitig etc.
- Weiteres dazu (u.a. Tips und Limitationen zur Erstellung der Regeln) schreibe ich gerne, wenn ich Zeit finde oder Anfragen dazu von Interessierten erhalte :-).
Kompiliertes Paket - Binary distribution
Omnivore_js 1.4.6 für Elexis 2.1.x / compiliert am 27.06.2013: ch.elexis.omnivore-1.4.6.20130627.jar
Installation des Plugins wie weiter unten für andere Plugins beschrieben.
NOAText_jsl - Ein TextPlugin mit verbesserter Stabilität, kompatibel (mindestens) bis LibreOffice 3.6.
Status
In der Entwicklung: Version 1.4.11, 2013-04-xx.
Aktuell: Version 1.4.18, 2013-11-01, kompiliert am 2013-11-01 - nur für Elexis_js 2.1.7.dev-qualifier-js-20131101.
Nicht verwenden: Version 1.4.15, 2013-06-25, kompiliert am 2013-06-25 - nur für Elexis_js 2.1.7.dev-qualifier-js-20130625.
Aktuell: Version 1.4.13, 2013-06-xx, kompiliert am 2013-06-xx - für frühere Versionen von Elexis bis Elexis_js 2.1.7.dev-qualifier-js-20130605
Ein Update mindestens auf Version 1.4.6 würde ich für Anwender früherer Versionen empfehlen - Begründung unten.
Status: Beta.
Keinerlei Gewährleistung! Verwendung auf eigene Verantwortung!
Sachkundiger Anwender, eigene Funktionstests in unkritischer Umgebung und gute Backups empfohlen!
Was fehlt: Die "Was fehlt:" Sektion und die weiteren Beschreibungen hier brauchen ein Update. (Ziemlich) vollständige Stabilität könnte mit 1.4.10 erreicht sein, dazu fehlt jedoch noch eine längere Erprobung - ein synthetischer Test - wohl der erste für Elexis Textplugins geschriebene - legt es aber nahe. (Alte todos: Dafür brächte es ein weiteres Code Review in LibreOffice/OpenOffice hinein - teilweise hab ich es schon gemacht. Nur Prüfen: Kann der Watchdog wiederholt erscheinen, wenn wiederholt richtig Grund dafüer; besteht - i.e. wird die Variable bei komplett neuem Zyklus resettet, die ein mehrfaches Erscheinen des Dialogs in *einem* besonders langen Aufruf-Delay verhindern soll? - Die Meldung, die beim Ablaufen des Watchdog-Timers erscheint, kann ggf. gekürzt werden. Weiteres Aufrämen des Codes (Kommentare und Monitoring output). Übersetzung bestimmter Ausgaben. Vollständige Linux-Kompatibilität mit Office Fenster als Frame in Elexis. Klärung des Lizenzstatus. Nochmaliges Update. Weitere Felder für die sinnvollen Namen für temporäre Dateien - wie auch für Omnivore_js 1.4.x realisiert. Ggf. konfigurierbare Verwendung des *.doc Formats. Aufbereitung und Bereitstellung der Dokumentation zu empfohlenen Einstellungen und Arbeitsweisen mit LibreOffice (intern vorhanden).)
Version 1.4.18: Die Neuerungen sind oben im Abschnitt Elexis_js beschrieben - Kurzfassung: Version 1.4.15 plus hoffentlich brauchbare Stabilität.
- Version 1.4.15 stellte sich schon am ersten Tag in der Praxis als (unerwartet) instabil heraus - ohne dass die Ursache sogleich erkennbar war. Deshalb habe ich den Code von Teilen des Plugins und der Aufrufe von Elexis noch einmal umfassender reviewt als zuvor. Zum Ergebnis zunächst lediglich oben bei Elexis_js etwas mehr.
- Insbesondere greift diese Fassung auch den mit 1.4.11 zunächst zur Seite gelegten Punkt des Monitorings der Office-Service-Nutzung wieder auf und schliesst ihn ab - ergänzt um korrektes (Nicht-)Schliessen des Office-Servers bei mehreren parallel laufenden Clients.
- Der Probebetrieb auf einem ersten Rechner bei Jürg Hamacher läft seit einigen Tagen gut. Dringende Voraussetzung ist im Moment noch, dass jede View mit Office-Dokument als Inhalt innerhalb einer Elexis-Instanz nur einmal gleichzeitig in allen (!) Perspektiven benutzt wird. Egal, ob sie gerade mit Inhalt gefüllt ist, oder nicht.
- Bitte ebenfalls die weiteren oben genannten Limitationen beachten - insbesondere zum Bearbeiten von Templates und zu der Rechnungsausgabe!
Version 1.4.15: Nutzung des in Elexis 2.1.7.dev-qualifier-js-20130625 ergänzten Status-Monitors. Damit wird für die Dokument-Arten Brief, RezeptBlatt, AUFZeugnis, Bestellung, LaborblattView, folgendes realisiert:
- Bisher: Die "View" mit dem jeweiligen Office-Dokument wurde nicht mehr zuverlässig aktiviert, nachdem man zwischenzeitlich auf andere Elemente von Elexis geklickt und anschliessend zum Weiterschreiben wieder mitten in den Text geklickt hatte (es sei denn, der Nutzer klickte auf das zugehörige Tab oder öffnete ein Dialog-Fenster in der Office-Applikation, also z.B. zum Drucken etc.).
In der Folge erfolgte trotz weiterer Änderungen das eigentlich vorgesehene Speichern nicht, wenn diese View das nächste Mal wieder verlassen wurde.
Somit konnten beliebig umfangreiche Änderungen verlorengehen.
Jetzt ist das korrigiert: die Office-View wird wieder aktiviert, somit erfolgt beim späteren Verlassen auch zuverlässig ein Speichern.
- Ausserdem habe ich ein regelmässiges automatisches Speichern ergänzt: Zum einen nach fixen maximalen Zeitintervallen; zum anderen auch abgestuft nach kürzeren Intervallen - so dass möglichst bald gespeichert wird, der Nutzer jedoch auch möglichst wenig beim Schreiben unterbrochen wird.
- NOAText_jsl 1.4.15 erfordert Elexis 2.1.7.dev-qualifier-js-20130625 (oder neuer) mit spezifisch zu diesem Plugin passenden Erweiterungen von mir. Ein aktuelles Medelexis reicht dafür nicht.
Version 1.4.13:
- Die Rahmenlinien erzeugter Tabellen werden unsichtbar gesetzt. Somit erscheint vor allem ein Rezept ohne sichtbare Rahmenlinien - allerdings nun auch alle anderen Ausgaben in Tabellenform.
- Nochmals erweiterte Monitoring-Ausgaben: Druckformatvorlagen.
Version 1.4.12:
- Grössere Robustheit der automatisch erzeugten Dateinamen gegen verbotene Zeichen in den Konfigurationseinstellungen, auch für die Füll- und Trennzeichen.
- Verändertes Handling von CRLF am bei Übernahme von Text aus Datenfeldern, z.B. "Patient-Detail" - "Diagnosen" etc. oder "Konsultation".
Nun kann kann man Text wiederholt automatisch aus einem Datenfeld in einen Brief übernehmen lassen, und von dort wieder per copy-paste in das Datenfeld einfügen - enthaltene Umbrüche überstehen das jetzt weitgehend.
Lediglich bei Mehrfachumbrüchen habe ich das alte Verhalten (reduzieren) beibehalten, um mit meinen eigenen aktuellen Druckvorlagen kompatibel zu bleiben, welche relativ aufwendig aufeinander folgende Adress-Einträge mit wohldefinierter Anzahl Leerzeilen generieren.
Version 1.4.11: In statu nascendi - vorläufig zur Seite gelegt: (siehe auch: 1.4.18)
- Noatext führt intern eine Liste der geöffneten Office-Dokumente. Sind alle zu, würde es den Office-Server wieder beenden und beim nächsten Dokument frisch starten. Gut gegen Memory Leaks und damit nach den letzten Befunden auch sehr empfehlenswert für Benutzer von OpenOffice, LibreOffice etc. :-) Nur leider hat dieses Feature nicht funktioniert: Office wurde nie beendet. Warum? Weil die Einträge aus der Liste der offenen Frames nie gelöscht wurden. [...] In 1.4.11 habe ich das korrigiert. Danach sehe ich, dass Office korrekt wieder entladen und später wieder eine neue Verbindung hergestellt wird. Aber nur etwa 2-3 x, dann ist das zu Ende. Und beim parallelen Stabilitätstest performt die erste Instanz gut, die zweite gibt entweder gleich auf, oder sie liefert die Dokumente in einem eigenen Window aus statt in einem Frame in Elexis.
- Deshalb: Work in progress :-)
- Hier sind auch zwei bereits zum Ende von 1.4.10 notierte Fehler korrigiert: Beschriftung der Einstellungen und - ein weiterer Mechanismus zum Erzeugen der Temp-Datei, welcher offenbar vor Urzeiten aus den Beispielen des NOA-Pakets übernommen wurde - und allerdings für scalc Dokumente gedacht war. Das war verantwortlich für die gelegentlich zu sehenden *.ods Dokumente im temporären Ordner mit auch sonst abweichendem Namensschema, die das Plugin auch nicht weiter verwenden konnte [...]
Version 1.4.10: Nun habe ich Stresstests in der Elexis View Briefauswahl entwickelt, die dieses Plugin besteht. Dazu folgende Infos:
- Stresstest 1 simuliert das wiederholte Laden eines ausgewaehlten Dokuments des aktuell gewaehlten Patienten.
- Stresstest 2 simuliert das fortlaufende Laden aller Dokumente des aktuell gewaehlten Patienten.
- Die Zahl der Ladezyklen ist derzeit noch im Code fest einprogrammiert, ich habe zwischen 10 und 1001 benutzt.
- Mit Noatext_jsl 1.4.10 und LibreOffice 3.6.6.2 schafft eine einzelne Elexis-Instanz ca. 364 bis 464 Zyklen, mit LibreOffice 4.0.2 (braucht andere Bibliotheken, geht ein wenig schneller, sonst funktional identisch, Bereitstellung auf Anfrage) ca. 580 Zyklen, dann bleibt es jeweils stehen. LibreOffice hat ein riesiges Speicherleck (Memory Leak) - mit jedem Öffnen und Schliessen eines Dokuments werden ca. 1 bis 2 MB RAM zusätzlich belegt. Das passiert auch, wenn man ein leeres Dokument ausserhalb von Elexis damit bearbeitet. Wenn LibreOffice dann stehenbleibt, hat es ca. 1 GB Speicher belegt, ausgehend von einem Startwert um knapp 30 MB. Hmm.
- Wenn man mehrere Elexis Instanzen parallel startet (direkt aus Eclipse heraus), dann scheitert LibreOffice schon mit zwei Instanzen nach wenigen Dokumenten (vielleicht war das schon nach dem ersten geöffneten in der zweiten Elexis-Instanz.)
- Mit Noatext_jsl 1.4.10 und ApacheOpenOffice 3.4.1 schafft eine einzelne Elexis-Instanz 1001 (und damit alle bisher vorgegebenen) Zyklen. Auch AOO 3.4.1 hat ein Speicherleck, aber das bewegt sich bei 64 KB bis 80 KB pro geöffnetem Dokument und ist somit eher vertretbar. Auch hier liegt der Augangswert knapp unter 30 MB; am Ende werden aber nur ca. 75 MB erreicht.
- ApacheOpenOffice 3.4.1 konnte auch in 4 parallel laufenden Elexis-Instanzen jeweils 500 Zyklen (gleichzeitig, ohne Pausen) absolvieren. Mehr habe ich nicht probiert.
- WARNUNG: Bei meinem ersten Installationsversuch hat AOO 3.4.1 bereits bei der Installation einen Bluescreen geliefert. Beim zweiten Versuch wurde die Installation fertiggestellt, aber der erste Versuch, ein Dokument (mit sehr vielen Formularfeldern, also keine Hausmannskost) zu öffnen, hat wieder einen Bluescreen prodziert. Auf Windows 7 Professional 64-Bit. Ich dachte, dass ein Betriebssystem solche Scherze heutzutage verhindern sollte, aber sei's drum. - Eine Recherche hat darauf hingedeutet, dass das Online-Update Modul schuld sein könnte - mir hat die Erfahrung jedenfalls gereicht, um das sofort wieder zu deinstallieren und es ein paar Monate wegzulegen. Trotz dieses Problems und der vielen Nutzerkommentare im Web sehe ich heute immer noch Version 3.4.1 als aktuell. Nachdem ich zu "LibreOffice Memory Leak" ebenfalls Bug-Tracker-Eintraege gefunden habe, die bis in die Zeiten von StarOffice selig zurueckreichen, und "standard procedure is to restart the application after some time" - hab ich eben doch nochmal das ApacheOpenOffice 3.4.1 installiert, und zwar ausschliesslich den Writer ohne Zubehör (später dann auch noch mehr, aber weder Online-Update noch Schnellstarter). Letztlich habe ich dann die genannte gute Performance im Stresstest von Elexis aus gesehen. Nach einigen weiteren Tests habe ich es in der von mir betreuten Praxis auf mehreren Plätzen installiert, jedoch nicht auf dem Server. Im Rahmen der remote durchgeführten Installation (nach Ende einer Menge Tests auf meinem Laptop) gab es einen weiteren Bluescreen - vermutlich auf meinem Laptop (!) - als ich remote einen Konfigurationsdialog aufgerufen habe. Danach konnte ich auf mehreren Rechnern remote AOO 3.4.1 einrichten, Elexis darauf umstellen, und AOO 3.4.1 auch noch konfigurieren. Jeder einzelne dieser Rechner ist beim ersten Aufruf des Tools - Customize (Anpassen) Dialogs abgestürzt, bootete automatisch neu, und war erst eine Minute später wieder erreichbar. Ich finde, dass Microsoft und die verschiedenen OpenOffice Anbieter (IBM will sich ja bei ApacheOpenOffice engagieren) das zum Anlass nehmen könnten, einmal eine gemeinsame Tasse Tee (Kaffee ist wohl schon genug im Spiel...) zu trinken. Die Einstellungen (Customize/Anpassen) und meine initialen Tests wurden natürlich als Benutzer ausgeführt, nicht als Administrator.
- Ich habe noch eine Reihe weiterer Offices getestet, auch OO 3.3, 3.2 und das - in diesem Zusammenhang unbrauchbare, weil intern anders aufgebaute - Lotus Notes. Allerdings nur kurz und teilweise, da die alten Versionen erst einmal unnötig schwer verfügbar sind und ich weitere Arbeiten zu erledigen hatte. Definitive Ergebnisse dazu deshalb später. Andere Anwender berichten auch davon, dass sie AOO 3.4.1 installiert hatten und wieder auf tiefere Versionen zurückgegangen sind.
- Aktuell empfehle ich die Verwendung von OpenOffice 3.2 oder 3.3.
- Wer sich irgendeine Kombination aus Plugin und Office-Paket installiert, die ohne weitere Bedienschritte auskommt, kann den Stresstest selbst benutzen, um die Stabilität seines Setups zu beurteilen. Ich denke, das ist eine essentielle Verbesserung.
- Siehe jedoch noch die Hinweise zu 1.4.11.
Damit ist jedenfalls noatext_jsl 1.4.10 derzeit das empfohlene Plugin. (Zwei noch ausstehende Mini-Text-Korrekturen im Detail - siehe auch vorläufige Infos zu 1.4.11)
Version 1.4.9: Vorläufige sinnvolle Namen für Temporärdateien - noch nicht konfigurierbar - nach dem Muster: noa_PatNummer_Vorname_Nachname_Geburtsdatum_Random.odt - Das erlaubt bereits ein direktes Versenden per e-Mail aus LibreOffice, als *.odt, *.doc oder *.pdf, wobei das automatisch erzeugte Attachment dann ohne manuelle Nacharbeit einen aussagekräftigen Dateinamen hat. [N.B.: Mit Thunderbird kann man mehrere Attachments bequem aus Elexis in eine Mail hineinbringen. Mit Outlook scheint das jedoch nicht so leicht zu gehen - so lange die von LibreOffice oder Omnivore aus erstellte neue Mail offen und noch nicht versendet (oder im Drafts-Folder und geschlossen) ist, kann man anscheinend kein zweites Fenster mit einer weiteren Mail erzeugen.]
Version 1.4.8: Einbindung der jüngsten Versionen der von noa-libre und bei LibreOffice 3.6.5.2 mitgelieferten Bibliotheken. Neu: In den Einstellungen konfigurierbare Grenzwerte für zwei unterschiedliche Schleifen im Interface zwischen Elexis und LibreOffice. Nochmals erweiterte und systematisierte Monitoring-Ausgaben, jetzt bis in eine erste Interface-Bibliothek von LibreOffice hinein. Teilweise verbesserte Linux-Kompatibilität, jedoch erscheinen dort Office-Fenster immer noch als völlig separate Fenstern, und nicht als Frame innerhalb von Elexis. Test bis LibreOffice 3.6.6.2.
Test bis LibreOffice 3.6.5.2. Für LibreOffice 4.x wäre wiederum ein Upgrade der Bibliotheken notwendig. Weil sowohl ApacheOpenOffice 3.4.1 als auch das erste LibreOffice 4.x - unabhängig von Elexis! - mir unter Windows 7 64-Bit schon nur bei der Installation oder direkt danach Bluescreens produziert haben, hab ich die Arbeit damit erst einmal zurückgestellt.
Version 1.4.7: Auf Wunsch eines Anwenders erstellte Fassung mit verkürzten Watchdog-Timeouts.
Version 1.4.6 ist bei Jürg Hamacher unter Windows seit einer Woche mit LibreOffice 3.6.2.2 im Einsatz und scheint bisher stabil zu funktionieren. (Unter Linux ist sie wie 1.4.5 vermutlich noch nicht verwendbar.)
Version 1.4.5 hatte laut mehreren Anwendern eine deutliche Verbesserung ergeben. Jedoch fand insbesondere Peter Schoenbucher eher eine Verschlechterung gegenüber dem von ihm zuvor benutzten Plugin (mit älterem Office-Paket). Bei Jürg Hamacher war es zwar drastisch besser, als das zuvor verfügbare freie Plugin, aber nicht perfekt stabil. Unter Linux im Kurztest noch nicht brauchbar.
Version 1.4.5 habe ich selbst getestet unter Windows 7 64-Bit und Windows XP 32-Bit, in Elexis 2.1.6.js, und in einer gemeinsam mit Niklaus Giger aus seinem elexis-bootstrap heraus am 25.05.2012 erzeugten Fassung von Elexis 2.1. Zumeist habe ich Libre Office 3.3.4 verwendet, einmal auch OpenOffice 2.0.3. Überprüft habe ich jeweils das Anzeigen und Ändern bestehender Briefe, Rezepte etc., auch mit abwechselndem Bearbeiten mehrerer Dokumente eines Patienten, auch bei gleichzeitiger Verwendung von zwei Instanzen von Elexis, sowie das Erstellen neuer Briefe und Rezepte. Unter Windows XP/32 jedoch mit weniger Tests als unter Windows 7/64.
Version 1.4.2 des Plugins wurde von mir getestet mit einer Custom-Version 2.1.6.js von Elexis, basierend auf 2.1.6.dev, sowie von einem Kollegen mit einer im Abonnement bezogenen Version 2.x. Sie war seit 2012-03 in zwei Installationen im Einsatz. Offenbar war sie deutlich stabiler als zuvor verfügbare Plugins. Ausserdem war sie bereits zu neueren Versionen von OpenOffice und LibreOffice kompatibel.
Wenn Sie über Updates oder Erfahrungen anderer Tester informiert werden möchten, können Sie mir auch gerne eine entsprechende Nachricht senden. Über Rückmeldungen vom Ausprobieren freue ich mich auch.
Niklaus Giger hat das Paket in seine Referenz-Build-Umgebung eingebunden; möglicherweise ist dort aber nicht immer die neueste Version dabei.
Hintergrund
Ein Text-Plugin realisiert die Verbindung zwischen Elexis und einer Software, mit der z.B. Arztbriefe oder Rezepte geschrieben werden. Elexis bietet eine Auswahl an Plugins; diese variiert nach verwendetem Betriebssystem und Bezugsquelle der Elexis-Distribution.
In diesem Abschnitt bezeichnet der Ausdruck "Office" die Office-Programm-Suiten OpenOffice oder LibreOffice.
Bisherige Situation
Das für Elexis unter Windows frei verfügbare Plugin noatext unterstützte OpenOffice (nur) bis Version 2.0.3.
Sowohl bei diesem, als wohl auch bei einem im Abonnement von Medelexis angebotenen Plugin war die Stabilität nicht ausreichend.
Mit dem freien Plugin führten bestimmte Aktionen zum Stehenbleiben des gesamten Programms Elexis. Eine gute Konfiguration und eine disziplinierte Anwendung des Office-Pakets konnten das Problem lindern, allerdings trat es im praktischen Einsatz dennoch zu häufig auf. Dann war mindestens ein Abbrechen von soffice.exe, oder auch ein Abbrechen und Neustarten von Elexis erforderlich.
Nach der Umstellung von Elexis 1.4.1 auf 2.1.6.js wurden die Adressetiketten nicht mehr direkt aus Elexis, sondern ebenfalls über OpenOffice 2.0.3 gedruckt. Dadurch wurde diese Funktion sehr unzuverlässig und eine Verbesserung unabdingbar.
Verbesserungen
Schon vor dem Anwendertreffen 2011 hatte ich Updates für die Bibliotheken gefunden, auf denen NOA-Text aufgebaut war. Wegen der Instabilität, der Beschränkung auf OpenOffice 2.0.3 und im Hinblick auf Fragen nach einem Plugin für Microsoft Office, habe ich alle frei verfügbaren Text-Plugins für Elexis studiert. Schliesslich habe ich ausgehend vom NOA-Text Plugin verbesserte Fassungen erstellt:
- Verbesserungen in 1.4.18 siehe vorläufig nur oben unter Elexis_js.
- In einer früheren Entwicklungsumgebung: Ein selbst unter Windows compiliertes NOA-Text hatte nicht funktioniert. Fehlersuche, dann Korrektur der Anzahl verwendeter Backslashes in einem Code-Abschnitt, der nur unter Windows übersetzt wird. Bericht im Elexis-Forum. Später Abgleich mit einer ähnlichen, dann auch in noa/noa4e und noa-libre eingepflegten Korrektur.
- Update der in NOA-Text verwendeten Teile von noa/noa4e erst auf die letzte von der IOn AG bereitgestellte Version 2.2.3/2.0.14, dann auf noa-libre (Stand März 2012). Dies entspricht dem Austausch beinahe des gesamten Plugins - erfordert allerdings nur Teile aus noa/noa4e.
- Untersuchung der Abläufe innerhalb des Plugins. Hierfür Ergänzung von Debug- und Monitoring-Meldungen sowie Kommentaren im Code.
- Anpassung einiger Dateien des Updates an Erfordernisse von Elexis - und zwar ausschliesslich aufgrund der Ergebnisse des eigenen Debugging. Anschliessend Verifikation meiner Änderungen durch Vergleich mit den von Gerry Weirich seinerzeit in entsprechenden Dateien gemachten Änderungen.
- Update weiterer Bibliotheken, die im Plugin als Objektcode eingebunden waren.
- Auswertung eigener Erfahrungen und Recherche in Anwenderforen zu möglichen Umständen und Abhilfen des Stehenbleibens.
- Beschreiben mehrerer Szenarien, mit denen das Stehenbleiben gezielt ausgelöst werden kann:
- Unter alten OpenOffice Versionen z.B. beim Öffnen von Dialogen zur Dateiverwaltung, sofern nicht die in OpenOffice eingebauten Dialoge aktiviert sind.
- Unter alten und neuen OpenOffice / LibreOffice Versionen, wenn bestimmte Dialoge offen oder Toolbars nicht angedockt sind, das Programm in diesem Zustand beendet wird, und nachfolgend wieder innerhalb von Elexis via NOA-Text geöffnet werden soll.
- An kritischen Stellen Ergänzung des Codes der NOA Bibliotheken, hierzu Aufrufe in weitere neu eingebundene Bibliotheken:
- Ausblenden von Menü-Optionen, die für Anwender von Elexis voraussichtlich nicht nützlich sind, aber das Potential haben, störende Dialoge zu öffnen. Die verfügbaren Kommandos wurden getestet und die letztlich verbliebenen individuell ausgewählt.
- Automatisches Schliessen störender Dialoge oder docken ungedockter Toolbars, soweit möglich. Die verfügbaren Kommandos wurden getestet und die letztlich verbliebenen individuell ausgewählt.
- Einbau eines Watchdog-Timers: Wenn der Versuch, ein Dokument aus Elexis via noa zu öffnen stehenbleibt, wird:
- bis Version 1.4.5: nach einer bestimmten Zeit ein Unterbruch ausgelöst. Die Entscheidung für diesen Versuch erfolgte nach einigem Studium der Abläufe als educated guess. Nach empirischer Prüfung läuft das Programm anschliessend wie erwartet weiter; der Anwender sieht dann lediglich eine Verzögerung statt des kompletten Stehenbleibens seiner Praxissoftware.
- ab Version 1.4.6: ein Dialog mit einem Hinweis angezeigt. Mit diesem kann das Stehenbleiben der Praxissoftware ohne Nebenwirkungen unterbrochen werden.
- Ergänzungen bzw. Korrekturen enthaltener Hinweise zum Copyright und zur Lizenz. Die verbesserte Version stelle ich zunächst unter der GPL bereit. Dies ist vermutlich adäquat, da die NOA Bibliotheken Teile aus YaBS verwenden, welches seinerseits unter der GPL veröffentlicht wurde; soweit ich sehen kann, enthält die ursprüngliche Datei NOAText.java auch Code, der direkt aus den NOA Bibliotheken oder Anwendungsbeispielen kopiert wurde. Da diese mindestens unter LGPL stehen, hätte das Ziel vermutlich nur unter GPL, oder allenfalls noch unter der LGPL veröffentlicht werden können.
- Version 1.4.3 funktionierte nur, wenn auch ag.ion.noa-2.2.3.jar im Ordner plugins lag. Das ist nicht mehr notwendig.
- Das Plugin erscheint nun als com.jsigle.noatext_jsl statt wie bisher als ch.elexis.noatext_jsl.
- Nach Rückmeldungen von Anwendern:
- Review des Verhaltens der Version 1.4.5 beim Unterbruch des Stehenbleibens.
- Zunächst über zwei Stunden erfolgloser Versuch, einen Fehler durch normale Verwendung des Plugins zu provozieren, bei bis zu 6 Instanzen von Elexis, LibreOffice 3.6.2.2, 3.5.6 und 3.3.4.
- Schliesslich reproduzierbares provozieren der gelegentlich beobachteten Fehlermeldung "Es ist keine Rechnungsvorlage definiert." - allerdings erst mit einem Testdokument, das mit LibreOffice etwa 5 Minuten zum Öffnen braucht (weiteres dazu unten). Das modelliert eine andere Situation, als das mit dem Watchdog ursprünglich behandelte Problem des zeitlich unbegrenzten Stehenbleibens nach offengebliebenen Toolbars oder Dialogen: Nun wird der Watchdog unerwünscht aktiv, obwohl technisch ein regulärer, nur sehr lange dauernder, Ablauf vorliegt.
- An diesem Modell Untersuchung der Folgen des Handlings des Unterbruchs (was ich für 1.4.5 auch schon als offenes ToDo angegeben und weiter unten auch begründet hatte): Das Signal destroy() an den stehengebliebenen Thread konnte dazu führen, dass das gewünschte Dokument zwar geladen und angezeigt wurde - dadurch wurde das aktuelle Stehenbleiben behoben. Allerdings konnte Elexis zumindest das Testdokument danach nicht mehr ansprechen. Der Versuch, nach dem Laden die Platzhalter zu ersetzen, schlug fehl - stattdessen erschien die Fehlermeldung "Es ist keine Rechnungsvorlage definiert" - deren Text allerdings historisch begründet ist. Nach mehrfachem Durchlaufen dieses Zustandes konnte das System instabil werden, und so erzeugte Dokumente wurden möglicherweise nicht in der Datenbank von Elexis gespeichert (ebenfalls siehe unten).
- Version 1.4.6:
- Erweiterte oder aktualisierte Monitoring-Meldungen.
- Verbesserung des Handlings des Unterbruchs: Zunächst: Einbau einer Rückfrage beim Anwender, dann Reduktion auf einen reinen Informationsdialog. Dessen Darstellung ist ausreichend, um das stehengebliebene System wieder zu erwecken; er dürfte keine unerwünschten technischen Nebenwirkungen haben.
- Inhaltliche Korrektur und erklärende Ergänzung der zuvor genannten Fehlermeldung.
- Version 1.4.7:
- Custom-Version mit schneller reagierendem Watchdog Timer.
- Getestet mit LibreOffice 3.6.5.2.
- Version 1.4.8:
- Aktuelle Bibliotheken (noa-libre und von LibreOffice bereitgestellte).
- Konfigurierbare Loop Thresholds.
- Weiter verbesserte Monitoring-Meldungen.
- Code-Review eine Schicht weiter zu LibreOffice hin.
- Getestet mit LibreOffice 3.6.5.2.
- Version 1.4.9:
- Einfache - noch nicht konfigurierbare - sinnvolle Dateinamen für temporäre Dateien mit Patienten-Nummer, -Name und -Geburtsdatum.
- Getestet mit LibreOffice 3.6.6.2.
- Versionen bis 1.4.15: Siehe oben (zur Vermeidung von Redundanzen).
- Einfache - noch nicht konfigurierbare - sinnvolle Dateinamen für temporäre Dateien mit Patienten-Nummer, -Name und -Geburtsdatum.
- Getestet mit LibreOffice 3.6.6.2. sowie 4.0.2 (Das braucht den Ersatz von einigen wenigen Bibliotheken)
- Meine Stresstests haben Ergeben, dass die OpenOffice Versionen 3.1.2, 3.3.x, 3.4.x zwar bei der Installation und Konfiguration (unabhängig von Elexis und vom Textplugin) Abstürze produzieren können, jedoch drastisch kleinere Speicherlecks aufweisen als alle LibreOffice-Versionen bis 4.0.2, und im Gegensatz zu diesen auch z.B. 1000 Zyklen des Stresstests in einem Elexis, oder je 500 Zyklen in 4 parallelen Instanzen von Elexis durchlaufen können. Deshalb empfehle ich aktuell die Verwendung von OpenOffice 3.2 oder 3.3.
Ergebnisse aus Anwendersicht
- Verbesserungen in 1.4.18 siehe vorläufig nur oben unter Elexis_js.
- Kompatibilität mit OpenOffice 2.0.3 bis 3.x, sowie auch mit LibreOffice - getestet bis LibreOffice 3.6.6.2. Bereits dadurch diverse Verbesserungen.
- Mehrere OpenOffice / LibreOffice-Versionen können nun parallel installiert sein. Die in den Einstellungen ausgewählte Version wird nicht mehr durch das Vorhandensein anderer installierter Versionen gestört.
- Bei neueren Versionen von OpenOffice / LibreOffice ist es nicht mehr zwingend erforderlich, die darin eingebauten Datei-Dialoge auszuwählen. Elexis bleibt selbst dann nicht mehr stehen, wenn in Office die Datei-Dialoge des Betriebssystems verwendet werden.
- Die Wahrscheinlichkeit, dass unerwünschte offene Dialoge und ungedockte Toolbars das Praxisprogramm zum Stehen bringen, wird aktiv und effektiv gesenkt.
- Selbst wenn der hinzugefügte Code diese Probleme nicht mehr rechtzeitig verhindern kann - weil er erst eingreifen kann, wenn das Office-Programm bereits innerhalb von Elexis läuft - rettet der Watchdog-Timer die Situation.
- Bei 1.4.5 erlebte der Anwender nur noch eine Verzögerung im Ablauf, und nicht wie früher ein völliges Stehenbleiben. Allerdings konnte das System wohl dennoch instabil werden.
- Bei 1.4.6 zeigt der Watchdog einen Informationsdialog. Nach Klick auf "OK" läft das zuvor stehengebliebene System weiter. Nach Tests mit präparierten Dateien und Erfahrungen aus der ersten Woche der Anwendung mit LibreOffice 3.6.2.2 scheint es auch anschliessend stabil zu bleiben.
- In jedem Fall werden anschliessend die potentiell störenden Dialoge geschlossen und Toolbars gedockt, so dass der Zustand des Office Pakets für den nächsten Aufruf verbessert wird.
- In der von mir betreuten Praxis funktionierte der Etikettendrucker schon mit Version 1.4.5 dieses Plugins und LibreOffice 3.3.4 wieder so schnell und zuverlässig wie vor dem Umstieg auf Elexis 2.x. :-)
- Version 1.4.2 bis 1.4.5 wurden mit echten Daten getestet, anschliessend haben sie sich über mehrere Monate in zwei Praxen bewährt (sowohl mit einer selbstkompilierten Version von Elexis, als auch mit einer im Abonnement bezogenen). Bei beiden wurde die Stabilität sofort spürbar verbessert; inzwischen gab es weitere positive Rückmeldungen.
- Allerdings hat ein Anwender der Abonnements-Version von Elexis mit etwas älterem OpenOffice berichtet, dass er mit Version 1.4.5 eher den Eindruck einer Verschlechterung hatte.
- Version 1.4.6 ist nun seit einer Woche in der von mir betreuten Praxis mit LibreOffice 3.6.2.2 in Gebrauch - bisher erscheint es stabil.
- Mit Version 1.4.6 wird per Dialog sichtbar, wenn der Watchdog festgestellt hat, dass der Prozess zum Öffnen eines Dokuments zu lange dauert. Eine Limitation: Der Fortschrittsbalken bleibt nach dieser Zeit stehen - LibreOffice kann jedoch trotzdem noch laufen und "legalerweise" mit einer länger dauernden Operation beschäftigt sein (im von mir zur Provokation verwendeten Testdokument auch bis zu 5 Minuten auf schneller Hardware). In diesem Fall erscheint der Dialog des Watchdog verzögert ohne technisch begründete Nebenwirkungen. Allerdings könnte der Anwender verunsichert werden, wenn der Fortschrittsbalken sich nicht mehr bewegt.
- Die Abläufe innerhalb des Plugins sind nun beobachtbar. Die ausgegebenen Meldungen sind robust gegenüber undefinierten Variablen. Im Normalbetrieb werden jedoch keinerlei zusätzliche Ausgaben in den Logfiles erzeugt.
- Mit Version 1.4.7 und 1.4.8 werden Wartezeiten im Fehlerfall verkürzt und einstellbar.
- Version 1.4.9 ermöglicht insbesondere in Zusammenarbeit mit den Optionen "Als E-Mail-Versenden", "Als E-Mail-Versenden im Microsoft Word Format", "Als E-Mail-Versenden im PDF-Format" eine Zeitersparnis: Das manuelle Umbenennen des Attachments aus Rücksicht auf den Empfänger entfällt, und man hat den Patientennamen auch schon im Betreff.
Copyright und Lizenzhinweis (vorläufig zu Version 1.4.6 / erfordert noch Review / letztlich noch nicht entschieden)
NOAText_jsl - Ein verbessertes TextPlugin für Elexis auf Basis von noa-libre.
Portions Copyright (c) 2011-2012 Joerg Sigle, 2007-2010 G. Weirich and Elexis, 2003-2006 IOn AG
NOAText_jsl ist Freie Software: Sie können es unter den Bedingungen
der GNU General Public License Version 2.1, wie veröffentlicht von
der Free Software Foundation, weiterverbreiten und/oder modifizieren.
NAText_jsl wird in der Hoffnung bereitgestellt, dass es nützlich sein wird,
aber OHNE JEDE GEWäHELEISTUNG; sogar ohne die implizite Gewährleistung
der MARKTFäHIGKEIT oder EIGNUNG FüR EINEN BESTIMMTEN ZWECK.
Siehe die GNU General Public License für weitere Details.
Sie sollten eine Kopie der GNU General Public License zusammen mit diesem
Programm erhalten haben. Wenn nicht, siehe http://www.gnu.org/licenses.
NOAText_jsl is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2.1,
as published by the Free Software Foundation,
NOAText_jsl is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with Foobar. If not, see http://www.gnu.org/licenses.
Die GPL habe ich vorläufig gewählt - weitere Erläuterung hierzu siehe oben und ausführlich in den von mir bearbeiteten Dateien. Dort habe ich informationshalber auch andere Lizenzhinweise belassen, jedoch angemerkt, warum die Eclipse License nicht ohne weiteres anwendbar ist, warum in anderen Teilen die GPL anstelle der LGPL erforderlich sein dürfte, und dass ich diese für die vorliegende Veröffentlichung meiner Modifikationen zunächst einmal frei gewählt habe.
Quellcode - Source Code
Version 1.4.18: Folgt, sobald ich Zeit dafür finde.
Version 1.4.15: Folgt, sobald ich Zeit dafür finde.
Version 1.4.14: Folgt, sobald ich Zeit dafür finde.
Version 1.4.13: Folgt, sobald ich Zeit dafür finde.
Version 1.4.12: Folgt, sobald ich Zeit dafür finde.
Version 1.4.11: Folgt, sobald ich Zeit dafür finde.
Version 1.4.10: Folgt, sobald ich Zeit dafür finde.
Version 1.4.9: Folgt, sobald ich Zeit dafür finde.
Version 1.4.8: Folgt, sobald ich Zeit dafür finde.
Version 1.4.6: Verfügbar bei: https://github.com/jsigle/com.jsigle.noatext_jsl
Kompiliertes Paket - Binary distribution
Hinweis: Da NOAText_jsl 1.4.18 ohnehin ein Elexis_js neuer als 2.1.7.dev-qualifier-js-20131101 benötigt, biete ich es jetzt nur im o.a. Elexis_js Paket zum Download an.
Warnung: Ältere Fassungen von NOAText_jsl funktionieren wahrscheinlich nicht mit Elexis_js neuer als 2.1.7.dev-qualifier-js-20130625.
NOAText_jsl 1.4.13 vom 06.05.2013: com.jsigle.noatext_jsl_1.4.13.20130605.jar
NOAText_jsl 1.4.10 vom 28.04.2013: com.jsigle.noatext_jsl_1.4.10.20130428.jar
NOAText_jsl 1.4.9 vom 14.03.2013: com.jsigle.noatext_jsl_1.4.9.20130414.jar
NOAText_jsl 1.4.8 vom 11.03.2013: com.jsigle.noatext_jsl_1.4.8.20130413.jar
NOAText_jsl 1.4.6 vom 23.10.2012: com.jsigle.noatext_jsl_1.4.6.20121023.jar
Versionen 1.4.3 ff. wurden Windows innerhalb einer Umgebung gebaut, die ich mir selbst zur Entwicklung einer angepassten Fassung von Elexis eingerichtet habe.
Aktuell baue ich die Pakete meist in einer elexis-bootstrap Umgebung von Niklaus Giger.
Die Bibliothek ag.ion.noa_2.2.3.jar wird aktuell nicht mehr separat benötigt; erforderliche Inhalte sind in noatext_jsl*.jar integriert.
Zum Herunterladen bitte "Klick-Rechts" und "Speichern unter" verwenden. (Mit "Klick-Links" versuchen manche Browser, das Java-Archiv direkt auszuführen.)
Das heruntergeladene Archiv sollte ins Verzeichnis elexis\plugins gelegt werden. Dort brauchen Sie es normalerweise nicht auszupacken.
Ich empfehle, frühere Versionen des Plugins oder ein noch vorhandenes separates ag.ion.noa_2.2.3.jar in einen anderen Ordner zu verschieben.
Dafür verwende ich selbst den Ordner elexis\plugins-disabled
Installationshinweise
Zur Installation kann es ausreichen, das heruntergeladene Archiv ins Verzeichnis elexis\plugins zu legen und Elexis neu zu starten.
Das Plugin sollte dann z.B. unter Help - Installation Details - Plugins sichtbar sein:
- Provider: jsigle.com
- Plug-in-Name: OOWrapper updated with noa-libre and improved by Joerg Sigle
- Version: 1.4.x (Bitte achten Sie auf die gewünschte Versionsnummer!)
- Plug-in Id: com.jsigle.noatext_jsl
Ausserdem erscheint es unter "Einstellungen" - "Textverarbeitung" als "NOAText_jsl", sowie mit einem eigenen Einstellungsdialog unter "NOAText_jsl • Version 1.4.x • ...". (Bitte achten Sie auf die gewünschte Versionsnummer!)
Wenn Elexis das Plugin nicht erkennt, können Sie folgende Dinge probieren - danach Elexis versuchsweise jeweils beenden und neu starten:
- Elexis mit dem (ggf. zusätzlichen) Parameter -clean aufrufen.
Dies war bei mir für NOAText_jsl Version 1.4.5 jeweils einmal erforderlich, danach wurde das Plugin sofort unter "Einstellungen" angezeigt.
Hierfür können Sie z.B. in Windows:
- mit Klick-Rechts auf das von Ihnen verwendete Programm elexis.exe eine Verknüpfung darauf erzeugen,
- deren Eigenschaften dann mit Klick-Rechts aufrufen,
- und darin ganz am Ende des aufzurufenden Programms ein Leerzeichen und dann -clean ergänzen.
- Wenn Sie nun diese Verknüpfung (doppel)klicken, wird elexis.exe mit dem zusätzlichen Parameter gestartet.
Dadurch werden die vorhandenen Bibliotheksdateien neu entpackt und - hoffentlich - neu hinzugefügte Plugins gefunden und verwendet.
- Ähnliche Wirkung, anderer Weg: Im ggf. versteckten Ordner, der in etwa heissen könnte: c:\Benutzer\Benutzername\.eclipse\ oder c:\Dokumente und Einstellungen\Benutzername\.eclipse\, oder auch in ...\elexis\configuration\ nur(!) die Unterordner org.* (nach Backup!) entfernen.
Vorsicht: Im Unterordner .settings stehen wahrscheinlich die aktuellen Einstellungen für die Datenbankanbindung etc., diesen bitte keinesfalls versehentlich löschen. Wenn Sie die Ordner nicht alle sehen, bitte nicht blind herumlöschen - es könnte passieren, dass Sie einen versteckten Ordner mit erwischen, und anschliessend nicht zufriedener sind :-)
- Einen Eintrag mit dem Namen des neuen *.jar Archivs in elexis\configuration\config.ini aufnehmen, oder einen vorhandenen Eintrag auf den Namen der aktuelle Version des Plugins umstellen.
Dies war bei mir für das Update des Adress-Plugins erforderlich (siehe unten), dort hatte ich mit den vorgenannten Methoden keinen Erfolg. Allerdings habe ich dort auch nur die Versionsnummer der Archivdatei erhöht - was in config.ini nicht automatisch nachvollzogen wurde - wohingegen ich bei noatext_jsl inzwischen den Namen des Plugin-Archivs deutlich verändert habe.
Wenn das Plugin korrekt erkannt wurde, sind noch folgende Schritte erforderlich:
- Unter Datei - Einstellungen - Textverarbeitung das aktuelle Plugin NOAText_jsl zur Verwendung auswählen.
- Unter "Einstellungen" - "NOAText_jsl Version 1.4.x..." (Bitte achten Sie auf die gewünschte Versionsnummer!):
- Den Pfad zum gewüschten (zuvor installierten) Office-Paket, z.B. c:\Program Files (x86)\LibreOffice 3.6 einstellen.
- Wenn das Installationsverzeichnis von LibreOffice dort nicht automatisch angezeigt wird, sollte es über den entsprechenden Button auswählbar sein.
- Wenn alles funktioniert, erscheinen direkt unter dem eingestellten Pfad wenige weitere Informationszeilen zum Office Paket.
- Nach dem Einstellen des verwendeten Office-Pakets ist wahrscheinlich ein Beenden und Neustarten von Elexis erforderlich.
- Ausserdem sollte sichergestellt sein, dass kein Schnellstarter einer anderen Version von OpenOffice / LibreOffice läuft - auch nicht nach einem zukünftigen Neustart des ganzen Rechners! (Siehe Symbole in der Windows-Startleiste, Einstellungen des Office-Pakets, Autostart-Ordner etc.)
- Falls z.B. der Dymo-Labelwriter 450 nach der Umstellung auf LibreOffice die Adressetiketten nicht mehr in der korrekten Orientierung druckt, senden Sie mir bitte eine Nachricht. Das ist offenbar ein Problem von LibreOffice, dafür habe ich neue Druckvorlagen für die Adressetiketten gemacht, die ich Ihnen ebenfalls bereitstellen kann.
- Falls Sie neue Druckvorlagen (insbesondere für die Etiketten) installieren, kann es nötig sein, diese jeweils genau auf demjenigen Rechner einzurichten, von wo aus sie benutzt werden sollen, und im Rahmen der Einrichtung dann auch in LibreOffice/OpenOffice für das jeweilige Dokument den dafür zu verwendenden Drucker einmal festzulegen. - Gegebenenfalls auch nach Arbeitsstationen getrennt unter Verwendung der Präfixe für Druckvorlagen in Elexis, wenn Etikettendrucker teils lokal und teils über das Netzwerk angesprochen werden sollen. Dies ist nicht spezifisch für das NOAText_jsl Plugin - weitere Informationen dazu stelle ich ggf. später bereit. (Möglicherweise werde ich auch einmal schauen, ob eine bessere Druckersteuerung aus Elexis heraus möglich ist.)
Eine gleichzeitige Installation mit der bisherigen Fassung von NOA-Text ist in meinem Entwicklungssystem möglich. Ich empfehle aber, verwandte Plugins und insbesondere frühere Versionen von NOAText_jsl oder NOAText_js, und ggf. auch ag.ion.noa_2.2.3.jar aus dem Ordner plugins herauszunehmen, um Verwirrung zu vermeiden.
Vor produktiver Nutzung empfehle ich eine Installation in einem Testsystem mit einer Kopie der eigenen Daten, einiges an zeitnah durchgeführter Validierung, sowie selbstverständlich gut gepflegte und funktionierende Backups. Ich übernehme keinerlei Gewährleistung - siehe auch die Lizenzbedingungen!
Sonstige Hinweise, bekannte Limitationen, ausstehende Arbeiten
- Limitationen in 1.4.18 siehe vorläufig nur oben unter Elexis_js.
Diese bitte dringend beachten: Dieselbe View in mehreren Perspektiven konfiguriert, macht diese Version des Plugins definitiv unbrauchbar - das hat einen nachvollziehbaren technischen Grund. Wenn man diese Situation vermeidet, ist es vermutlich gut.
- Version 1.4.18 erfordert Elexis_js Version 2.1.7.dev-qualifier-js-20131101 (und ist vermutlich gut).
- Version 1.4.15 erfordert Elexis_js Version 2.1.7.dev-qualifier-js-20130625 (ist aber noch nicht gut).
- Ältere Versionen (und auch andere ätere Textplugins) funktionieren nicht mehr mit dieser Fassung von Elexis_js.
- Die von mir gemachten Änderungen an Elexis sind nicht identisch mit den Änderungen, die Niklaus Giger selbst auf meinen entsprechenden Hinweis für Plugins mit separatem Textfenter gemacht hat. Die resultierenden Plugins und Elexis-Fassungen sind deshalb im Moment auch nicht miteinander kompatibel.
- Versionen 1.4.9 bis 1.4.11: siehe oben
- Version 1.4.8 bieten in den Einstellungen zwei konfigurierbare Zeitlimits.
- Das erste betrifft das initiale Starten von OpenOffice / LibreOffice. Auf einem langsameren Rechner ist der voreingestellte Wert vielleicht zu gering; dann sehen Sie nur schon deshalb, weil der Office Start etwas länger dauert, die Fehlermeldung "OpenOffice-Anbindung nicht richtig konfiguriert..." und können direkt zum Einstellungsdialog springen.
- Das zweite betrifft die Kommunikation mit OpenOffice / LibreOffice zum Bearbeiten eines Dokuments. Wenn dieser Timer abläft, erscheint ein Hinweisdialog - dessen Anzeige zumeist auch die vorliegende Blockade in der Kommunikation mit Office läst. Ausserdem werden automatisch die Menüeinträge und zusätzlichen Dialogfenster von Office so angepasst, dass weitere Probleme vermieden werden.
- Die Stabilität dieses Plugins ist laut Rückmeldung von allen Testern ausser einem besser als mit den anderen von diesen verwendeten Text-Plugins. Allerdings ist sie immer noch nicht perfekt. Insbesondere habe ich selbst Situationen gesehen, wo der Watchdog von Version 1.4.8 einmal die Situation gerettet hat (LibreOffice antwortete nicht gleich; Dialog ist nach dem eingestellten Zeitlimit erschienen und LibreOffice antwortete dann doch - aber beim nächsten geöffneten Dokument antwortete LibreOffice wieder nicht, und auch der Watchdog verbesserte das nicht mehr.)
- Der Watchdog-Timer war bei Version 1.4.6 fest auf 20 Sekunden eingestellt. Auf Maschinen mit Core Duo, i5 oder i7 CPU dauert das Öffnen eines typischen Briefes im Vergleich dazu nur ganz wenige Sekunden. Ich will den Watchdog regelmässig nur dann auslösen, wenn Elexis mit Office auch wirklich hängengeblieben ist. Deshalb kann ich die Einstellung des Timers auf Wunsch ändern oder auch konfigurierbar machen, wenn jemand ein deutlich langsameres System betreibt.
- Ab Version 1.4.6: Wenn das Öffnen eines Dokuments tatsächlich länger als 20 Sekunden dauert - kann der Fortschrittsbalken zu diesem Zeitpunkt aufhören, sich zu bewegen.
- Wenn der Vorgang wirklich hängengeblieben war (offen gebliebene abgedockte Toolbars, Dialogfenster etc.), wird dann sofort der vom Watchdog Timer erzeugte Informationsdialog erscheinen. Nach Klick auf "OK" verschwindet er, der hängengebliebene Vorgang wird abgeschlossen, das geladene Dokument erscheint.
- Wenn der Vorgang lediglich sehr lange dauert (LibreOffice und Formularfelder; relativ langsamer Rechner etc.), ohne dass irgendeine Fehlfunktion vorliegt, wird der vom Watchdog Timer erzeugte Informationsdialog jedocherst dann erscheinen, wenn der Vorgang von selbst zu Ende gekommen ist. Der weitere Verlauf ist gleich.
- Nach meiner Erfahrung kann unter Windows 7 64-Bit das Deinstallieren eines OpenOffice oder LibreOffice Pakets dazu führen, dass die Verbindung der Dateinamens-Erweiterung auch mit einem ggf. verbleibenden anderen Paket dieser Sorte verloren geht. Es scheint mir auch beinahe so, als würde Windows es mir etwas schwer machen, diese Verknüpfungen danach interaktiv permanent zu erstellen. Wenn man also LibreOffice 3.x installiert, und danach OpenOffice 2.0.3 deinstalliert, kann es erforderlich sein, anschliessend nochmals LibreOffice 3.x zu installieren - nur, damit dessen Installer die Verbindung zwischen *.odt und LibreOffice wieder herstellt. Innerhalb von Elexis ist das nicht unbedingt erforderlich, aber hilfreich, wenn man einmal externe oder in OmniVore liegende Dokumente bearbeiten will.
- Umgekehrt hat nun die Installation von LibreOffice 3.6.2.2 hat bei mir dazu geführt, dass LibreOffice sich selbst als Standardanwendung für die Erweiterungen .doc, .docx, .xls, .xlsx, .ppt etc. eingetragen hat. Wenn Sie MS Office parallel nutzen, sollten Sie dies anschliessend wieder umstellen - oder probieren, ob ggf. die Auswahl erweiterter Optionen bei der Installation eine Option zeigt, um dieses Verhalten zu vermeiden.
- Beim Upgrade von 3.3.4 auf 3.6.2.2 hat LibreOffice, soweit ich gesehen habe, fast (?) alle (?) vorbestehenden Einstellungen übernommen - jedoch musste ich die Option "Writer - Kompatibilitätseinstellungen - Keinen zusätzlichen Leerraum einfügen..." erneut ausschalten und danach "Als Standard verwenden" klicken. Diese Option sorgt dafür, dass LibreOffice gleich hohe Zeilen erzeugt, wie (das diesbezüglich wohl fragwürdige) MS Word. Das ist nützlich, falls man die Dokumente später im Word-Format an Kollegen schicken möchte.
- Auf den meisten Systemen und für die meisten Anwender wurden bei meinen Updates von LibreOffice 3.3.4 nach 3.6.2.2 zwei Tastendefinitionen (Accelerators) in der Datei Users/username/AppData/Roaming/LibreOffice/3/user/registrymodifications.xcu (oder ähnlich) tatsächlich übernommen. Nur auf dem ersten von ca. 8 Systemen hatte ich bei 2 von 3 Nutzern den Eindruck, dass das nicht funktioniert hätte, und beim Nachprüfen auch gefunden, dass sich das Format des Eintrags verändert hatte. Ich empfehle Backups einer ggf. angepassten Datei und das Testen der erwünschten Funktionalität nach dem Update.
- In der von mir betreuten Praxis konnte LibreOffice auf dem LabelWriter 450 die zuvor mit OpenOffice erstellten und verwendeten Druckvorlagen nicht mehr gebrauchen - die Druckzeilen wurden immer (egal, welche sonstige Einstellung) quer auf dem Etikett ausgegeben. Dies betraf ausschliesslich LibreOffice, und zwar auch ausserhalb von Elexis. Letztlich habe ich als einzigen Ausweg vollständig neue Druckvorlagen für die Etiketten definiert, bei denen (IIRC) bereits die Schriftzeilen vertikal angeordnet sind. (Diese kann ich später ebenfalls bereitstellen.)
- LibreOffice 3.3.4 öffnet eine von mir erstellte Dokumentvorlage mit über 100 Auswahlbuttons, Eingabefeldern etc. und viel Makrocode wirklich furchtbar langsam. D.h. in knapp 2 Minuten, statt in einigen Sekunden bei OpenOffice 2.0.3. Dieses ist unabhängig vom NOAText_jsl plugin. Jedoch setzt der Watchdog-Timer bei diesem Dokument regelmässig ein - und zwar nicht, weil das Programm stehengeblieben wäre, sondern weil die Operation in LibreOffice so lange dauert. Trotzdem wird dieses Dokument augenscheinlich vollständig geladen, es funktioniert anschliessend auch wie erwartet. [Update 2012-10-30: siehe oben zu noatext_jsl Version 1.4.5 nach 1.4.6: Nein, Version 1.4.5 funktionierte danach nicht wie erwartet. Genau dieses Dokument habe ich schliesslich als Provokationstest verwendet, um das zu untersuchen und zu verbessern. ApacheOpenOffice öffnet dasselbe Dokument viel schneller; (auch) deshalb werde ich vermutlich zu diesem zurückkehren, möchte es vorher jedoch noch weiter testen.]
- In LibreOffice 3.3.4 werden in der Tabellenkalkulation calc Felder mit leerem Text "" beim Verwenden als numerischer Parameter in Rechenformeln nicht mehr automatisch als "0" interpretiert, sondern sie verursachen einen Fehler. Das mag formal auch korrekt sein - es führt jedoch zu einem veränderten Verhalten bestehender Tabellen. Möglicherweise kann man es auch umkonfigurieren? - Eine inzwischen verfügbare aktuelle Version von "Apache OpenOffice" zeigt diese Besonderheit jedenfalls nicht und war mir für meine Tabellen deshalb angenehmer.
- Elexis bezieht die Druckereinstellungen aus den Druckvorlagen des OfficeProgramms. Wenn man viele Druckvorlagen und z.B. Etiketten-Drucker teils lokal und teils über das Netzwerk verwendet, und verschiedene Konfigurationen mit OpenOffice / LibreOffice ausprobiert, kann die Druckerliste in Office unübsichtlich und zwischen den Arbeitsstationen uneinheitlich werden - es kann dann erforderlich sein, nur (!) für die Verwendung bestimmter Drucker unterschiedliche Druckvorlagen für mehrere Arbeitsstationen vorzubereiten. Wenn man solche Vorlagen auf der "falschen" Arbeitsstation zum Bearbeiten öffnet, kann der dort eingestellte Drucker sich ändern - so dass z.B. danach Adressetiketten auf dem Standarddrucker erscheinen. Dann muss man die Druckereinstellung für diese Vorlage wieder auf der "richtigen" Arbeitsstation korrigieren. Dieses Verhalten ist von diesem Plugin unabhängig, das Plugin verbessert aber auch (leider noch) nichts an dieser Situation.
- Die folgenden Hinweise waren vor allem für Version 1.4.5 relevant. In Version 1.4.6 konnte vermutlich die Ursache für die - unter bestimmten Umständen - beobachteten Fehler behoben werden. Version 1.4.6 verwendet auch eine viel weniger eingreifende Aktion zum Unterbrechen des Stehenbleibens, welche kaum noch mit dem Risiko von Nebenwirkugen verbunden sein sollte:
- Die Lösung für das Problem des Stehenbleibens basiert zu einem guten Teil auf einer Arbeitshypothese und Empirie. In der praktischen Medizin funktioniert so etwas ja regelmässig besser als pure Theorie, aber in der IT würde ich mir ein durchaus machbares Review der Abläufe weiter in das Office Paket hinein doch noch wünschen. Anschliessend könnte ich vermutlich weitere Verbesserungen anbringen - und vor allem die Sicherheit der Lösung besser einschätzen. Vielleicht würde der Watchdog-Timer dann auch unnötig - ich kann es jedoch nicht vorhersagen.
- So lange dieses vollständige Review fehlt:
- Im Moment bin ich nicht sicher, ob ein- oder zweimal ein mit diesem Plugin erstelltes Dokument nicht in der Datenbank gespeichert wurde. Ich hatte selbst beim Testen einmal den Eindruck, dass mir das vielleicht passiert sei, und einmal trat es möglicherweise bei einer in Einarbeitung befindlichen Mitarbeiterin der Praxis auf. Beide Eindrücke könnten aber auch gut aufgrund von Anwenderfehlern (keine Konsultation geöffnet) oder Irrtümern (anders bedient, als beabsichtigt etc.) entstanden sein.
- Verschiedentlich erschien beim Öffnen von Dokumenten oder beim Druck von Etiketten die Fehlermeldung: "Fehler: keine Rechnungsvorlage definiert." - Dabei hatte das geöffnete Dokument gar keinen Bezug zur Rechnungsstellung. Dieser Meldung bin ich noch nicht weiter nachgegangen. Wenn ich mich recht erinnere, konnte ich sie jeweils wegklicken, und das System arbeitete weiter wie erwartet. Ich weiss auch nicht, ob dieselbe Meldung auch mit dem bisher frei verfügbaren Textplugin auftauchen konnte, da wir dieses wohl weniger als zwei(?) Wochen mit Elexis 2.x benutzt haben.
- Heute (2012-06-26) hat JH mit der Version 1.4.2 dieses Plugins seine letzten Änderungen an einem Brief verloren - die genaue Vorgeschichte (Bedienschritte etc.) ist leider unbekannt. Als ich das System gesehen habe, lief soffice.exe und soffice.bin (aus LibreOffice 3, auf Win 7 64 Bit) im Task-Manager noch, Elexis aber nicht (!?), und soffice liess sich nicht nach vorne holen. Die letzten verfügbaren Dateien im Temporärverzeichnis stammten vom Beginn der Bearbeitung dieses Briefes (2x, unterschiedliche Dateinamen) und wurden schliesslich beim Beenden von soffice.bin und soffice.exe nicht nochmals aktualisiert. Wiederherstellungsinformationen waren nicht verfügbar.
- Selbst wenn diese beiden Eindrücke auf verbliebene Fehler im Plugin oder in der Integration von Elexis mit LibreOffice hindeuten sollten, därfte dessen Stabilität nach Anwenderberichten deutlich besser sein als bei anderen Alternativen.
- Das Plugin ist wahrscheinlich bis Version 1.4.15 noch nicht richtig mit Linux verwendbar. Das lässt sich wahrscheinlich einfach korrigieren, allerdings habe ich bisher noch keine Zeit dafür gehabt.
- Kommentare könnten besser strukturiert werden.
- Debug- und Monitoring-Ausgaben könnten in das bisher in Elexis vorhandene Logging- und Debugging-System eingepasst werden.
- noa-libre wurde inzwischen nochmals aktualisiert, so könnte ich auch ein weiteres Update von NOAText_jsl erstellen.
msword_js - Entwicklung eines Plugins für Microsoft Word - Prototyp mit Grundfunktionen
Status
Stand: 2012-03
Status: Alpha. Prototyp vorhanden, Aufruf von Microsoft Word in verschiedenen Versionen aus Elexis mit vorhandenen Briefe über einen COM-Wrapper erfolgreich.
Was fehlt: Einige Fleissarbeit - und vor allem: Perspektiven für die tatsächliche Nutzung.
Verwandte Arbeiten: NOAText_jsl - Ein TextPlugin mit verbesserter Stabilität, kompatibel (mindestens) bis LibreOffice 3.3.4.
Adress-Suche js - Neues Update des Plugins "Medshare Directories" ab 2013-11
Status
Stand: Version 1.4.4, 2016-01-19
Status: Beta.
Keinerlei Gewährleistung! Verwendung auf eigene Verantwortung!
Sachkundiger Anwender, eigene Funktionstests in unkritischer Umgebung und gute Backups empfohlen!
Meine in 2010 erstellte Version wurde damals unverändert in die Hauptstämme der Elexis Quellcodes übernommen und dürfte seitdem bei allen Anwendern in Betrieb gewesen sein.
Was fehlt: Titel (wie Dr. med.) werden nicht in das Feld "Titel" übernommen, sondern verbleiben typischerweise im Feld "Zusatz". Diese Limitation liegt am ursprünglichen Design des Plugins, wenn Interesse an einer Verbesserung besteht, kann ich diese gerne erledigen.
Hintergrund
Das Elexis Plugin "Medshare Directories" realisiert die Adress-Suche in einer Internet-Datenbank und die Datenübernahme z.B. beim Anlegen neuer Patienten. Wenn es nicht funktioniert, ist viel mehr Arbeit mit Tastatur und Maus erforderlich.
Verbesserungen
Jeweils in 2010, 2012 und 2013 wurde die Seite tel.local.ch verändert, so dass frühere Versionen des Plugins keine Ergebnisse mehr geliefert haben.
Eine weitere Änderung erfolgte wohl Ende 2015 - danach lieferte das Plugin bei vielen Anfragen nur teilweise Ergebnisse (insbesondere, wenn z.B. nach Name und Ort gesucht wurde u.a.).
Schon in 2010 habe ich im Plugin Funktionen zum Entfernen überschüssiger Leerzeichen, Verarbeitung von Umlauten etc. hinzugefügt.
Die Fassung von 2012 konnte zusätzlich codiert ankommende e-Mail Adressen übernehmen.
In 2013 hat sich Inhalt von tel.local.ch - nach meiner persönlichen Einschätzung - technisch eher wieder rückwärts entwickelt. Unter anderem erscheinen die einzelnen Felder der Adressen nicht mehr getrennt. Statt strukturiertem Inhalt wird eher vorformatiertes Layout geliefert. Auch die Codierung der e-Mail-Adressen ist vollständig entfallen. Das Plugin wurde deshalb wieder angepasst - so dass es mit einigen getesteten Einträgen umgehen kann. Für das Beispiel von "Atupri" in "Bern" werden gleich mehrere zurückgelieferte Angaben (Hausanschrift und Postfach mit unterschiedlicher PLZ; mehrere e-Mail-Adressen) in brauchbarer Form in die verfügbaren Felder übernommen. Die Zusatzinfos zum Facharzttitel werden so ausgewertet, dass für das Beispiel "Hamacher" in "Bern" etwas brauchbares herauskommt - für die Spezialisierung mit Bevorzugung der Detailinfo vor den allgemeinen Angaben und mit Umstellung der Titel.
Quellcode - Source Code
Stelle ich bereit, sobald ich Zeit dafür finde.
Kompiliertes Paket - Binary distribution
Zum Herunterladen bitte "Klick-Rechts" und "Speichern unter" verwenden. (Wenn man stattdessen einfach auf das Link klickt, dann versuchen manche Browser möglicherweise, den Inhalt des Java-Archivs direkt auszuführen, dann erscheint ein Zugriffsfehler.)
Das heruntergeladene Archiv sollte ins Verzeichnis elexis\plugins gelegt werden. Dort brauchen Sie es nicht auspacken, das sollte Java selbst tun können, wenn es die Inhalte braucht. (Weitere Hinweise im nächsten Absatz.)
Im 2016 habe ich die Versionsnummer nun von 1.4.3 auf 1.4.4 erhöht. Die neue Version wurde von mehreren Elexis-Installationen mit dem Dateinamen ch.medshare.elexis_directories_1.4.4.jar nach Beenden von Elexis, Austausch der vorigen Fassung im Ordner plugins, sowie neuem Starten von Elexis sofort verwendet.
Zuvor hatte ich im 2013 die Versionsnummer auf 1.4.3 belassen, weil dasselbe Plugin mit (der schon damals einmal ausprobierten) Versionsnummer 1.4.4 mit zwei vorhandenen Installationen von Elexis nicht funktioniert hat. Mit der Versionsnummer 1.4.3 und dem Dateinamen ch.medshare.elexis_directories_1.4.3.jar hat es hingegen ausgereicht, Elexis zu beenden, das alte Plugin zu Seite zu legen, das neue in den Ordner plugins zu legen, und Elexis wieder zu starten. Bisher nur getestet mit dem Dateinamen ch.medshare.elexis_directories_1.4.3.jar, zur Bereitstellung auf dieser Seite verwende ich jedoch einen Dateinamen mit Build-Datum. Falls es damit unerwartet nicht funktionieren sollte, probieren Sie es bitte einmal mit dem Namen ohne das Datum.
Adress-Suche js vom 19.01.2016: ch.medshare.elexis_directories_1.4.4.20160119.jar
Dieses Paket wurde unter Windows innerhalb einer Umgebung gebaut, die ich mir selbst zur Entwicklung einer angepassten Fassung von Elexis eingerichtet habe. (Hinweise zur Installation stehen weiter unten.)
Wenn Sie über Updates oder Erfahrungen anderer Tester informiert werden möchten, können Sie mir auch gerne eine entsprechende Nachricht senden. Über Rückmeldungen vom Ausprobieren freue ich mich auch.
Installationshinweise
Hier liegt eine (nun schon ältere) Anleitung mit Screenshots.
Das Plugin sollte nach Beenden und erneutem Starten von Elexis unter Help - Installation Details - Plugins sichtbar sein.
Wenn Elexis das Plugin nicht erkennt, können Sie folgende Dinge probieren - danach Elexis versuchsweise jeweils beenden und neu starten:
- Elexis mit dem (ggf. zusätzlichen) Parameter -clean aufrufen.
Hierfür können Sie z.B. in Windows:
- mit Klick-Rechts auf das von Ihnen verwendete Programm elexis.exe eine Verknüpfung darauf erzeugen,
- deren Eigenschaften dann mit Klick-Rechts aufrufen,
- und darin ganz am Ende des aufzurufenden Programms ein Leerzeichen und dann -clean ergänzen.
- Wenn Sie nun diese Verknüpfung (doppel)klicken, wird elexis.exe mit dem zusätzlichen Parameter gestartet.
Dadurch werden die vorhandenen Bibliotheksdateien neu entpackt und - hoffentlich - neu hinzugefügte Plugins gefunden und verwendet.
- Ähnliche Wirkung, anderer Weg: Im ggf. versteckten Ordner, der in etwa heissen könnte: c:\Benutzer\Benutzername\.eclipse\ oder c:\Dokumente und Einstellungen\Benutzername\.eclipse\, oder auch in ...\elexis\configuration\ nur(!) die Unterordner org.* (nach Backup!) entfernen.
Vorsicht: Im Unterordner .settings stehen wahrscheinlich die aktuellen Einstellungen für die Datenbankanbindung etc., diesen bitte keinesfalls versehentlich löschen. Wenn Sie die Ordner nicht alle sehen, bitte nicht blind herumlöschen - es könnte passieren, dass Sie einen versteckten Ordner mit erwischen, und anschliessend nicht zufriedener sind :-)
- Den Eintrag mit dem Namen des *.jar Archivs in elexis\configuration\config.ini auf Version 1.4.3 umstellen (und falls dort notiert, auch auf das neue Plugin-Datum).
Dies war bei mir für das Update des Adress-Plugins erforderlich und wird auch in der oben verlinkten Anleitung beschrieben, dort hatte ich mit den vorgenannten Methoden keinen Erfolg.
Vor produktiver Nutzung empfehle ich selbstverständlich gut gepflegte und funktionierende Backups. Ich übernehme keinerlei Gewährleistung - siehe auch die Lizenzbedingungen!
Copyright und Lizenzhinweise (vorläufig)
ch.medshare.elexis_directories_1.4.4
Portions copyright 2010, 2012, 2013, 2016 by Jörg Sigle, www.jsigle.com
Portions copyright 2007 by medshare and elexis
All rights reserved. This program and the accompanying materials
are made available under the terms of the Eclipse Public License v1.0
which accompanies this distributions, and is available at
http://www.eclipse.org/legal/epl-v10.html
Inhalt
LQ-Recorder
Programming
Colours & Notes
Literatur
Links
Neues
Diese Web-Seite wurde von mir selbst erstellt,
genau wie alle enthaltenen grafischen Elemente.
© 2009-2012
Dr. med. Jörg M. Sigle, Wissenschaftliche IT-Beratung