Re: database schema, was Re: LinuDent and tk_fp and odontolinux
On Wed, 17 Apr 2002, Karsten Hilbert wrote:
> [Andrew]
> > All software systems describe a certain data structure (if in database, it
> > would be a database structure). At some point, if we want to move
> > information between systems, we need to map one data structure to another.
> > I doubt implementing an all encompassing set of database tables will be a
> > viable solution. As Thomas Beale (GEHR) and I repeatedly stated in our
> > OpenHealth list postings, no set of database tables/schema will ever be
> > comprehensive. New medical knowledge will always need to be incorporated!
> I don't see how this argument is really valid or helpful. I
> can counter it easily with another equally invalid argument by
> showing you an all-encompassing table structure that is
> capable of holding the world's current and future medical
> knowledge, no matter what:
>
> table medical_data (
> item_id : serial primary key,
> ref_id : integer references medical_data(item_id),
> item_name : varchar,
> item_type : varchar,
> item_value: varchar
> );
>
> Not very useful, indeed (and not very original, either).
Hi Karsten,
You have presented a most compelling argument. Your example succinctly
illustrates the major architectual feature of all systems that attempt to
model "flexible" schema.
However, it is premature to write off such an architecture as "useless"
:-). 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.
In the GEHR system, the _fixed_ objects are archetypes and transactions.
> An actual schema does not need to be comprehensive let alone
> complete to be useful (this is, btw, your very own principle).
Agreed. However, my opinion is that the method for extending a schema is
also an important design consideration. This is often overlooked.
> Designed smartly (which we hope to do but, of course, we
> aren't total ZEN either...) such a schema is easily and
> cleanly extendable by additional tables with foreign keys (as,
> incidentally, OIO does to my understanding).
We basically agree - the OIO design focuses primarily on
_clean_ extensibility (with sufficient descriptive power, of course).
How does GnuMed do the same?
> I doubt there will be much difference between mapping of
> arbitrary (and hopefully well thought out) open schemata such
> as GNUMed's and less strictly predefined schemata such as
> OIO's.
The OIO system uses simple metamodels to describe metadata. For example,
the metamodel for forms is (form, item, itemtype). All metadata (schema)
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?
> > Sharing the DB is a good idea. However, is the DB schema easy to extend
> > and manage over time? For example, if I take the GNUmed DB and modify a
> > few of its tables (e.g. for psychiatry),
> If you have to do that (modify, that is) we screwed up. You
> shouldn't have to.
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.
The question is : would you
1) prevent me from modifying the domain schema? or
2) allow me to modify the domain schema? or
3) help me create and modify the domain schema?
Being open source, GnuMed would probably not be #3.
I suspect it is more like #2.
OIO is clearly #3 (where we don't even attempt to supply any
domain-specific schema :-).
> > How do I make sure
> > what I added will work with other people's ideas for describing
> > the psychiatry domain?
> You don't. And incidentally you don't enforce that with OIO
> either lest you explain me how.
Since OIO forms are never mutually independent, any "form" will work with
any other form!
> The same way there could be two different tables describing a particular
> psychiatric aspect from two points of view there could be two different
> forms in OIO covering the same range of data. They aren't automatically
> compatible either. Both are, however, "compatibable".
Two different forms covering the same range of data will not interfere
with each other. It is no different from having two different "tables".
What the OIO (and GEHR) systems offer is a way to manage the "two
different tables" in a convenient way. :-) No more, No less.
> Nevertheless, Nirvana shall eventually be reached by walking
> the One True Path, that which lieth beyond OpenEHR.
My hope is that what we have accomplished with the OIO project will be of
use to GnuMed and others. I don't know what lieth beyond OpenEHR, but I do
know plug-and-play forms are sufficiently powerful for many uses.
Best regards,
Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org (Hosting OIO Library #1)
--
To UNSUBSCRIBE, email to debian-med-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: