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.
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.
2 comments:
Yes, i'd say that pyjamas is the best tool for the job: in this particular case for a number of reasons.
the application you're looking at is designed along MVC lines, already. http://puremvc.org can be compiled by pyjs to javascript, along with the rest of the application... but it will still function as a python desktop application should you so wish. WITHOUT needing to modify the original python of the application.
Hi Garfield,
Nice to know that you like OpenEMR. Hopefully GNUmed and openEMR will be able to exchange data some time.
Post a Comment