Re: [Health] Freely configurable Party and Products Flags with Configurable Per-Group Defaults

[Christoph H. Larsen]

Dear Alexandre,
Thanks a lot for you long mail.

On 22/04/12 03:42, Alexandre Santos Aguiar wrote:
> Hi,
> 
> Em Sex 20 Abr 2012 às 04:27, falava-se sobre "Re: [Health] Freely 
> configurable Party and Products Flags with Configurable Per-Group 
> Defaults" e Christoph H. Larsen escreveu:
>> ad as new medical fields are added over time, you have to be constantly
>> on the watch not to expose medical details to clerical staff. (I know
> 
> Yep. Think I understand now. Still do not have enough knowledge on Tryton 
> but generic system wide methods have been used elsewhere. Just for 
> brainstorming. Access privilege is a difficult matter.
I sorted out the access privileges, by denying access to field when
clerical staff enters patient core data from with the Patient facility.
The issue is that the area, where core data should be entered (to ensure
strict, sustainable and hence fail-safe privilege separation between
clerical and medical staff), i.e. the Party facility, does not have any
mechanism to create patiet IDs nor to enter SSNs.
> 
> One such "generic" method is the use of domains and contexts. Different 
> applications of domains define both so that a context is an application 
> domain where a given user is in (within his/her user domain). Tryton 
> seems to have both already.
Done via the model concept in Tryton, so certainly not really a problem
in conceptual terms, and I believe, done well. The point would be to
drag the patient ID and SSN fields out of the patient model, or to share
it with the party model, IF field is_patient=TRUE.
> 
> If a user can create fields (or objects of any other available classes) 
> within his domain then the new fields|objects simply inherit the context. 
> This way "roles" can be defined dinamically depending on context even 
> without explicit user configuration. The whole system can be yet more 
> stringent by submitting functions and whole classes (including interface 
> components) to the this "domain + context = role" scheme (I suspect this 
> already happens somehow).
> 
> The only new function to be created (for human use) is the ability to 
> change contexts of newly created objects. And "change" here is the same 
> as privilege scalation in an (expected to be) ordered and safe fashion. 
> The less human intervention the better, IMHO.
> 
> A wider application of the contexts can include the machine where 
> application is run and/or the machine that requested data, important in 
> distributed applications.
> 
> Scenartio: someone creates a field (a database field and a correspondent 
> interface in a given window possibly with attached functions to assure 
> correction of newly entered data). For instance: a phisiciann creates a 
> field to record the presence of say, Naffziger sign. Both objects (data 
> colection interface and data storage) inherit the context of a phisician 
> caring for patient so that the system unsderstands that non health care  
> personel is not to see that bit of information. Not to take into account 
> the these new two objects will already be available only in the context 
> of a window that is available in the context of an app, etc. This 
> approach produces a very strong hierarchical mechanism with many 
> redundant such controls so that no single hack can unconceal much 
> information. If network location restriction is applied, other effects 
> may appear: a phisician could not open patient information (or be 
> required to assume himself liable for doing this) in a guaranteed non 
> private or non patient related local. This, however, requires a so 
> unlikely high commitment of IT personel although could be handled 
> (actually completely automated) by proper network topology.
I do believe that the creation of extra fields for new signs and
symptoms will lead us down a rocky road. Also, normal users should not
be able to create new fields, IMHO.
> 
> An approach like this is used by Drupal that makes it available to third 
> party modules through an API.
> 
> Actually, for maximum automation and minimum impact on existing code, a 
> static object of class context (or anythigng meaningful) can be a private 
> component of a primitive virtual class to be base for all data related 
> classes. Or something like this that could work.
> 
> Please, forgive me if I wrote too much crap. Still have to study a big lot 
> of Tryton/Gnu Health internals. :-)
The good news is that Cécric has done a great job and created a
rock-solid framework. It is more a matter of using/exploiting all its
great features WOITHOUT duplicating his efforts at a higher level.
>

> My 2 cents.
Cheers!
> 
> 

-- 
Dr. Christoph H. Larsen
synaLinQ (Vietnam)                      synaLinQ (Kenya)
P.O. Box 55, Bưu điện NT, 01 Pasteur    P.O. Box 1607, Village Market
Nha Trang, Khánh Hòa                    Nairobi 00621
Vietnam                                 Kenya
Mobile: +84-98-9607357                  Mobile: +254-753-632481
        +49-176-96456254 (Germany)
Fax:    +49-231-292734790
Email:  address@hidden