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

[sjtan]

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

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.