gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] re: sourceforge ldap


From: Horst Herb
Subject: Re: [Gnumed-devel] re: sourceforge ldap
Date: Fri, 21 May 2004 09:04:58 +1000
User-agent: KMail/1.5.9

On Fri, 21 May 2004 02:59, Jim Busser wrote:
> 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?

We have the concept of "data services", which really are nothing but remote 
procedure call interfaces to domain-specific functionality. What happens 
behind the API is irrelevant to the connecting client.

Hence, you should be able to chose to administrate your demographic data via a 
LDAP based data storage, OR via storage in your own Postgresql tables, OR by 
connecting to a governmental demographic database (as it exists for example 
in Norway). I don't think there would be any point in importing *all* data 
from an LDAP server into local tables, but for some LDAP functionality might 
help in the sense of "white pages" to look up addresses that don't exist 
locally yet.

Horst




reply via email to

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