Quoting Tim Churches <[EMAIL PROTECTED]>: > 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. It's mainly postgres inheritance that we would miss, also server-side triggers and views. Inheritance you could model in an ORM, but the others would get tricky.
Of course, you don't need them if you keep the backend to static data storage and put all the business logic in the client. gnumed was originally concieved as "smart-server, dumb-client" model, with backend triggers doing all kinds of high-level stuff, like interactions checking. We strayed away from this and IMHO that's (partially) why things got messy, the client is too smart and complex for it's own good. > > 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, OK, so my above these points are academic in a Web-based model as the database 'client' is on the server anyway. > 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. Web is always tempting, but we need to be honest in our motives: it's a shitload easier to develop and deploy, but we need to look closely to see if web can meet our non-structural requirements, particularly high data-entry speed and mouseless navigation, personally I'm still somewhat sceptical. Ian _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
