Re: [Gnumed-devel] re: sourceforge ldap

[Jim Busser]

On May 19, 2004, at 10:08 PM, Horst Herb wrote:
> ...Thus, you would of course run a local server for performance 
> reasons alone
> already, which then synchronizes in intervals with those others you 
> want to
> share data with. Synchronizing only certain categories (non-patients 
> for
> example) is an option.

I offer the puzzlement of the ignorant, in case I stumbled on anything 
that needs a decision, or merits clarification.

For the categories chosen to be run under LDAP (e.g. doctors), would 
the local LDAP server be the primary storage for gnumed data, or would 
the LDAP serve merely as an exchange device by which to bring data into 
gnumed's original tables, and to serve out an LDAP copy of any other 
designated gnumed data (maybe giving access, for certain outside 
doctors, to specific or general patients' demographic data) but with 
the "primary" data continuing to reside in gnumed's original tables?

If, in this discussion, the local LDAP serves only as a secondary copy 
of gnumed data (for LDAP exchange purposes) then the questions below 
are moot, but if LDAP is meant to serve ANY primary data repository 
functions for gnumed:

Would the entirety of the remote doctor data be copied/mirrored into 
the local LDAP server, or only those doctors who had been added on an 
incremental basis, each time they had been connected to a patient, or 
had needed to be looked up for some other reason?

Would the local LDAP server be configured to be able to be able to hold 
data not in the remote (source) LDAP server, for example a place to 
keep private info (special phone numbers or other info) that the owner 
chose not to contribute to the remote, general-use LDAP server.

Supposing doctor data were accessible from an outside LDAP server, but 
physiotherapist data were not, so must be added on an individual basis 
into gnumed. Into where? Into the same local LDAP tables as are used 
for the doctors? Otherwise would the personalia service need to be made 
more complex, in order to know that certain categories of personalia 
have their data kept in one set of tables, and other categories 
(including patients) in others? We already acknowledged that any one 
entity could BOTH be a patient AND have some other non-patient 
relevance to the practice. This  makes me think that all personalia 
data must be kept in a single set of tables - or is it in fact feasible 
to split up where personalia reads and writes data?

I am also thinking that one pathology/lab organization could make its 
branch information available via LDAP but others may not. If a mixed 
system requires personalia to look, read and write based on specific 
defined categories of personalia, then presumably the table set in 
which the data is to be contained must be all-or-none (i.e. not mixed) 
within the category.