[Gnumed-devel] Re: workplace in tarball

[Jim Busser]

back onto the devel- list :-)

On 22-Jul-09, at 2:08 PM, Karsten Hilbert wrote:

Also, [if a workplace was renamed in the backend] all

[of what would have been the now-seemingly-missing]

workplaces' config items in the database will have gone back

to hardcoded defaults [under a workplace regenerated to fill the void].

All those [configs] that are linked to that workplace in the database (nearly

all of them). Say, temp dir, deletion age of empty encounter, encounter time to live, etc etc.

This is a revelation to me that these configurations are able to be stored and invoked differently in different "workplaces". I thought these were all single-setting-per-site.

Maybe temp dir makes sense to store within workplaces, where the aim might be to write temp files into a shared (server or local drive) directory where the workplace is invoked by more than {one user, from one machine}.

Is it clinically reasonable though, within a single praxis, to maintain multiple different parameters which (inconsistently) define how short or long should be intervals that define clinical activity as belonging to the same or different encounters, or at what point to call episodes "dormant", based on more than one workplace which different clinicians may choose?

It seems to me that the consequence will be that even within a single user (if they would ever use more than one workplace) they risk being inconsistent with *themselves*.

I could understand heterogeneity in the configurations based on *type* of encounter and maybe by user (where "A" is satisfied that a problem after 12 months is dormant, whereas "B" is satisfied after 6 months that it is dormant) if we will ignore or the moment the effects when within a praxis user A and B provide bridging care to each other's patients.

 

The above is the discussion that is now more of interest, since the problem of retiring "GNUmed default" is a non-problem. Simply define "Local default" to be the 0.5-forward default when no workplace has been named. If we do not bother to rename GNUmed default in the backend as part of the v10 --> v11 database upgrade, then anyone who already had a GNUmed default would retain it, and lose nothing unless they had removed

name = GNUmed default

from their config file in which case they will get a "Local default" with the hardcoded settings which they can either modify or go into .config and exercise their preference to get back the "GNUmed default" whose disappearance they themselves would have had to cause.