Re: [Gnumed-devel] Integrating LDAP

[Karsten Hilbert]

> Options:
> 1. GNUMed queries the LDAP each time, storing only the doctor's LDAP 
> Distinguished Name (DN)
No. This too much depends on non-guarantueed availability.

> 2. GNUMed queries the LDAP each time, but maintains a copy of the data, 
> refreshing it as required
Too much overhead I would think.

> 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)
Sounds good to me.

> 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?
IMHO weekly auto-update is plenty.

> 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?
yes, scripted, selection of records automatically provided by
keeping only those doctors locally that we have had contact
with (and thus forced retrieval of their data)

> Presumably the licensing body will not "push" updates to 
> every existing medical practice?
Technically, a parseable announcement should be mailed to
subscribers detailing the DN's that have changes. But that
isn't likely to happen.

> 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?
That's what I'd do: take the values I already have, parse out
known values into fields and try to guess from there what the
rest is to mean. Also, this table might help:

create table ldap_doc_info (
    pk serial primary key,
    fk_doc integer references staff(pk),
    ldap_data text not null,
    unique (fk_doc, ldap_data)
);

Where anytime a contact is pulled up and has a corresponding
ldap_doc_info entry it is display alongside with the contact
info and makes it easy for the user to semi-manually parse the
data into fields. Upon transferring all data to fields the row
is deleted.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346