GNUmed 0.7.6 on Mac - user report

Jim mailed in to show this screenshot of the freshly released
GNUmed on Mac OS 10.6.4 aka Snow Leopard

GNUmed web interface - wishlist

The following article show a) that I still know very little about web application development and b) that the person implementing this properly really needs to have a good skill set.

The person doing the web interface for GNUmed needs to have good skills in
- python
- Javascript
- JAVA
- object oriented coding
- MVC principles
- singlepage applications vs. multipage applications
- balancing client side workload with client side workload
- coding and running multiple instances of GNUmed web concurrently

Hardware is cheap. Internet tubes are congested and will be even more in the future. This means GNUmed web will need to

- transfer as little data and overhead (!) as possible
- cache heavily on the client side while ensuring data consistency (hard one)
- offload the user interface rendering to the client
- be capable of rendering user interface server side for incapable clients
- seperate data, ui layout (templates)
- have full i18n support
- handle 20 sessions on a off the shelf office server

It does not make sense to try to develop an interface that will fit small touch devices as well. Touch devices need a seperate interface.

When you attempt this please try to avoid code that makes an AJAX call for every keystroke in a phrasewheel or takes 30 seconds to load the login screen. If you think you have the skills it takes we sure would like to know.

GNUmed web interface - to framework or not to framework

Having read up quite a bit on the subject over the last few days a picture is forming. In short
there is no such thing as the optimal solution. Frameworks are all the hype nowadays. They have
helped to make Javascript usable for web application developers despite the fact that browser
incompatibilities are a pain in the rear.

Since browsers speak Javascript one needs to learn that language. Sure there is GWT which lets
web developers develop in JAVA (it will compile JAVA into Javascript). When reading up on GWT I
came across ZK which is yet another toolkit for JAVA developers.

Then a tiny little bit of information came up that is overlooked and ingnored by media. There is a
difference between client side frameworks and server side frameworks. Often one is tempted to look
only at the graphical user interface of the frameworks. Beauty is all too often associated with quality.

For all non web app wizzards the basics are like this. In a client side framework all the processing
is done in the browser on the client. If the app wants data it has to talk to the server to get it. On
other end there are the server centric frameworks that process all data and user interface on the
server and send html to the browser. The server centric way is often associated with a desktop
like developement. Both approaches have their share of pros and cons.

Some of the conclusions I have drawn so far:

• framework is no well defined entity

some include features to render a user interface, some talk to databases, some to all of this

• user interface frameworks

there are many, most are client side, some are server side and some are both
most are Javascript based, some are JAVA-based (GWT) or Python-based (pyjamas)
a bug in the framework might break the application

• language considerations

many if not most web app developers are using Javascript
professionalism varies widely
supposedly going through a language-to-Javascript compiler
will fail badly in case of a bug

• framework intercommunication

various techniques including Json and RPC exist but there is no consensus
or benchmarks 

• designer applications

the widely used frameworks such as extJS and ZK have designer applications
available which would allow non-coders to produce pseudo code or mock ups.

Going back to the drawing board (with a little more info on frameworks)
here is what I am looking

for.

• code or a framework that lets me develop the user interface without it messing with the database itself (for now). This is the work of gmPG2 and friends.
  
• a nice looking set of widgets that makes up a nice looking interface
• a set of widgets that can be accessed through python (e.g. ToscaWidgets)
• a framework that will be there for a few years and not being given up for the next best thing
• solution that lets me seperate design (html, css, JS) and content through e.g templates
  

So far I have found nothing that fits the bill. In case of Pyjamas I am unsure about its
future and its set of widgets. I like that one could develop in python. It would mean that
Javascript coders are left out. GWT would mean learning JAVA. License is Apache License
v2.0. extJS or qooxdoo would mean learning Javascript and would leave the python coders
out. I like the idea that extJS and ZK have designers available.

As always feedback is highly appreciated.

GNUmed web interface - when easy is not so easy after all

There is two sorts of user interfaces for FOSS EMR. There are the fat client applications
and the web client applications.

GNUmed is a fat client application. It uses wxpython and has an interface like many
traditional software applications. That means it needs to be installed on a user's computer.
This has pros and cons. On the positive side developers need to code exactly one interface.
The actual redering is left to the operating system and underlying GUI toolkit. However
providing the underlying toolkit on many operating systems and window managers is no
easy task.

Then the internet era came along and brought the browser. There was one rendering
application (the browser) and one user interface language (html). It turned out that was
not reality. There are dozens of browsers and because html alone is limited along came
CSS and JavaScript. But there was one very important detail that makes the web attractive
for delivering applications. All you need is a browser. You do not need to install the application
on your computer and you don't need to mess with dependencies such as special libraries.
In the ideal world you make your application run on on computer (the server) and the clients
(the browser) will only display the output and collect input to feed back to the server.

Web clients have their own share of problems. Browsers are not fully standard compliant. For
security reasons you cannot access local peripheral devices such as scanners, printers, files
easily. That severly breaks a input-oriented application like an electronic medical record.

People came up with all sorts of clever solutions. Thin client are fat clients whose output is
displayed at a remote location. This does not sound too bad. However the data that needs
to be transfered is too much for today's internet lines and even broadband. VNC is only usable
when run in a highspeed local network of 100MBit/s or more. And people tried to solve that
problem as well. They came up with the NX protocol. Pretty much a heavily optimized remote
display solution. It works and it works well but the web is so prominent that it does not
penetrate the mass market.

NX solves the problems for the user. Well kind of. You still need to install a NX client on your
computer. Then NX married the solution with the browser. They built the nx browser plugin.
This is one solution to the problem. However the nx client needs to be available for every
platform and every device (ARM, x86, your favorite operating system here). It is not. But the
web is. Virtually every device that looks like an electronic device can run a browser. Even the
washing machine and the microwave oven have Android installed. Anywhere there is a browser
there is chance to deliver the application.

Does GNUmed need a webinterface. I don't think so. However people are made to believe that
the personal computer will go away in 2-5 years. Along with it there is a chance that fat clients
will go away. That would make the GNUmed client we have today go away. The doctor does not
care. She just wants it to work not matter what technology. Lets just say GNUmed needs a web
interface. Apart from the fact that then GNUmed team does not yet have anyone with the skills
needed to make this a success it is always a good idea to look at what others have done so
far.

Web interface definition
There is two types of web interfaces. One is the traditional mix of HMTL pages maybe with a bit
of CSS for beatification and some Javascript to make it look. The other one is a so called RIA
(rich internet application). This is what Gmail and friends think a web application should work
and look like. Because the mix of browsers and OSs is such as PITA frameworks have been created.
Those frameworks try to abstract the pitfalls from the developer and try to offer a cross-browser
and cross-platform user interface developement solution. This has been benefical but developers
tend to push the boundries. This lead to countless approaches and frameworks. Many of those
target Javascript developers (extJS, dojo, qooxdoo, YUI, jQuery). Then Google came along and
brought GWT which let developers develop in JAVA instead of pure JavaScript. This however means
you
need to program in JAVA or at least php.

Choosing the right tools
Over the years it became evident that developers seldomly have design skills.
Application design was pushed down on the agenda and a few webpages were created to for
the EMR user interface. Pretty soon everyone noticed that those "applications" are a  nightmare
to develop, maintain, translate and debug. Users broke them all the time. Not because users
are stupid but because they are busy and impatient. The result is what openEMR, Oscar and
Freemed (up to 0.8.4) look like today. Design says little about how well an application works
but users tend to associate the quality of an application with its design.

Road to redesign
Nearly all projects I followed over the years have either done a complete user rewrite or plan to
do so. Freemed has been picked up but even the rewrite is under rewrite. They tried Dojo

but that did not work so they switched to GWT. The web application now works as a mix of
three languages (PHP, Javascript, JAVA). The interface looks promising and I hope they will
pull this off. OpenEMR is currently getting certified in the US. I wonder how long it takes before
the UI will be rewritten.

Back to GNUmed.
While the appearance of openEMR and Freemed might be lacking GNUmed
is not there yet. It has recently been demonstrated that the GNUmed backend and middleware
(connection to the database etc.) can be reused without much effort in a webbrowser. The
only thing missing it the graphical user interface. It is not as easy as it sounds. Careful
planning is indicated to avoid starting over a few months down the road. A python based
web application usually uses a python web framework anlong with some template manager.
For python there is at least pylons, django, turbogears, cherrypy. These frameworks try to
be complete solutions. They bring everything to the table including database access. But we
don't want that. So the question arises do we need a python framework ? Given my little
knowledge I am not sure about that. Next question is on the user interface framework. Do we
need a Javascript framework like extJS , GWT , qooxdoo and friends. I am starting to believe
we could use one of those although I am not sure how to marry this to our middleware. The
point is unless you have a very experienced web application developer in the team chances are
this gets screwed up and wastes time.

Pyjamas to the rescue.
A group of people thought what GWT is to JAVA GWT can be to Python as well. They came up
with pyjamas. The ideas is to develop in python and the python-to-javascript compiler will
translate this to well JavaScript. JavaScript is the only language browsers understand. There
is documentation on this and it is supposedly relatively compatible to GWT. I lack the insight
to judge how well this works. The potential benefit is a closer tie to the python middleware.
A potential drawback is that you need a python coder to do the job. This will leave out all
web developers which are only fluent in JavaScript. And those are the majority I would guess.

Performance considerations
While reading up a lot on web application development I noticed there are a number of ways
to solve the problem. There is no best of practice and depending on what you wanna do
opinions differ. It boils down to where to do the heavy lifting. One end of the rope is creating
all (x)HTML on the server and serving that to the client. The other end is letting the client to all
the HTML,JS,DOM work.  Since I know too little on this here is an article which talks about it.

Long story short
Doing a web interface is easy. Just start and learn along the way. The same attitude is inherent in
some of the FOSS EMR both with web clients and fat clients. While it works it certainly is a pain
if you ever want to hand over the code to another developer.

What are the options.
One could look into pyjamas and try to make the most of it. Or one could just learn JS and go for
extJS and friends. I guess no option would be to use pure GWT since there needs to be a bridge
between python and JAVA (Jython maybe?). One could also just do away with the RIA as a whole
and serve a few static or partly dynamic webpages.

I would really welcome some comments here. As I said I am totally new to this. However if this
is not properly planned it is better to leave this out. And who knows how the internet will develop.
There might just be wxwidgets to javascript mapping appearing.

How to share your GNUmed code via GIT (gitorious)

There may be different ways, better ways. Here is how you can share your code with the rest of the GNUmed community.

The GNUmed project use GIT as a way to host the source code and track changes. The GNUmed code can be found at gitorious. This so called repository has been created by Karsten Hilbert (ncq) and will host his changes to the GNUmed code. There is no such thing as the official GNUmed repository.

In order to share your code with the world through git you need to get yourself a gitorious account.

1.) Sign up with gitorious
2.) Start a new project (e.g. gnumed-yourshortname)
3.) Upload you plubic ssh key or create a new one if you have none

Once you have this you need to fill this with code. I assume you have a local git repository on your computer since you most likely created code by now. If you don't then start using GIT today.

Please see my previous article on GIT for GNUmed for information on how
to use git for your code.

Now it is time to upload your code. The repository you have on your local disk
is a full, standalone copy of Karsten's repository on gitorious. Other
than that it 'knows' about its origin there is no connection between the two.
There is an article on that and I will summarize it here.

To upload you code you need to tell git where to. The destination will be you
project on gitorious. For the beginning I have chosen to make a copy of the
git checkout on my computer. The checkout from ncq is in

~/sources/gnumed-head and the copy in ~/sources/gnumed-shilbert to reflect
which is my tree and what is ncq's (read-only) tree.

Now open ~/sources/gnumed-shilbert/.git and edit the file config. Before the
change it looks like this.

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://gitorious.org/gnumed/gnumed.git
[branch "master"]
remote = origin
merge = refs/heads/master

Change the line url = foo to let foo reflect your tree at gitorious. You will get the url
from gitorious once you have created your project and logged in.

After the change mine looks like this.

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@gitorious.org:gnumed-shilbert/gnumed.git
[branch "master"]
remote = origin
merge = refs/heads/master

Now everything is configured to upload your local git tree to gitorious. Do it like
this to upload your newly created branch (template in my case).

git push origin template

The following output can be observed.

The authenticity of host 'gitorious.org (87.238.52.168)' can't be established.
RSA key fingerprint is 7e:af:8d:ec:f0:39:5e:ba:52:16:ce:19:fa:d4:b8:7d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gitorious.org,87.238.52.168' (RSA) to the list of known hosts.
Enter passphrase for key '/home/basti/.ssh/id_rsa':
Counting objects: 91837, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (18055/18055), done.
Writing objects: 100% (91837/91837), 37.85 MiB | 71 KiB/s, done.
Total 91837 (delta 63311), reused 89983 (delta 61565)
=> Syncing Gitorious... [OK]
To git@gitorious.org:gnumed-shilbert/gnumed.git
* [new branch] template -> template

Then push your master branch which initially will be identical to the ncq's
master branch until you or ncq change the now individual master branches.

basti@thinkpad:~/Sources/gnumed-shilbert> git push origin master
Enter passphrase for key '/home/basti/.ssh/id_rsa':
Total 0 (delta 0), reused 0 (delta 0)
=> Syncing Gitorious... [OK]
To git@gitorious.org:gnumed-shilbert/gnumed.git
* [new branch] master -> master

You are almost done. You have to announce it to the world :-) You can e.g. send
an e-mail to the mailing-list at gnumed-devel at gnu.org and point people to your
code. They will then look at it and maybe incorporate them into their own trees.

If you however decide that you do not want to use git you can always send files
and patches directly to the mailing-list for review.

How to lower the barrier - plugins and videos

Hi all,

Recently we were contacted off list by someone who was attempting to implement
a plugin for GNUmed. Like many before him he had missed almost all information
available at in Wiki. After some pointers like the little series on plugins in
our Wiki it looked like he was on track. However despite initial success he
hit a road block when attempting to create a plugin. He was offered to send us
the problematic files but never did. We don't know if it was too much a
hassle. Initially you would think that documenting stuff in the Wiki, offering
direct help and more should be sufficient.

It is not I believe. Many people are used to solving problems on their own
instead of using the ressources readily available. That stems from the closed
source world where you would reinvent everything over and over.

Not all is lost however. We are missing two ressources I believe to give the
beginner programmer a chance. First is a set of templates. Second is a set of
videos explaining some concepts behind GNUmed. I have tried to solve the first
problem and have come up with a template plugin everyone can start off with.

I have them in my git tree and am currently learning how to share this work
through gitorious. I guess this will be another blog post. I hope Karsten can
chip in some information.

So far I have set up an account on gitorious. What now. Clone gnumed
repository ? Let's establish how merge requests and stuff works. If it works
out there will be a branch called template.

I suggest we ship those files in master as well so people pulling the
developer source tarball will have it as well.

Then the content in the Wiki needs to be updated to reflect how to make use of
the templates. The template files should be heavily documented in the code
itself and maybe will see a plugin or two appear.

Another thing I would like to see is a set of movies showing what one can do
with GNUmed. Those can either be rough demos or if you want to make the most
of it write a little script so everyone can follow the script and submit
videos.

GNUmed client 0.7.5 - call for testing

Hi all,

Please install and test GNUmed (its client and its server). The respective packages are gnumed-client and gnumed-server. The Personal Package Archive currently holds version 0.7.4. This is especially important for Ubuntu users since we are trying to get 0.7.5 into Lucid-proposed. I will try to upload 0.7.5 to the PPA today.

A Russian Ubuntu user (10.04) has reported a segfault when trying to start the client. We are not aware of any problems on the GNUmed side so any testing done by Russian Ubuntu users is very welcome.

We consider 0.7.5 a huge step forward compared to 0.6 which ships with Lucid. So your testing will directly make a difference for all current and future GNUmed users on Ubuntu.

More information is available at http://wiki.gnumed.de

Best regards,
Sebastian Hilbert
GNUmed Team

GNUmed 0.8 to be - in screenshots

Word of mouth has it that a release candidate of GNUmed 0.8 series is about to be released. From recent postings on the mailing list here are some bits we can expect:

In April 2010 arsten first mentioned vaccination handling and posted a screenshot:


Then on Apr 29th a pdf was posted showing of the improved current medication table in the LaTeX
format. This is now much more suitable for patients wondering how they should take their medication.

Beginning of May lab result plotting appeared:



Demographics editing was improved and a screenshot posted.



Still in May a more meaningful tooltip on the patient picture (it will show
the date the picture was generated) was announced.



Before the month was over this was announced :
This is the start of the third tab in the demographics
plugin, dubbed "Social Network", which is poised to become
the hub and spokes of the human network the patient is part
of.

Note that you can link a person within this same database
but you don't have to. You can also just write a comment in
the field below and leave the top line empty.

If there is a link to another patient it can be activated
from there straight away.

Also note how this screenshot nicely shows the tabbing
together of possibly unrelated windows into one "tab group"
-- one could imagine to tab together a few instances of
GNUmed or some such.



After improvement of the tooltip:


Then two days later progress on vaccination handling was reported:
This is GNUmed showing the (only but) latest Tetanus
injection Kirk got, right in the EMR summary. Next to it a
listing of his vaccination history ordered reverse
chronologically.

The "latest shot" logic will work correctly across single-
and combi-indication vaccines.

Note the new icon John provided.



For reasons not fully understood still in May ...

It's the little things that count:

Observe the Sum sign behind the indication in the EMR
summary vaccination list. It shows the total number of
vaccinations for this indication the patient has received.

A poor man's vaccination plan ... ;-)



An then some days ago (June finally) this appeared:

In the attached screenshot observe how the patient search
field tooltip shows the emergency contact for the patient as
well as the comment on this person.

Below the listing of drugs also note the "UAW" (German for
ADR) button which takes you to a (configurable) website for
reporting an adverse drug reaction.



In June the vaccination user interface was discussed again and the latest version was this:

Looks like this will be a feature packed release for the clinician. There now is a solid foundation for vaccination handling, medication lists, emergency contact handling and much more.

From the discussion it seems that a few more interesting goodies are in the pipeline.







* GNUmed client and server have once again be tested and made to work on the Mac OS platform
* GNUmed on Windows now installs and runs without ever installing python, wxpython or friends
* GNUmed bootstraping now works without ever installing python or friends
* Lx-Office/sql-ledger and ledgersmb have been identified as candidates for billing interfaces
* Preliminary survey data suggests that ICD-coding and billing are the most wanted features.

Join us for a discussion. Head over to wiki.gnumed.de or leave your comment here.

GNUmed Mac version - hardware needed

Initial tests indicate that the upcoming 0.8 version of GNUmed and the corresponding server part run on Mac OSX. But these tests were only performed on Tiger which is supposedly outdated. The GNUmed project does not have any Mac hardware available for testing. If you are interested in GNUmed running on that platform you might want to consider donating/lending the development hardware it can use for testing and developing.

GNUmed - job openings

This is not meant to be overly serious. However below is a bit of information what it would take to develop GNUmed from scratch. I encourage everyone to apply for one of these jobs. You will be reimbursed by the respect from your peers and the cosy feeling of having done the right thing.


GNUmed public relations manager

It will be your job to handle all kinds of communication with interested parties such as media, users, developers and either respond yourself or forward the issue to one or more people on the team that might handle the issue more profound. Furthermore it will be your job to research document and shape if neccessary the GNUmed project's visibility in media , search engines and user/developer communities. When new releases are made it part of the job to forward information or press releases to interested parties and parties that might have interest.


GNUmed wiki manager

It will be your job to document important information from all kinds of sources (e.g. design discussions on the mailing-list). You will be responsible for updating content as the need arises (e.g. new GNUmed release). It will be part of the job to work with the public relations manager and the IT-system administrator to keep the Wiki running and secure. This includes monitoring security related announcements. Furthermore it will be your job to initiate and work on improvements to the content and usability of the Wiki with regards to GNUmed users and developers.


GNUmed system admin

It will be your job to keep the infrastructure such as webserver, buildserver running. You will be responsible for security related issues and it is expected of you to initiate, plan and execute inprovements to the infrastructure.


GNUmed release manager

It will be your job to communicate with all parties regarding new releases of the GNUmed software. You will working with the PR manager and the system admin. It is your responsibility to ensure the availability of packages for all major platforms. You will be responsible for the creation and availability of demo media such as Live-CD, VMware images.


GNUmed webinterface developer

It will be your job to work with all other developers to develop a webbased interface for GNUmed. Preferred technologies are python based frameworks and a modern UI framework (e.g. AJAX, HTML5, no Flash). It is exprected that you have very good skills in python, Javascript, webframeworks or are willing to invest significant time into learning those skills in a reasonable timeframe. You will work with the interface designer to develop and deploy an interface that fits a physician's workflow.


GNUmed medical user interface designer

It will be your job to design medical user interfaces (web, fat client) that fits physician's workflow. You are expected to communicate with all developers including the webinterface developer and the core developers. You should have at least basic knowledge in python. It is expected of you that you have good skills or are willing to learn interface design and that you keep in mind industry standards.


GNUmed application developers

It will be your job to research , develop and deploy the GNUmed application. You will be responsible for creating , documenting and maintaining a solid database backend based on proved database technology (e.g. PostgreSQL). You will be writing code to abstract the user interface from the backend. It is essential for senior application developers to have excellent python, wxpython, SQL skills and a track record of active communication with all team members.


GNUmed application documentation manager

It will be your job to work with the developers and testing specialists to establish and keep up to date all programming information, guidelines, manuals. You will be working with users to find out what information is missing and you will be responsible for creating missing content. You will be responsible for setting up


GNUmed application testing specialist

It will be your job to establish a toolchain and testbed for continous testing of all aspects of the GNUmed application. You will be responsible for creating test routines and working with developers to turn test results into a better application.


GNUmed application support specialist

It will be your job to take care of the infrastructure to handle incoming support requests. You should furthermore have experience in triaging support requests and working with application developers and all other team members until an issue is resolved. It is part of the job to gather missing information and interact with the inquiring party until a solution has been found.

GNUmed translator

It will be your job to translate the user interface, the technical and user
manuals and the online content into a number of languages. It is part of the
job to work with users and developers to find the correct translation not only
literally but context-wise and language-specific

GNUmed on twitter and identi.ca

In those days it seems to be horribly old-school to follow the GNUmed website
by visiting its website or subscribing to a news feed. Even a blog is not hip
anymore. Well folks that is why you can follow GNUmed on twitter and identi.ca.
Be there when a new release is announced. Be there when the GNUmed devs
talk about upcoming features. Can't wait for an announcement to be made ?
Talk to us in the Wiki Live Chat.

All your social networking at your fingertips.

A question to the community

Hi all,

Jim's pointing to a thread from 2006 got me thinking. Here are some questions I
would like to throw at the subscribers of this mailing list or any reader of the blog post.

What is the state of GNUmed ?
What is missing and what is the feature that needs to be added before you will use it in your office ?
How do you view the work since 2006?
How do you see the concepts of GNumed ?
Do you care about the concepts of GNUmed ?

They say listen to the users. Here we are.

Sebastian

Billing for GNUmed - ready for action

The following workflow has been documented and is therefore ready for someone to implement

let GNUmed search for a client in the ledger application
if it exists open a browser and jump to invoice creation page
if it does not exist create it in the datbase and open invoice creation page
if multiple matches for client search term exist open browser and let user select the one
let GNUmed open a browser and jump to the "unpaid invoices page"

All info is at http://wiki.gnumed.de/bin/view/Gnumed/BillingLxOffice

Now it is only a question of implementing this. IOW someone has to code it.
Most of this is pure python. That means apart from creating a few menu entries
in GNUmed there is not too much GNUmed code involved. If you are going to
attempt this and need help with e.g. getting the current patient in GNUmed
just yell and let us know.

While this sounds overly complicated it is not. Even for beginners this is a reasonable effort.

All the nifty details like clean code, documentation etc. can be worked on after a first implementation.

Now it is up to you when GNUmed will have billing features.

Happy coding,

Sebastian

Billing/invoicing for GNUmed

There is an ongoing effort to provide some basic invoicing for GNUmed. Looking around
it looks like the packages sql-ledger, lx-office and ledgersmb will be evaluated. This is largely
due to the fact that ledgersmb and lx-office are forks from sql-ledger.

All three packages are webbased and written in perl. It seems possible to call functions not only
via the web interface but from the commandline as well.

This makes it suitable for GNUmed which tries to avoid implementing its own invoicing solution
and rather makes use of existing software.

A rough guide on what is planned can be found in the wiki at
http://wiki.gnumed.de/bin/view/Gnumed/BillingLxOffice

We need help with the implemenation. If you feel you could benefit from invoicing for GNUmed
please join the team.

We recommend you subscribe to gnumed-devel@gnu.org mailing list and introduce youself.
Any help is appreciated.