[Top][All Lists]

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

[Gnumed-devel] Integrating LDAP

From: Jim Busser
Subject: [Gnumed-devel] Integrating LDAP
Date: Wed, 17 Mar 2004 23:15:14 -0800

I have been learning about LDAP, in part courtesy of a helpful link given previously by Tony Lembke


- 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

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.

reply via email to

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