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: Tim Churches
Subject: Re: [Gnumed-devel] wells score - how to store it ?
Date: Mon, 28 Mar 2005 19:52:20 +1000
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Karsten Hilbert wrote:
> 2) A dedicated table stores what the widget gathers (much like
>    family history) and stores a summary narrative line (see
>    above). Disadvantage: We would start accumulating lots and
>    lots of similar tables for Mini Mental State, etc etc
> 
> 3) We develop a generic table structure to store such things
>    and place a narrative line in the notes. Disadvantage: We
>    would duplicate/rewrite OIO (and our forms layer).

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. The process of versioning and deploying
user-defined forms in a multi-user system is the hardest thing to get right.

For storing small numbers of records, as in GNUmed, the more flexible
EAV (entity-attribute-value) model would be worth considering.

Tim C




reply via email to

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