gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] jl-gui et alii - v_emr_tree


From: Jerzy Luszawski
Subject: Re: [Gnumed-devel] jl-gui et alii - v_emr_tree
Date: Tue, 27 Aug 2013 05:19:44 +0200

> 
> > > > > 4) What is the reason for choosing assessment to be the
> > > > >    description of the encounter ?  (this will severely limit
> > > > >    the generic applicability of this view)
> > > > Isn't assessment_of_encounter just this - short description?
> 
> Regarding clin.v_pat_encounters - yes, I can see why you'd
> want to keep assessment_of_encounter ->
> encounter_description.
> 
> Regarding .modified_by and .provider:
> 
> a) do you truly need both ?
Yes. See below.
> b) what you call .provider is, by convention, called .modified_by
NO! What I named .provider is staff.short_alias, only when this is
*unavailable* it falls back to ('<' || c_enc.modified_by) || '>'), eg.
'<gm-dbo>'
The purpose of .provider is to show wherever possible the pretty and
easy recognizable by humans short_alias (like 'J.Lusz.'), instead of db
user name, which can be 'jl123456'. But .modified_by is still useful for
changes log display, which is raw.

> c) .provider is not accurate - people will think this is
>    the provider having taken part in the encounter. It isn't.
In which situation it isn't? If someone modifies the clinical data
he/she must be treated as provider.
BTW - people will see the description of the field in a plugin, not the
field name in db schema. 

> Consequently, I renamed .provider to .modified_by and comented
> out your .modified_by (and renamed it to .modified_by_raw).
Renaming to new and unused name is harmless, but what you described is
putting different information into already widely used field
'.modified_by'. Everyone, including me, will be misled by it.
Please, reconsider the purpose of .provider I described above. If you
still think the 'provider' is inappropriate, suggest a new name for
this field, so that the .modified_by could be left unchanged.


--
Regards,
Jerzy Luszawski



reply via email to

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