gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Past History Comments (was 1.2.3.....)


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Past History Comments (was 1.2.3.....)
Date: Wed, 24 Nov 2004 13:42:23 +0100
User-agent: Mutt/1.3.22.1i

> >We should perhaps derive a new table from clin_root_item
> >called past_history that has dedicated age/unit fields.
> >Entries in that table would then be attached to health issues
> >which would somewhat clean things up on the backend. Comments
> >there ?
> >
> it's a bit fuzzy what should go on past_history and what's on clin_diag
a) there is no past_history yet
b) entries in past_history needn't be diagnoses just like
   health_issues needn't be such
c) clin_diag is nothing but a factored out form of a 
   clin_narrative.is_diag field allowing for convenient
   linking of fields pertinent to diagnoses only (laterality
   etc)

What would be a less fuzzy way to group between past_history
and clin_diag and health_issue ?

> I'm assuming there'd be only allowed one past_history item per 
> health_issue, otherwise the grouping of the other clin_root_items
> would be difficult.
That sounds very reasonable. In fact, I wonder whether a
past_history table shouldn't hold details linked to
health_issues just as clin_diag does with clin_narrative. Hm,
but then one couldn't declare a past_history detailed
health_issue to be a diagnosis. Darn.

> >Any number of clin_narrative rows can be attached to the
> >clin_health_issue. The frontend could scan for particular
> >types of clin_narrative rows and display them as Notes.
> a type field for clin_narrative?
No. Use linked types.

> BTW, is is_episode_name really needed? Why not just a non-mandatory 
> field on clin_episode?
If you want a clin_episode.name field: We just moved away from
that in the last two weeks. If you want a
clin_episode.fk_narrative_as_name foreign key, well, where's
the difference, really ? Hm, maybe the difference is in easier
handling. Will take a look although I don't like the circular
foreign key.

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]