[Top][All Lists]

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

Re: [Gnumed-devel] gmContact signal --> referrals

From: sjtan
Subject: Re: [Gnumed-devel] gmContact signal --> referrals
Date: Fri, 04 Jun 2004 11:21:26 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

there was an attempt to abstract org - persons in gmOrganisations, using cOrg and cDemographicAdapter which implements

it's ok for getting info using the dict way of ['email'], ['phone'], ['fax'] for comm links, ['name'] for org or person name, .getAddressDict() for a dict for address, or o.getHelper().getAddressStr( o ) where o is the org or person . The org['subtype'] field is not well abstracted though, as it means 'department'/'branch'/'division' with an org object, but 'cardiologist/plumber/physiotherapy' with a person object. There's probably a need for a ['fullname'] attribute, as it then gets the hospital name and department name for a sub-org, instead of just the department name , which might be the same for a number of hospitals (as an example). At the moment to get the full name for an org, the steps are 'if parent exists, return parent's name +' '+ name +' '+ subtype, else return name '.
(sounds like a need for an overloaded getName() function).
The reason the org['subtype'] wasn't well abstracted was the interpretation of Richard's contacts gui ; the branch/ department name is a text entry, but maybe it should be like a category entry ( e.g. Department of Respiratory Medicine is the same as department of Respirology , or Thoracic Medicine Department ; maybe store the name and the subcategory as separate table fields). The org_category concept is probably not being used sufficiently: currently, it's just used to store 'hospital', 'pathology company', 'radiology company' , 'nursing home', 'hostel', 'rehab centre' i.e. top level org types ; should it store 'physiotherapy department', 'pathology company collection branch' , 'radiology centre', as a utility compromise?

Currently, to do a category search, a method could be added to gmOrganisation.cOrgHelper to get back cOrg objects which can represent either organisations or person demographic records, but with the limitations of the cOrg interface. This might be ok for referral writing, but then ANOTHER phrase wheel matcher needs to be written for lists of python objects or dictionaries, which can be configured for cOrg.

to make it sql simple ( and not gmOrganisation dependent, and current phraseWheel compatible) a personOrg sql view might be better.

reply via email to

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