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 rendering is left to the operating system and underlying GUI toolkit. However providing the underlying toolkit on many operating systems and window managers is no
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
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
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 soundy. 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
Pyjamas to the rescue.
While reading up a lot on web application developement 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.