Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 91, Issue 51

[Sebastian Hilbert]

Am Sonntag 27 Juni 2010, 20:15:17 schrieb richard kim

HI Richard,
:
> Hi.  I am new here, so take these comments for what they are worth, and I
> apologize ahead of time for any ignorance.

Thanks for taking the time to comment.

> 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.
> 
What happened. Can you report on any specific issues with web interfaces ?
What the interface an issue in your attempt to create your own emr ?

> 
> 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. 

We tend to say that setting up the emr fat client is a) fairly easy for GNUmed
and b) can/should be done by a support company because they are trained to 
do that. the only reason why people don't like to hire professionals is that 
the ones you hire are either not professional or like to charge a lot of money

> The demo is always good, but as you mentioned, it is very slow, and not a
> great example of GNUmed's ability. 

Well. If more people around the world would set up a public GNUmed database
it would be faster. It is not that slow from Germany because the server is
in Germany. I agree that it being slow is bad.

> 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. 

Well. I am not sure about that. The physicans I know don't care about the 
technology as long as it works. If you give them fast client that are fast on 
the local area network they are just as happy. Webinterface have their
drawbacks such as problems with accessing devices such as card readers, 
cameras, scanners and so on.  A mix of fat client and web might be a solution.

> It also opens up doors to other aspects, like
> patient portals,

I am a fan of these use cases as well but at least here in Germany patient 
portals have been a huge failure. Patient tend to give a s***t about their 
health let alone use some internet stuff to manage it.

> sharing amongst physicians at different offices,

This has little to to with web interfaces. I have a pretty good framework in 
my head how this is going to work through Jabber. THis is more
dependent on a data exchange protocol.
> and use
> at home -- without VNC, NX, or any other remote network additions.

This is a point I agree with.

> 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.

I agree.

> 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.
> 
I agree but there are some things that are hard to do in a browser. See above.

> 
> 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? 

I am not exactly sure what you mean. Please elaborate. One important feature 
that every framework needs to support is to reuse the GNUmed backend and 
middleware. I am not interested in recreating all the database stuff with a 
python framework.

> Do you really have to be sure to install
> your EMR with different database management software? 

No. All I want it PostgreSQL but this is handled by gmPG2 and psycopg2 and 
nothing else.

> If so, then I would
> understand.  But if not, it would seem that a lot of work would be already
> done by these frameworks. 

Those frameworks often try to fit all use cases. I just want to use tested and 
proven code of the GNUmed middleware. When this code is enhanced for the fat 
cleint the web client will automatically benefit.

> 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.

I don't know those frameworks enough but for now I don't want to write extra 
code and I trust that the security GNUmed has now is sufficient. I have yet to 
look into how the current security model can be reused by the webinterface. 

> Example, Ultimate EMR is built upon Plone.

I have looked at UltimateEMR. I know little about it. I hope they succeed in 
what they are doing and I sure will look at their code but I want to write as 
little code as neccessary and reuse as much from the current GNUmed code as 
possible.

> 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 sure I understand. The backend and the middleware will hopefully be 
lifted from GNUmed. I don't want any toolkit to mess with table creating and 
data writing . This is entirely up to the GNUmed middleware. All I want is 
fany web user interface. It would be the same if I throw out wxpython and use 
PyQT. Just substitute wxpython by your-AJAX-GUI-here.

> 
> 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. 

That is great. We are always looking for fresh input that will challenge our 
rusty thinking. Bug us with arguments any you might see some things change.

> 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.

I am nor sure I share that conclusion. I would only throw out the UI code 
(wxpython) and replace it by AJAX-UI code. The question has been which 
framework lets me do that.

Sebastian