"unless the reference model changes" - this assumes that the reference model is as perfect as it gets ; if the
reference model was called "posix" maybe it wouldn't change, but clinical metamodels aren't as important as operating
system interfaces, it seems. What you really need is a critical mass of dependency - once enough stuff is dependent
on the reference model, then maybe it won't change.
On Tue Jan 3 10:27 , "Hugh Leslie" sent:
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] [[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
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
