There is more than one way to write code

CVS systems are great. You can check in your work and others can change it e.g. for coding style. gmDeviceWidgets py was cleaned up by Karsten.

Change is here : http://cvsmonitor.gnumed.de/cvsmonitor.pl?cmd=viewBrowseVersion&version=1.14&file=gnumed/client/wxpython/gmDeviceWidgets.py&module=GNUmed.gnumed

Needless to say I did not even recognize it anymore since huge chunks of the code have been replaced :-)

GNUmed plugin development - part 13

Be aware that some things have changed. The file GNUmedDeviceParserElementTree.py has been moved from test-area/shilbert/ to business/gmDevices.py

There are now four files involved in this plugin.
- gmDevices.py in /business - responsible for the XML data extraction part
- gmDeviceWidgets.py in /wxpython - responsible for calling gmDevices.py and compiling the ui widgets
- gmCardiacDevicePluginPnl.py in /wxGladeWidgets - is the python code representation of the ui widgets
- gmCardiacDevicePluginPnl.wxg in /wxg - is the xml representation of the ui widgets

If I need to change the plugin's appearance I need to touch first gmCardiacDevicePluginPnl.wxg with wxGlade and transfer it into the python code representation gmCardiacDevicePluginPnl.py. This files gets imported and the controls filled with data in gmDeviceWidgets.py. The business logic of data compilation from and to screen is handled in gmDevices.py

Next up is getting the device data from the database instead of an XML file. For the time being it was agreed that the xml file is simply stored as yet another document. To store it GNUmed was started and the plugin 'Document import' was used. I was asked for an associated episode. 'Routine postop cardiac device checkup' was entered. 'Device check up' was chosen as document type. This was entered via the menu item 'GNUmed>Manage master data>document types'.

A quick chat with Karsten revealed the basic code:

pat = gmPerson.gmCurrentPatient()
doc_folder = pat.get_document_folder()
docs = doc_folder.get_documents()

This returns a list of cMedDoc objects which can be parsed like that:

for doc in docs:
    doc['comment'] = ... etc.

doc_folder.get_documents() returns elements ordered by clin_when so the first element is the newest one I am looking for.

for doc in docs:
             if doc['type'] == 'cardiac device checkup report':
                         selected_docs.append(doc)
if not len(selected_docs) == 0:
             # since get_documents() is sorted I simply get the first one as the most recent one
             # for now assume that the xml file provide the cardiac device context.
             # that pretty much means logical connection of leads and generator is provided in the xml
             xml = selected_docs[0].get_parts()[0].export_to_file()
             tree = etree.parse(xml)
             DevicesDisplayed = gmDevices.device_status_as_text(tree)
             for line in DevicesDisplayed:
                        text = text + line
else:
             _log.info('There are no device checkup reports in the database')
             text = _('There are no device checkup reports in the database')

To construct the line

xml = selected_docs[0].get_parts()[0].export_to_file()

one has to take a good look at the file gmMedDoc.py in /business. Using that code it is now possible to get the XML from the database and display the current device status.

Currently the XML is entered via the default the 'attach document' plugin. There is a nifty solution to a problem. How to check for documents of a type that might not yet exist in the database ?

When the cardiac device plugin is initiated the document type is automatically added to the document types in the database. The file gmDeviceWidgets holds the following code for that.

def __init__(self, *args, **kwargs):
         # check if report types exist in db, if not create them
         dtype = gmMedDoc.create_document_type('cardiac device checkup report')
         dtype.set_translation(_('cardiac device checkup report'))

The next step is to get rid of saving to a file and reading from that. Another issue is to get refresh going when entering new data.

GNUmed plugin development - part 12

Show me the code. Part 11 talked about the xml handling. I put everything in the CVS to make it available.
That was almost two months ago. Due to time constraints I only recently picked up again. I had to realize that my python skills are very rusty and that I had to learn to read and write at the same time.

In the meantime both the XML files as well as the Parser have gone through 2 rewrites. I threw the code out where I felt it became too complex for me to handle. Check out the latest version now.

now run:

python GNUmedDeviceParserElementTree.py

and observe the following output:

-------------------------------------------------------------
Device(ICD): St. Jude Medical Atlas DR (active)   Battery: St. Jude Medical (St. Jude Medical)  Implanted: 23.03.2002


RA-lead in RA-position: Medtronic Sprint XL (active,no comment on lead) Implanted: 23.04.2009
last check: 23.04.2004 Sensing: 7mV Threshold 1.4mV Impedance: 300 Ohm

RV-lead in RV-position: Medtronic Sprint fidelis (inactive,no comment on lead) Implanted: 23.04.2009
last check: 23.04.2009" Sensing: 7mV Threshold 1.4mV Impedance: 300 Ohm

LV-lead in LV-position: St. Jude QuickSite XL (active,no comment on LV lead) Implanted: 23.04.2009
last check: 23.03.2004 Sensing: 7mV Threshold 1.4mV Impedance: 300 Ohm

Now what you see here has been parsed from the XML. No more fake input. Next step is to first replace all hardcoded English strings with gettext-equivalents so translators can have a go at them. To achieve that we will take a look at other plugins that already have that feature.

Take a look at gmMeasurementsGridPlugin.py. The first few lines look like this.

import logging

from Gnumed.wxpython import gmPlugin, gmMeasurementWidgets
from Gnumed.pycommon import gmI18N

_log = logging.getLogger('gm.ui')
_log.info(__version__)

All of the above but the second and third line were added to the top of the parser. To tell gettext where to replace I marked them like this:

_('this is a string that needs a translation') vs. 'this is a string that needs a translation'

So the _() construct identifies the strings to gettext. The following lines were added to the main section.

from Gnumed.pycommon import gmI18N
gmI18N.activate_locale()
gmI18N.install_domain()

Running the parser now displayes the same result even after all 'I am a string' occurences having been replaced by _('I am a string'). The next part will try to get the parser connected to gmCardiacDevicePlugin and get this plugin displayed in GNUmed. Once this has been accomplished the XML needs to be read from the database instead of a file.

How to build GNUmed packages for Windows

A few people have responded to my call for regarding packaging. Despite the fact that this only touches the Mac as no volunteers showed up for Windows or any distribution besides Debian I have continued to put up documentation on how to package GNUmed for various OS and distributions.

The last few hours I have rebuilt packages for Windows. It should have taken only 20 minutes but this time I decided to document everything in a step by step guide.

The guide can be found in the Wiki at http://wiki.gnumed.de/bin/view/Gnumed/GNUmedNSIS

If you follow that guide you should be able to roll Windows packages yourself. Anyone willing to help out with packaging new releases please let us know at gnumed-devel@gnu.org.

 

How to build GNUmed packages for Ubuntu from Debian

Packaging for multiple distributions and operating systems is quite some work. Our Ubuntu packages are based on the fine work of the Debian-med team.
I order to attract contributors to the GNUmed project (and to get some work off our backs :-) we have published a guide on how to build GNUmed packages for Ubuntu. Anyone willing to help us out is welcome to take a look at our Wiki.

GNUmed EMR client has been updated

The client for the electronic medical record GNUmed has been updated to version 0.4.6. There are no database fixups to apply for this release. Packages are available through the Launchpad PPA at:

https://launchpad.net/~gnumed/+archive/ppa

Feedback is always welcome.

GNUmed update tricks

Hi all,

Every so often a new GNUmed series is released. This time it changes from the 0.4.x series to the 0.5.x series. This involves two major changes. The client has new features and possibly regressions. But more important is that a new database might be needed. In this case there is a major version change in the database version.

This involves a database upgrade during the installation process and is described at http://wiki.gnumed.de/bin/view/Gnumed/ServerUpgrade2. Last but no least it involves upgrading you client config file so it will let you select the new database at client startup.

More info on how to edit your config  files can be found at: http://wiki.gnumed.de/bin/view/Gnumed/ConfigFiles

So after upgrading to client 0.5.x you will need to select version 11 of the GNUmed database.

GNUmed 0.4.6 and 0.5.rc1 released

As announced on the mailing list GNUmed Updates have been published. The stable 0.4.x series is now at version 0.4.6.

Futhermore the first release candidate of the 0.5.x series is out. This series brings new features and hopefully no new bugs. We need help to test these release candidates.

Packages for OpenSUSE , Fedora, Mandriva are available from the OpenSUSE Build service at http://download.opensuse.org/repositories/home:/SebastianHilbert:/GNUmed/

Installation instructions are available from http://wiki.gnumed.de/bin/view/Gnumed/InstallerGuideHome

Please report any problems to gnumed-devel@gnu.org or forum.gnumed.de

OpenPhysio für die Physiotherapie

Es scheint als gäbe es noch einen zweite Bestrebung eine OpenSource Software für die Physiotherapie zu entwickeln. DIe Lösung findet sich als Alpha-Version unter www.openphysio.de. Die Macher von Thera-Pi.org sind darüber informiert.

Obwohl Konkurrenz das Geschäft belebt ist es im Anfangsstadium extrem schwer ein Projekt auf die Füsse zu stellen. Vielleicht finden beide Projekte ja zusammen und schaffen eine knackige Alternative.

Mindestens zwei Physiotherapiepraxe nutzen GNUmed. Da stellt sich die Frage ob man nicht alle Projekte irgendwie vereinen kann.

www.openphysio.de
www.thera-pi.org
www.gnumed.de

Dicom viewer (X)medcon packaged for Linux

Xmedcon has been packaged in its latest version 0.10.5. Apart from providing the latest version there now is a packages for OpenSUSE 11.1 as well which previously did not build.

Get it from via 1-click installation from http://software.opensuse.org/ymp/home:SebastianHilbert:GNUmed/openSUSE_11.1/xmedcon.ymp

When overengineering fights getting things done

When I had some days off from work a few weeks ago I started to hack on a GNUmed plugin for cardiac device management. The idea was simple. Avoid all the mistakes done by the software I currently use and make it even better (TM). Back then I decided to document my steps toward the goal. Those of you having followed the series are aware that the planning stage went well. Having ideas and putting them on paper or mindmaps is the easier part. When the coding started it became quiet.

Let me explain why I think that is quite natural. One has to learn new tools. In my case that means learning python and wxglade. One has to learn about the existing code. In my case that is learning about database connections and getting patient information from the database. The single most critical issue howerver is the overengineering disease.

I work with a system that takes on pacemaker management. It has some flaws. Some of them I consider serious. Producing a new system involves finding and avoiding those flaws. I got trapped however by the desire to handle every use case in the first iteration of the plugin.

The only solution is to take a step back and reduce the initial feature set without cutting down on the possibilities. The plan is to get a working version out and enhance it gradually.

Another round of ICU shifts is coming up so this will have to wait for two weeks or so.

GNUmed mobile edition updated to version 0.4.5

The GNUmed mobile edition has been updated to client 0.4.5 and server v10.5

What is the mobile edition you might ask ? GNUmed mobile edition is a carefully crafted version that requires no local installation. It is a Windows version that is installed (copied to) a removable drive such as a USB drive. It can then be started from that drive in (hopefully) any Windows-Computer on the go. The data is stored on the removable drive as well.

While updating I have not simply updated GNUmed but added some features as well.

1.) The GNUmed client is integrated with the PortableApps laucher
2.) The PortablePostgres systray launcher is intergrated with the PortableApps launcher
3.) The PortablePostgres systray launcher provides access to the portable PG config files
4.) PortablePostgres is configured to run on port 5433 rather than 5432 so it will run alongside a locally running PostgreSQL. Useful for backup/restore feature
5.) Client size has been reduced to 25MB from 88MB
6.) Server Size has been reduced to 171 MB from 288MB

On my todo list:
1.) show active/inactive status for PostgreSQL through colored systray icon
2.) add backup/restore scripts specifically for GNUmed for pre/post house call situations
3.) Talk to Karsten about display option of server one is connected to in the GNUmed window

Grab it from http://wiki.gnumed.de/bin/view/Gnumed/InstallerGuidePortable

FOSS EMR visibility

Thanks to the great work Andreas Tille from Debian is doing I was able to quickly supply packages for various Ubuntu releases.
Every once in a while I search for GNUmed via Google. I am always surprised that it will come up at a number of places when people are looking for alternatives to closed source EMR packages.

I was even able to find threads that indicate that users we are not aware of through the mailing list actually have succeeded in getting GNUmed to run in their machines. Most of the time they use Ubuntu which is only possible because of the work of Andreas and the Debian-med team.

But there is another side of the coin as well. When putting in Linux and EMR into google the interested searcher is not directed to a site that presents the FOSS EMRs in a light that would make one try it.

FOSS EMR are as badly represented as possible. There is no room for the 'not invented here' syndrome. It is a small market and we better make damn sure we represent the FOSS EMR ecosystem as good as possible.

This primarly involves to allocate ressources at
1.) user friendly packaging
2.) user friendly package distribution
3.) user targeted software descriptions

At GNUmed we have come a long way and even put some serious cash from our own pockets behind this. Unfortunately not all projects seem to understand this issue.
First they (users and competitors) ignore you. Then they will laugh at you. Then the fight you. Then you win. FOSS EMR are barely beyond the ignore phase.

GNUmed for Ubuntu updated

Packages for Ubuntu have been updated to provide the latest upstream version. Available via the PPA is client version 0.4.5 and server v10.5. This version fixes a nasty bug that in some cases would write an incorrect date of birth to the database.

Packages are available from https://launchpad.net/~gnumed/+archive/ppa

OpenSource Physiotherapiesoftware Thera-Pi

Bin vor einigen Tagen auf die Software Thera-Pi gestossen. Dabei handelt es sich um eine Software, die eine Verwaltung einer Physiotherapiepraxis bzw. eines Rehazentrums ermöglichen soll.

Welche positiven Aspekte sind schon jetzt zu bemerken.

1.) Start soll der 1.1.2010 sein. Bis dahin soll es fertig sein.
2.) Es soll OpenSource sein - der Quelltext ist schon jetzt verfügbar
3.) Es bildet ein Programm nach, dass schon jetzt existiert und vom selben Programmierer stammt

Programmiert wird in JAVA. Helfer und Tester werden noch viele gesucht.

Aktuell besteht das Henne/Ei-Problem. Weil noch unfertig finden sich nur wenig Helfer und daher wird es nicht so schnell fertig wie geplant. Ich empfehle allen potentielle Interessenten den Besuch der Internetseite www.thera-pi.org.

GNUmed - please support a stable release update (SRU)

Since Jaunty was released we are getting about two automatic bug reports a week because GNUmed crashes on the same version and error in Ubuntu. The reason has been known for a while but a fix did not make it into Ubuntu because of feature freeze.

I have filed a bug with the intent to get a stable release update published. See this bug.
https://bugs.launchpad.net/ubuntu/+source/gnumed-client/+bug/375874

The solution is to either update GNUmed to a fixed version in our PPA or set a supported timezone in GNUmed (this needs a timezone which PostgreSQL can handle).

Please try gnumed-client and gnumed-server from Jaunty (version 0.3.9) and if it crashes please update to 0.4.4 and report your finding on the bug report. That way MOTU might get a better impression if a SRU is worth the effort or not.

If it does not work out we will at least have a better version in Karmic :-)

Thanks
The GNUmed team

On handling software updates in Ubuntu

GNUmed - one of the FOSS electronic medical records has seen quite a few bugfixes since Ubuntu 9.04 was released. The sad part is that many (potential) users never find out about that.

GNUmed updates are available through the GNUmed team's PPA but few users will search for a PPA. It is documented on the webpage but often when you encounter a bug in a software you are trying you are not investing to much energy into getting it run. It either runs or one moves on.

All we can do about it is wait for the next Ubuntu release to ship an update. I know there is a backports repository but we have been down that road. Until enough people verify that the package should go in backports a new release is out.

I really believe there should be a mechanism that lets Ubuntu users search for software updates and include the PPAs

http://packages.ubuntu.com/ should include the PPAs such as the search on software.opensuse.org does.

GNUmed support for OpenSUSE 10.3 fading out

As I am not aware of anyone still using GNUmed on OpenSUSE 10.3 I have upgraded to openSUSE 11.1. This means packages are still built but not heavily tested. If you rely on 10.3 and experience problems in the future let us know.

Upgrade to 11.1 went flawless. GNUmed client and server were installed through the one-click-feature. A simple gm-bootstrap_server call on a root shell bootstraped a complete database.

Sebastian

Can Ubuntu save the electronic medical record ?

There are a number of Open Source electronic medical record software packages (EMR). There are even more proprietory EMR packages. Many of the FOSS EMR can compete with the commercial ones. Despite the fact that they mostly run on free OS such as Linux they are mostly invisible.

When you try to sell a FOSS EMR on a free OS it gets difficult. Few FOSS EMR have bothered to package for any given distribution. GNUmed is one of the few that provides packages for Ubuntu , Debian, openSUSE, Fedora and others.

Since the inception of Debian packages a lot more people have been able to try GNUmed on a free platform. It is about the users. EMR are valuable to very few people but the that look for Linux EMR have not been greeted by nice installation methods so far.

Ubuntu has received a lot of buzz lately. Seems like a lot of people are getting introduced to Free Software by means of Ubuntu. We are prepared for that. GNUmed provides easy to install packages.

Is it enough ? We don't know yet. It would certainly help if more medical and scientific software was visible. There is a project called Debian-med which takes care of aggregating scientific and therefore medical packages in Debian. I believe a medical derivative of Ubuntu could benefit both sides.

Increase visibility for Ubuntu as a commecially viable OS in medical offices and certainly expose FOSS EMR to a wider audience.

Free your mind with mindmapping

While I am wraping my head around the details of the cardiac device pluging I realize just how complex it is to get it right. The software i currently use solves that by ignoring corner cases like a lead being implanted at the right ventricular apex but being paced fom the atrial channel of the generator. It does not cater for the case that a patient has an left ventricular and right ventricular lead but both being connected to the RV channel through an Y-connector.

The XML file is changing almost every minute a new thought comes up. I have been toying with the idea of how to group devices. To do that one has to define what a device is. I have settled for the definition that an ICD-device is actually a virtual device consisting of a generator and a number of leads. Actually the generator consists of a battery, a number of output/input channels and a mainboard that does the signal processing and therapy delivery.

Why so overly complicated. Because you will want to know which of your patients have a device that has just been recalled or if the ICD shocks are related to the lead being flaky. You might also be interested in the fact that the program you applied two years ago led to less shocks than the currently active one.

To even have a chance to get this done right I have started to use a mind mapping tool called vym. It exports to various formats. The map itself is in the test-area for shilbert in the CVS.

Have a look. Right-Click-Display-Image to enlarge it.