Re: [Gnumed-devel] wells score - how to store it ?

[Karsten Hilbert]

On Mon, Mar 28, 2005 at 07:16:15PM +1000, Ian Haywood wrote:

> BYW, we could still use the form template: to generate a
> pretty description of the form data to put in clin_narr:
> i.e "Well's score 10: DVT likely", or whatever.
Sure that'd be a neat and clever way for formatting.

> Conceptually, if we have "proper" tables for family history and so many 
> other things,
Well, we have "proper" tables for things that are *fundamental
data types* for GPs. Wells Score is neither a "data type" nor
fundamental (eg it does not feel bad technically to just write
it into a sOap line).

> I don't see why we can't have tables for referrals,
Yep, we are likely to have a dedicated table for the *entity*
referral. However, a possibly used *form* associated with that
entity will live in the forms part of the schema. Same with
prescription vs. current medication list.

> Well's score, MMSE, etc. Yes we will have heaps of tables, but it's
> not as if postgres can't cope (is there even a set maximum number of 
> tables?)
AFAIK there is and it is so remote (something 2^<two digits>)
that the developers went to the fun of affording a dedicated
error message.

> Could we have a "multi-valent" business object which can hold a row
> from any of this form tables, and provide enough field meta-data to allow
> basic form GUIs to be auto-generated.
Sure, that's what I was referrring to in that other post. What
this would mean to users is this: They can generate a template
for a new form, use it with the generic UI generator and wait
for a better/dedicated UI to emerge. Nice :-)

> This would imply a column in form_defs
>       destination_table name, -- the name of the table storing this forms 
> data.
Not necessarily. I think we can achieve the "generic" form
object without the need to resort to dedicated forms tables
sprouting like mushrooms.

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