On Thu, Jan 19, 2006 at 07:40:38PM -0800, Jim Busser wrote:
> 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. Surely. > 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'd rather employ an algorithm to force them unique (add a number, add more characters, etc) in that case. They can always be changed. > 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. Exactly. > Is there any reason that once the staff member has been created, the > value of this field has to remain frozen? No. That would violate one of our design principles: don't make the database schema prone to display/UI changes. The alias is simply for display purposes. It is always accessed via the primary key of the provider. > 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? We pride ourselves in the latter. However, the "sign" may end up hardcoded in some places: think referral letters or better yet printouts for, say, paper backup (where clinical notes are tagged by "sign" to indicate which doctor they come from). Such things really should contain a legend on such values. See, the EMR software I am working most with uses single-character aliases. They are never in ample supply for the staff needing one. They are also hardcoded into the clinical data (hence I acquire "ownership" of notes of my predecessor). Such stupidities are best avoided. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
