|
| From: | richard kim |
| Subject: | [Gnumed-devel] Re: Gnumed-devel Digest, Vol 91, Issue 51 |
| Date: | Sun, 27 Jun 2010 11:15:17 -0700 |
Hi. I am new here, so take these comments for what they are worth, and I apologize ahead of time for any ignorance. I, with a group of friends, tried to start an EMR project of our own, but it fell apart completely. I hope to share my opinion from my experiences.
My personal bias is that a web interface is essential, and even a preferable means to access an EMR. Setting up a server-fat client model can be difficult for physicians, even just to experiment and test the product. With that being the case, the barrier to new user entry goes up. The demo is always good, but as you mentioned, it is very slow, and not a great example of GNUmed's ability. A web interface is easier for users to access, and is a lot more familiar (ease of use). That goes a long way with customers/users. It also opens up doors to other aspects, like patient portals, sharing amongst physicians at different offices, and use at home -- without VNC, NX, or any other remote network additions. Many things are built into browsers that are familiar to physicians already: printing, changing font sizes, tabs, and many more depending on what you want to do. You do not need to recreate these, as you do on fat client applications. Finally, the web interface does not need to work with all browsers equally. It is a web application, not web site. If internet explorer does not work well with your web application, I would think it is okay to not support it, and just be up front about that.
Also, I would ask why you do not want a framework that tries to be a complete solution. You may not have the flexibility, but is that flexibility really necessary? Do you really have to be sure to install your EMR with different database management software? If so, then I would understand. But if not, it would seem that a lot of work would be already done by these frameworks. I would think it would save a lot of time/man power, while at the same time, maintenance and security is usually built into those platforms already. Example, Ultimate EMR is built upon Plone. Without having expertise in the toolkits mentioned, adding an extra toolkit on top of the existing project seems like it could be open to a lot of unforeseen problems in the future.
I am not a programmer. My python knowledge is rudimentary, and _javascript_ is trivial. So take these comments with a grain of salt. I have been working more on the UI end. From that perspective, and my biased view, I consider a web interface important, and using a preexisting framework would be very helpful in the long run, but it also might mean throwing out a lot of current code, and I'm not sure if that is the best idea either.
Richard
Send Gnumed-devel mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.gnu.org/mailman/listinfo/gnumed-devel
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gnumed-devel digest..."
----------------------------------------------------------------------
Message: 1
Date: Fri, 25 Jun 2010 19:14:04 +0200
From: Sebastian Hilbert <address@hidden>
Subject: [Gnumed-devel] GNUmed web interface - when easy is not so
easy after all
To: GNUmed list <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
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
| [Prev in Thread] | Current Thread | [Next in Thread] |