Self-replying, it might be helpful for the widget to pre-populate
this "sign" (or call-sign etc) with a value derived by parsing the
staff member's names to return the initials.
Ideally, before returning them, it could check whether these already exist, and
if they are unique, offer these as a default but
if they are not unique, return an alert
I suppose it could be up to the local administrators to decide
whether to adhere to a "format" for example the doctors (like Karsten
Hilbert) could have a convention to have the short_name or call-sign
"DrKH" but that would be purely to make the value informative and any
presence of "Dr" in this field would not be to grant or enforce any
privileges.
Is there any reason that once the staff member has been created, the
value of this field has to remain frozen? I am thinking that in a
small group I might start out as "jb" but if later the clinic or
surgery is joined by Jack A Burak there may be value to my becoming
"jrb" and Jack becoming "jab".
Is the value of "sign" written into clinical records, or does it
exist only in the staff table, to be used purely in the construction
of views?
At 12:13 AM +0100 1/19/06, Karsten Hilbert wrote:
> the extra staff not null details, such as staff role and sign (
which I asssume
> you can cut and paste a rsa public key, much like savannah does ) .
Nope, sign is intended for a short "call-sign" thingy, eg
"Leonard McCoy" has "LMcC". This is used where we need a short
signum for the provider. Please suggest a better term, anyone.
Maybe consider
short_name
short_form
user_initials
unique_initials
So far, I have not seen in the schema wiki-like spellings for field
names, for example shortName or uniqueInitials. So probably best to
not start using them mid-process, even if postgres would tolerate
them?
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel
