gnumed-devel
[Top][All Lists]
Advanced

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

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


From: richard terry
Subject: Re: [Gnumed-devel] safe handling of end-user extensibility
Date: Thu, 12 Sep 2002 14:58:29 +1000

I'd agree option 3 seems the best, but then I don't profess to be technical.

Also I always prefer human_readable stuff ie:

> 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 ?
variables


On Thursday 12 September 2002 2:09 pm, you wrote:
> 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




reply via email to

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