[EMAIL PROTECTED] wrote: > > Quoting David Guest <[EMAIL PROTECTED]>: > >> > > I had a bit of time over the Xmas break, and did the Ruby on Rails > > tutorial (dead easy Windows tute at onlamp) and then started on the > > Ajax > > on Rails. The upshot of all this is that we will have to rethink about > > the way we handle web data and interactions and hence all medical > > communications. I now know what you, Tim and Horst were referring to > > earlier. Unfortunately only a few others do. > > 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.
It is worth pointing out that these object-relational mappers use dynamic generation of SQL, not static, is being to store the data for instances of classes in an SQL database. Thus new instances of these classes (eg a patient class) can be created and related to instances of other classes (eg a doctor class or a medication class) on the fly and all the necessary SQL is automagically generated just when it is needed. > From there stems their limitation, "portable SQL" (read: we stick only > to the > MySQL featureset as lowest-common-denominator), which is an unacceptable > hobbling from the gnumed perspective. These object-relational mappers (ORM) don't HAVE to use teh lowest common denominator. For example, the ORM in NetEpi CaseMgr is targetted at PostgreSQL and makes use of POStgreSQL transactions to help ensure data integrity. > Currently I'm looking at going the the other way (defining the schema in > postgres and then auto-generating python objects) as a way out of the > current gnumed woes. It seems to me to be much nicer to use Python to create instances of various classes for patients, docs, meds, visits etc etc and to have the data storage look after itself in the background via the ORM than to start with a hand-written relational database schema and work from there forwards. I'd rather write Python than SQL. Even better, I'd rather point-and-click on something which calls Python behind the scenes to create class instances and thus teh database tables and SQL code. > Also, I have finally found a coherent exposition of the google select > system: > http://www.dcs.lancs.ac.uk/~grill/mgbox/ > (people are running around calling this technique "Ajax" like it's God's > gift, > IMHO we should call it "Javascript finally doing something useful") Very useful link, thanks. > It means a usable web-based EHR is now on the horizon, although I'm > not sure we've arrived yet. I think that to do a good Web-based EHR, we need to write down the requirements, distill the lessons learnt from GNUmed, MD2 etc etc, pick the best toolset (probably Python, PostGreSQL and various Python libraries for doing AJAX-enabled Web apps) but otherwise start with a clean sheet of paper. Trying to adapt GNUmed, VistA or anything else may be more trouble than it is worth. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
