gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Re: schema changes requested


From: Ian Haywood
Subject: [Gnumed-devel] Re: schema changes requested
Date: Wed, 30 Nov 2005 17:24:34 +1100
User-agent: Debian Thunderbird 1.0.7 (X11/20051017)


Ian Haywood wrote:
> I would like to request some schema changes
> 
> - forms_data seems to double up with the fields of 'real' tables that hold 
> this data
> such as referral, lab_request, medication, etc., I would get rid of it.
> Instead each of these tables links to form_instances
> with the data in form_instances and the fields of the table the form can be
> re-created and re-edited as required.
Hmm, that creates a problem when the user prints something then changes the
clinical table. The old values will be there in the audit tables, but we can't
link them to the form.

How about
create table clin.form_instances
(
        pk integer primary key,
        fk_form_def integer references form_defs (pk),
        form_name text,
        source integer references clin.clin_root_item (pk_audit)
);

This has the advantage that
        - clin_root_item descendants don't need explicit links
        - one clin_root_item can have several forms printed off it,
we can still guarantee we know the contents of the row (and hence the form)
at the time of printing.
This means forms can't have user-defined fields: fields must be 'real' fields
in a SQL descendant or derived from them by the business object.
I wouldn't make form_instances a clin_root_item or even auditable as these 
things
are redundant: this table isn't meant to be updated and is always linked
to a clin_root_item.

The exception is if we want to use the forms layer to print statistical reports
(i.e as part of t=a billing module) In this case we would use a "non-clinical"
equivalent of form_instances.

Ian


Ian H




reply via email to

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