Re: [Gnumed-devel] Re: database schema, was Re: LinuDent and tk_fp and odontolinux
Hi Andrew,
>> Not very useful, indeed (and not very original, either).
>
> However, it is premature to write off such an architecture as "useless"
Note how I said "not very useful" instead of "useless". The
one thing a minimalist table structure like this tells you is
that anything contained in this table is believed to be
medical knowledge by the person who entered the information
:-)
> The design challenge is to balance the flexibility with sufficient
> (but not too much) semantic "assumptions". In the OIO system, for example,
> we assume that the construct of a "form" (as in a paper form for data
> entry) is an useful _fixed_ semantic "assumption". So, yes, the form can
> contain various question items etc and thus it is flexible -
> but it is limited still by the "forms" structure.
So now I would like you to show me how this is fundamentally
superior (apart from being more convenient to the end user) to
defining additional tables in GNUmed.
> Agreed. However, my opinion is that the method for extending a schema is
> also an important design consideration. This is often overlooked.
True. However, are you talking about the method for effecting
a schema extension or the concept thereof ? The
method/mechanism sure is elegently solved in OIO. I fail to
see, however, the fundamental difference in principle to
GNUMed. Basically, both boil down to: "If what we have doesn't
fit your needs roll your own."
> We basically agree - the OIO design focuses primarily on
> _clean_ extensibility (with sufficient descriptive power, of course).
What do you mean by "clean" ? (Well, sorry, I used the term
first).
> How does GnuMed do the same?
It normalizes data into discreete tables as much as is
feasible. Agreed, this requires more manual labour than
designing a new OIO form. But this, in turn, facilitates more
careful thinking and raises emotional barriers to
free-wheeling table proliferation which I would expect to
happen within an active OIO community even locally unless
explicitely discouraged (which you don't endorse, AFAICT).
> The OIO system uses simple metamodels to describe metadata. For example,
> the metamodel for forms is (form, item, itemtype). All metadata (schema)
In GNUmed it is (table, attribute, attribute_type) where
"table" is supposed to model a well thought-out aspect of the
domain.
I don't think the difference is so much between GEHR/OIO and
GNUMed but rather between GEHR/Odyssee and OIO/GNUMed because
both of the latter lack what the former offer: true semantic
constraints on items (and, no, implicit semantics courtesy of
"I am a member of this form and thereby of this domain
snippet." does not count).
> are described using this metamodel. Because of the simple metamodel, it is
> easier to process, use, and re-use the metadata as plug-and-play
> components.
> How does GnuMed do this?
By way of business objects that talk to the appropriate
tables.
> I see it differently. There is no way for anyone (even you :-) to model
> any domain such that it is perfect for every situation. Even though you
> may feel that I shouldn't have to modify any domain schema, I may disagree
> with your conceptualization.
I wasn't thinking of the purely medical part of the domain but
I can't fail to disagree less.
> The question is : would you
> 1) prevent me from modifying the domain schema? or
No.
> 2) allow me to modify the domain schema? or
Yes.
> 3) help me create and modify the domain schema?
Depends.
> Since OIO forms are never mutually independent, any "form" will work with
> any other form!
To my understanding I can create two forms capturing
essentially the same range of data. They won't be
automagically aware of each other unless I explicitely make
them so. The same holds true for GNUMed tables. I can, if
semantically possible, always create a third mapper object
connecting the two tables/forms.
> What the OIO (and GEHR) systems offer is a way to manage the "two
> different tables" in a convenient way. :-) No more, No less.
Except that GEHR has built-in mechanisms for defining
constraints. Does OIO offer that, too ?
> I don't know what lieth beyond OpenEHR, but I do
> know plug-and-play forms are sufficiently powerful for many uses.
No doubt about that. I fail to see, however, where the
fundamental advantage of traditional tables is - apart from
convenience.
Regards,
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
To UNSUBSCRIBE, email to debian-med-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: