|
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
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 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
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 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.
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.
Best regards,
Sebastian
|