gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] wells score - how to store it ?
Date: Thu, 31 Mar 2005 18:03:37 +0200
User-agent: Mutt/1.3.22.1i

> In fact, OIO uses a separate table for each version of each form you
> define. OIO uses a generic table to hold metadata about each field on
> each form, but the actual data for each form is held in its own table.
> NetEpi Case Manager does the same - it uses one table per form version,
> but we store the form and form field metadata in Python objects (which
> are stored in .py files currently, but in XML files in the version after
> next). We also plan to decouple forms from tables somewhat, and to
> roll-forward and consolidate data stored in previous versions of forms
> in the latest version.
We mix both approaches.

We have tables for

a) versioned form templates + template metadata
b) field definitions linked to templates
c) form instances linked to form templates
d) form field data instances linked to field defs

All audited, of course.

We then have Python classes that operate on types of form
templates. I guess we could write a class to generically
(albeit quite logically not efficiently) display some sort of
GUI for *any* form definition.

We can have specialized Python child classes implementing
logic inherent to one particular form template version.

I do like Ian's suggestion of having form template (version)
specific child classes of the generic GUI generation class in
order to efficiently support forms where neede.

Anyone see any holes in this arrangement ?

> The process of versioning and deploying
> user-defined forms in a multi-user system is the hardest thing to get right.
Agree. The one horror that must be avoided by the very first
implementation of our forms layer is that form templates may
get overwritten and old data made inaccessible therefore. I so
detest that and it happens in every single commercial EMR I
have to use ...

> For storing small numbers of records, as in GNUmed,
Small numbers of records ? Where does large begin ?

> the more flexible
> EAV (entity-attribute-value) model would be worth considering.
Given the above don't we do that although fleshed out quite
a bit ?

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]