Interview with Karsten Hilbert

Karsten, Judging from the Wikipedia entry you have been involved with GNUmed for quite a while.

How did you get involved ?

We were using Linux on the server side in my parents' medical office for quite some time. While babysitting their proprietary EMR I often experienced quirks and bugs and attempt-once-only upgrade procedures which, having some knowledge in programming, made me wonder whether there's anything better out there. Something where I could influence the design or fix bugs. So I scourged the net and fournd GNUmed started by Horst Herb. His concepts appealed and made sense to me so I got on the mailing list and started to ask questions.

What was your first contribution to GNUmed ?

I don't really remember. However, the first larger or noteworthy contribution was to define and code a basic patient object. The next step was to define a must-have roadmap for 0.1 and follow through with it.

Why did you choose python as programming language and why wxwidgets for the user interface ?

I didn't, Horst did smile Python struck me as a great balance between maintainability, speed, and rapid development. It also promised to be a low barrier to entry for non-professional coders. The GUI toolkit - which is wxPython based on wxWidgets, btw - was available cross-platform under a FOSS license (which Qt wasn't on Windows, at that point). It also delivers the look-and-feel typical for a given platform, that is GNUmed on Windows looks like a Windows application while on Linux it looks like a typical Gtk app. The API is, unfortunately, very C++ish. While Dabo delivers a much more pythonic API on top of wxPython there are no Debian packages for Dabo which so far prevented me from using Dabo.

We have heard complaints on the mailing list about the user interface. What does it involve for other programmers to change that (e.g. QT) ?

Well, the business logic is largely encapsulated in classes which don't have anything to do with the GUI. So, it'd be a matter of writing another GUI and hooking that up to our business classes. It's a lot of work GUI-wise but no business logic needs to be reimplemented because the GNUmed design roughly follows the MVC/MVP pattern. Of course, there will be a bunch of little things that do turn out to be tied to the GUI in one way or another but I'd be happy to iron them out quickly. So, just do it. We'll handle any needed adjustments in the middleware just fine.

Why doesn't GNUmed use MySQL as it seems to be more widely used ?

We use advanced data protection and integrity methodology which simply isn't available in MySQL such as foreign keys, constraints, triggers, rules, inheritance, and lots more. Some of them are available in one form or the other for MySQL but one cannot currently have all of them at once. You'll have to decide which you want and pick a storage engine that supports those you picked.

A deal-breaking "feature" of MySQL (I'd have to check whether it'd be possible that that really still applies) was that MySQL would, under certain circumstances, merrily and silently truncate numbers to the largest value a given field can store. Imagine that happening to a red-flag lab result ! You'd be telling patients their lab is fine while most decidedly it is not.

In short, PostgreSQL has proven to be rock solid, very performant and uncompromising on data quality. And we started using it when it was still version 7.1 !

Is GNUmed specific to any particular health system or locale ?

What makes practice management applications specific to a locale isn't the medical side of things, it's the political turmoil of regulatory disease. In GNUmed we work hard on clearly separating such concerns. The medical side of things makes immediated sense to active doctors all around the globe to which our user community attests. In those cases where locale-specific code needs to be nicely integrated with the medical GUI we were so far able to abstract out the local needs via APIs supporting locale-specific plugins. Currently there is no sign of that not being possible any longer.

Who is most likely to use GNUmed ? Hospitals or smaller care facilities ?

GNUmed is intended to be used by walk-in clinics, primarily of the General Practitioner variety. However, it is being used for dedicated tasks in Physical Therapy practices and hospital departments as well. Basically, there's two things which differentiate a Practice Management application from a HIS:

  1. range of features
  2. scalability

While 1) can be mitigated by careful design using plugins, APIs, and separation of concern inside the code the 2nd argument cannot easily be taken care of (it can in principle, as evidenced by the Linux Kernel and, partially, by the Veteran's Affair Vista EMR). Certain scalability requirements ask for other design decisions, say, accessing federated databases, which aren't appropriated for a PM system.

GNUmed is hard to install. Can you give an overview if still holds true and why this perception came about ?

It much depends on how much pain you want to inflict upon yourself. If you run the recommended platform of choice (Debian/Testing) then all that is required to get the latest released version is to type
$> apt-get install gnumed-client
To add a local server to that (you don't have to - we offer a public server on the internet for testing) simply go
$> apt-get install gnumed-server
$> gm-bootstrap_server
Then there's 1 line to be added to a config file on the server and another 5 or so on the client in order to have your client access your local server.

We also offer RPMs for the most common distributions out there. A windows installer is available. A live-CD is available. You can run GNUmed from a USB stick. You can have someone preinstall it for you into a virtual machine image. It is even easy to run locally from a copy of the tarball. For that we also provide shell scripts for upgrading client and server.

Is there any support available for interested users ?

Who drives development and what does it involve for 3rd parties to add features to GNUmed ?

How do the GNUmed developers communicate and what tools are used to work as a distributed team ?

We mostly communicate via email on the mailing list. Sometimes there's a bit of in-person discussion between developers - one feature of Version 0.5 was discussed and decided upon while riding a ski lift wink Every once in a while we try to have a GNUmed conference.

For more persistent documentation we use a wiki ( where we store manual pages, blueprints, links to pertinent specs etc.

Everything related to code is available from CVS hosted by the GNU Foundation.

What do you plan to add in the future to scratch your own itch ?

How can interested users get involved ?
Topic revision: 18 Jun 2009, JamesBusser
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark