Re: [Gnumed-devel] LDAP vs. SQL - RT comments

[richard terry]

Again I come at contacts from a pragmatic point of view, not a technical one.

My whole approach to medical records is one of functionality - speed 
optimization, which is why I came up with the editing area concept.

I note already the discussion on referral letters, about which by the way I 
don't agree - as there is no need to use external word processors to write 
these letters. Doing that is just another layer, more clicks, more confusion. 
Simply a rich text box provides all the style one needs and can be set to a 
default font as per user requirements. All my referral letters range in size 
from 1k to 3k max for over an A4 page cause I just keep the ascii.

 A good contact database is an integral part of the referral letter write. As 
information is kept in normalised tables people can be attatched to more than 
one organisation/hospital/clinic/ or be free standing. The minimum dataset 
for the contacts must include an obligatory category eg Orthopaedic Surgeon - 
Hand. When linked to your letter writer then, you can refer by 
occupation/category, select by surname, click on the address field and have 
the multiple addresses for that person pop up etc, and even make the program 
respond by giving you addresses say close to the postcode the patient lives 
where the specialist can be found.

The contact database is also integrated with ALL REFERRAL FORMS. Same format. 
In my contacts databse organisations have branches, organisations have 
employees either of the head office (the default address of the 
organisatsion) or are employees of a branch. When setting up the medical 
records program, a table holds the default type of provider (I chose 
pathology), preferred providers for each doctor and the preferred address 
they wish to send requests.  

When selecting the requests button (or function key), the program changes to 
that editing area complete aready with default details (see requests1.png) of 
provider, preferred rooms address etc. If one wants to change to say the 
company providing the service, one clicks on the company line (see 
requests_multiple_providers.png). If one wants a collection centre of a 
chosen  company in anothe suburb simply click on the suburb line (see 
requests_providers_multiplesuburbs.png).

When requesting anything (be it 
physio/pathology/radiology/vascular/cardiovascular/podiatry etc etc, as soon 
as one selects the first letter of too of the provider type, up pops the 
phrase wheel etc as per previous examples).

Next look at doing a referral letter:
One could order by category: see referrals_by_category.png, then decide that 
we want the patient to be seen at a different branch, we click on the suburbs 
line see referrals_by_category_change_address.png

etc etc.

Ie a complex normalised relational database for contacts is essential. for a 
quickly functioning flexible program.

Anyone, patients are stacking up outside and my secretary is getting stroppy 
so I'll have to go.

On Wed, 30 Jul 2003 03:16 am, Ian Haywood wrote:
> It has occurred to me that we need a contacts database for
> referrals/requests. Should we:
>       a/ use LDAP
>       b/ "roll our own" in postgresql, as another service
>
> advantages of ldap:
>       - can scale, divisional servers, share with local hospitals, etc.
>       - existing standard
>       - interoperates with e-mail clients etc. etc.
> disadvantages
>       - another dependency, server configuration
>       - limited features: a simple "flat" addressbook, limited ability to 
> group
> people by location as Richard's contacts widget implies (Richard, could you
> elaborate on this)
>
> Ian
>
> PGP public key E750652E at wwwkeys.pgp.net
> 9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

referrals_by category_change address.png
Description: PNG image

requests_multipleproviders.png
Description: PNG image

referrals_by category.png
Description: PNG image

request_providerers_multiple suburbs.png
Description: PNG image

requests1.png
Description: PNG image