|
From: | richard terry |
Subject: | Re: [Gnumed-devel] LDAP vs. SQL - RT comments |
Date: | Wed, 30 Jul 2003 10:10:38 +1000 |
User-agent: | KMail/1.5 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |