Re: [Gnumed-devel] forms handling / NetEpi

[Karsten Hilbert]

On Wed, Jun 20, 2007 at 05:59:42AM +1000, Tim Churches wrote:

> > How do we handle form filling from within GNUmed for those
> > forms which are not to be edited inside OOo ? For that one
> > would want a GUI generator which creates a UI mask from a
> > definition of fields.
> > 
> > Tim, how is this (conceptually) done in NetEpi ?
> 
> Yes, we use a custom XML schema to store all necessary metadata about
> each version of each form. The XML definition is stored in the database
> and read whenever the form needs to be instantiated for editing patient
> data.

I will review the NetEpi code within the next few days.

Tim, what were your reasons to store the form definition as
an XML-based blob rather than in tables (roughly) like so:

create table form_definition (
        pk serial primary key,
        form_name text,
        form_version text,
        background_image bytea
);

create table field_definition (
        pk serial primary key,
        fk_form integer
                not null
                references form_definition(pk),
        name text,
        type text,
        tooltip text,
        placeholder text,
        position_on_screen point,
        position_on_target point
);

In GNUmed we currently have tables like this but haven't
deployed forms handling yet so I would like to learn the
relative merit of both approaches.

One advantage of the table over the XML blob is that form
data tables can reference the field definition:

create table form_instance (
        pk serial primary key,
        fk_form integer
                not null
                references form_definition(pk),
        date timestamp with time zone
                not null
                default now()
);

create table form_field_data (
        pk serial primary key,
        fk_form_instance integer
                not null
                references form_instance(pk),
        fk_field_definition integer
                not null
                references field_definition(pk),
        value text
);

which alleviates the need for ...

> one for each version of each form, which are created via SQL table
> creation and modification statements when a new version of a form is
> "deployed".

... this. We have only one table for all the form data.

One disadvantage for this is that the table might become
large and thus slower. Which could be alleviated by using
constraint-based partitioning (eg by age) and putting the
partitions onto more spindles.

> Data from the table for the previous versions of the form
> are rolled forward into the table for the new version of the form when
> it is deployed.
Nice. A table-based roll-forward.

Looking forward to your comments !

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