Karsten Hilbert wrote:
5) We develop a "form" to be stored in our forms schema which
doesn't get printed or mailed or anything. Disadvantage:
I am not convinced this is technically sound. I do favour
this approach.
Instinctively this is what I would prefer too, but I see why
there are problems.
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.
Conceptually, if we have "proper" tables for family history and so many other
things, I don't see why we can't have tables for referrals,
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?)
Certainly in AU interesting possiblities arise when referrals, etc., are in
proper tables.
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.
This would imply a column in form_defs
destination_table name, -- the name of the table storing this forms
data.
This is not OIO: we still want "hand-rolled" GUIs for a lot of stuff
(scripts the classic example) where we want "magic" features, but
for Well's score and many others it should suffice.
Ian
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel
