[Gnumed-devel] Integrating LDAP

[Jim Busser]

I have been learning about LDAP, in part courtesy of a helpful link 
http://www.ldapman.org/articles/index.html given previously by Tony 
Lembke

Scenario:

- suppose one's regional doctors' licensing body offers, via LDAP, data 
on on several thousand doctors
- suppose patients in the practice have had contact with only 300 of 
these doctors

Options:
1. GNUMed queries the LDAP each time, storing only the doctor's LDAP 
Distinguished Name (DN)
2. GNUMed queries the LDAP each time, but maintains a copy of the data, 
refreshing it as required
3. GNUMed maintains and uses primarily its own data, and accesses the 
LDAP:
-- when the desired doctor is not already "in" GNUMed
-- on demand (letter returns undeliverable; phone number is non-working)
-- automatically at intervals (doctors last updated more than x time 
ago)

As the LDAP server will in this case reside beyond control of the 
GNUMed practitioners and could at least briefly become unavailable 
then, at minimum, the practice should maintain, at all times, at least 
a copy of the doctor information. Option 1 is presumably "out" as a 
"bad idea".

However, as it is not unusual nowadays for doctors to change their 
phone info, their office location within one urban area, or to get 
itchy feet and thus even move away completely, and as these events are 
unpredictable, should the LDAP be accessed with each and every doctor 
access? Once a day? Less often? Is it the sort of update one would want 
GNUMed to do in a scripted fashion as is done with cron scripts etc, 
"pulling" updates on a selection of records or the full set according 
to criteria? Presumably the licensing body will not "push" updates to 
every existing medical practice?

One other contingency to cover the case of a doctor (e.g. specialist) 
who maintains, and sees patients at, a variety of offices. It is 
important both in the initial referral of patients and in followup 
contacts with the specialist to be able to retain this level of 
granularity --- patients get understandably upset at going to the wrong 
place, and I myself get peeved when I try to contact the doctor at one 
office only to be advised that "the patient is seen at our other 
office, which is where their record is kept, you will need to phone 
over there". A computing challenge may arise in that the LDAP will 
probably be structured to offer the available offices (and phone 
numbers) as:

  dn: ui=01108 , ou=Respirology, dc=foobar, dc=com 
  cn: Dr John Smith 
  officeAddress: 1234 Anywhere Lane, Vancouver  BC  V1V 1V1
   officePhone:  604 123-4567
  officeAddress: 5678 Somewhere Ave, Richmond BC  X2X 3X6
  officePhone:  604 456-7890

In the example, there is no key identifying the individual values for 
the addresses, they are merely offered as attribute pairs (attribute 
type = officeAddress, along with the attribute value). How then will it 
be possible for GNUMed to determine which, if any, of the doctor's 
contact info which had previously been entered into GNUMed to update? 
Would the record content need to be parsed for string comparison? Is 
there a standard within LDAP in which the officePhone that is presented 
first can be understood to relate to the officeAddress that is listed 
first etc.