[Gnumed-devel] safe handling of end-user extensibility

[Karsten . Hilbert]

Dear all,

I need some advice regarding the following problem:

Several places in GnuMed (will) allow extensibility by the user. A concrete
example would be the type of stored medical documents. We will have some
types provided by the default installation as examples but many sites will
categorize documents themselves.

How do we allow for this extensibility without incurring a maintenance
nightmare ?

There's several more or less ideal solutions:

1) having a table doc_type and leaving it to people to deploy their own
document types at will - this will make merging data from different sites less
than desirable, it will also bring up the danger of overwriting carefully
thought out schemes by a careless update of the GnuMed system defaults

2) saying that doc_type.ID < 100 is reserved for system defaults - this
works, is based on convention, has the potential problem of overflow (what
happens if we _should_ hit the limit for system defaults ?) and still needs 
careful
updates not loosing doc_type.ID > 100 when updating system defaults

3) going for the full monty with tables doc_type_sys and doc_type_usr the
latter of which is arbitrary to the site and will never be touched by updates
(unless the table structure _needs_ change) - this would need more code but
has the cleanest separation of user level customization from system defaults
without fear of overwriting (which is an absolute no no)

Version 3 feels technically cleaner to me. I don't really mind writing the
bit of extra code. It still does not solve the merging (think of a "message",
not a total merge) issue.

Along the same lines is there a _real_ advantage to using symbolic IDs
instead of numeric ones ?  "usr_referral_ENT" and 
"sys_discharge_summary_surgery"
as opposed to 513 and 15 ? Or is this just a virtual benefit of a better feel
for human beings ?

Comments on this greatly appreciated.

Karsten

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net