An openEHR database schema doesn't contain ANY archetypes - The data reflects the openEHR reference model, not the archetype model. If you have to hard code archetypes in a schema then you have not gained anything at all. The archetypes just describe what the data means.
A kind of analogy is that the openEHR reference model is like generic lego building blocks that of themselves don't describe anything. It just gives us the ability to build structures to contain any type of data. The archetypes are like the lego manuals that describe how to turn generic blocks into meaningful models. That means that we can describe a database schema once and never have to change it (unless the reference model changes) but still store any archetyped data that comes along. That means that in 10 years, I can create a new archetype about some new clinical concept and still store it and retrieve it using the same database schema. Hope this adds to the discussion... :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, 3 January 2006 4:08 PM To: General Practice Computing Group Talk Subject: Re: GP Requirements - was [GPCG_TALK] Re: The Dreaming Quoting Richard Hosking <[EMAIL PROTECTED]>: > Thanks Sam > > Gnumed is using PostgreSQL as a backend with an intelligent middleware > "broker" actually it's pretty dumb. IMHO bad design of the middleware is what's been slowing us down, which is why these discussions on a new backend are avoiding the actual problem and so slightly frustrating (but interesting all the same) > between client and DB which can be remote. no it can't. > The OpenEHR reference model and Archetypes could provide a rational > data model and DB schema. How much work would be involved in > converting these to SQL? Probably quite a lot. > I guess the simplest method would be to do it by hand for a set of > archtypes/structures that are sufficient for your record. Yes, however this has no compelling advantages over the current gnumed backend: why do the work again to end up in the same place? > It seems > overkill to write a program that will only need to do it once - or is > there a need for dynamic/runtime data objects - if so why? Yes, there is. The idea is to specify the data structure once, and then have the system autogenerate the middleware and backend code. Otherwise you end up with the current gnumed situation: having to write a datastructure in SQL, and then do it all again in Python (or whatever middlware language) There are 3 ways: 1- specify in Python (i.e. the middle layer) and generate backend SQL 2- specify in SQL and generate middleware 3- specify in a third language which then is translated into SQL and also runs the middleware. I'm not suire if OpenEHR is a 1 or a 3. Ian _______________________________________________ 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
