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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
