gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] history types (was: little project for non-coders)


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] history types (was: little project for non-coders)
Date: Tue, 14 Dec 2004 11:05:45 +0100
User-agent: Mutt/1.3.22.1i

> I can collate any others' responses, posting to the wiki once it is up.
That would be excellent. I should point out that Liz once
posted a list of what she frequently assesses as far as social
status is concerned. This list should be found in the
archives.

> I gather the intent is to populate:
> >comment on column clin_item_type.type is
> >     'the full name of the item type such as "family history"';
> >comment on column clin_item_type.code is
> >     'shorthand for the type, eg "FHx"';
Precisely !  :-)

> .. probably the codes should wait until the list stabilizes
I am OK with that.

> Some of types may overlap (e.g. are risk behaviours part of "Personal 
> history"?)
They can, no problem. "Smoking 2 packs per day for 10 years"
both carries the fact of "Habit::heavy smoker" as well as
"Personal history".

> Anyone yet know of these are defined in any standards pertinent to 
> interoperability?
Not to my knowledge. One might best look in the vicinity of
ontology/terminology efforts.

> Should bootstrap items be limited to those on which we have total agreement?
Not necessarily. Just a decent subset of common *appeal*.
They'll have to be changed for other languages anyways.

> Some of the following, arbitrary ideas raises the issue of "nesting". 
Down that path great complexity lies.

> Maybe preferable to design "flat" but in order to remove the 
> "parents", the "children" might need to be adequately comprehensive.
The possibility to attach as many types as wanted allows us to
attach coarse and fine grained type levels in parallel without
needing to bother with interconnecting them which can be done
outside the scope of them being connected to a clin_root_item.

If we do want to *encode* nesting arbitrarily constraining
ourselves (in data, not in concept) greatly helps reducing the
towering complexity issues.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]