Dr John Van Dyck <[EMAIL PROTECTED]> wrote: > > Answered in my last post???
Any specific lessons about Web-based EHRs to be learnt? Perhaps we should be precise, and differentiate problems with (Web-)browser-based applications per se (including those hosted on local servers on a LAN) from problems due to latency and bandwidth issues for browser-based applications hosted over the Internet. Tim C > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Tim Churches > Sent: Friday, 30 December 2005 10:54 AM > To: [EMAIL PROTECTED] > Cc: General Practice Computing Group Talk > Subject: Re: Re: [GPCG_TALK] The Dreaming > > [EMAIL PROTECTED] wrote: > > > > Quoting Tim Churches <[EMAIL PROTECTED]>: > > > > > David Guest wrote: > > > > [EMAIL PROTECTED] wrote: > > > > > > > >>I agree. I have also been looking at Rails and it's python > > equivalents, > > > >>the breakthrough seems to be auto-generating SQL from Python/Ruby > > template > > > > > > >>classes. > > > >> > > > > > > > > Fan django? > > > > http://www.djangoproject.com/ > > > > > > Not nearly as cool a name, but TurboGears may be an even better > > > prospect, especially the forthcoming v0.90 release: > > > http://www.turbogears.org/ > > I agree this does look very appealing > > Note this isn't inconsistent with still wanting a handwritten backend > > (http://sqlobject.org/SQLObject.html#automatic-class-generation) > > > > SQLObject does allow arbitrary joins etc., which is good, but the code > > > looks > > pretty ugly: > > from sqlobject.sqlbuilder import LEFTJOINOn > > MyTable.select( > > join=LEFTJOINOn(Table1, Table2, > > Table1.q.name == Table2.q.value)) > > > > I'm not sure this is any better than a backend view, (and slightly > > slower.) > > But I take Tim's point about putting all the logic in one layer in one > > > language. > > Yes, I think that it is possible to create better ORMs than SQLObject, > for > specific purposes. For NetEpi, we plan to extend our current custom ORM > (which is PostgreSQL-specific and makes good use of the features > provided by > PostgreSQL, especially transactions and views, but not inheritance or > triggers). Likewise, we plan to stick with Albatross as the Web > framework/templating system, not CherryPy and Kid as used by TurboGears. > But > we do hope to leverage Mochikit, which is the Javascript used by > Turbogears > to provide AJAX capabailities and other browser-side tricks. > > > With Web interfaces, would it really fly? > > If the Web server is on the LAN within the practice, accessed via > 100Mbit/s > Fast Ethernet (or even 10Mbit/s Ethernet), and the Web apps runs as a > persistent process on the server (without the old CGI > set-up/tear-down-with-every-interaction overhead) then Web apps can be > every > bit as fast as a GUI. > > The same applies if the app is hosted on a remote server to which there > is a > fast, low-latency braodband connection. But you do need to make sure > that > the Internet connection will always be fast - and it is very difficult > to > ensure that. Otherwise there will always be occasional but annoying > delays > while some other person on the ISP network segment as you downloads a > pirated movie or something. > > But a $1000 machine or two is all that is needed to run a Web/database > server in each practice, and with Slony it is easy to automatically > slave to > an off-site back-up database somewhere, for continuous off-site back-up > and > instant recovery. > > > I'm addressing this to those running practices: if > > it could be made fast enough with all the features like > auto-completion > > and a > > WYSIWYG editor, is this something you would actually be prepared to > use? > > There are several open source Javascript in-browser editors available, > but I > haven't investigated these to determine how good they are, or how hard > it > would be to make them support smart text wrangling eg on-the-fly > auto-completion or mnemonic/abbreviation expansion. Otherwise > browser-specific plug-ins or an embedded Java app might have to be used. > But > you can do hell of a lot with Javascript these days. > > > We don't want to end up like a certain other web-based EHR (nat-div > > subscribers know want, or rather, who, I mean ;-) > > Huh? Which one? What? Prey do tell, it could be instructive. Don't > mention > names if you prefer, but give us the gist of it, the take-home message > of > what can go wrong or what not to do. > > Tim C > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
