|Subject:||Re: Feedback Re: [Gnumed-devel] GNUmed Release 0.6.rc1|
|Date:||Mon, 23 Nov 2009 00:12:10 -0800|
On 2009-11-22, at 1:59 AM, Karsten Hilbert wrote:
I would rather not give an answer before understanding what might still be a good idea. Is the issue that there exists a "type" which is "status line" and if you changed this particular message's "message type" (to "status line") this would give an already-defined behaviour?
Is the already-defined behaviour of a status line (upon being double-clicked) simply to disappear, or are additional options intended, such as the ability to pop-open the item in case the message content was longer than could be show in a single row of the UI, or perhaps there could be value forwarding it to some other individual in the praxis (with or without editing)?
In the alternative, was there some thinking that there would be value to a
message type = FYI
that would have different behaviour than a "status line" and it is merely a matter that the alternate handling has not yet been coded?
You mean "the tables, as shipped" which, after local activation, can be added to?
... is the internal reference data
... normalizes, across what different patients consume, the substance name (and ATC, if the substance has an ATC)
... provides the foreign key constraint for clin.substance_intake
... allows more than one substance to have the same ATC because the ATC may not be unique?
... external database
... design is very limited at this stage (brand names per ATC code)
... eventually the strength and preparation and brand might come from this or a linked normalization table
but presently only the name (normalized) comes from clin.consumed_substance and nothing comes from the external database except the brand names via ATC lookup (but not using foreign key constraints)
but since on 2009-10-29, at 12:50 PM, Karsten Hilbert wrote:then this is agreed suitable for inclusion in the substance entry / edit widget? Were you thinking excessively fine-grained for 0.6 and preferring for 0.7?
I see the value in a .last_actually_used field. Let's
document that and keep it for a future revision.
|[Prev in Thread]||Current Thread||[Next in Thread]|