Re: [Gnumed-devel] Re: Medication viewing

[Karsten Hilbert]

On Thu, Nov 19, 2009 at 09:07:57AM -0800, Jim Busser wrote:

> Maybe not. When Episode is the Grouping term is the first order sort
> now determined "invisibly" by whatever was the default or manually-
> determined order of the health issues, and so it is coincidental, or
> for other reasons, that "abdominal pain" appears first, and not
> because of its alpha "a"?

Indeed. The order is currently rather arbitrary: it is by
pk_health_issue and thus resulting in a grouping rather than
sorting per se. Then, within the grouping by
pk_health_issue, an alpha sort is applied to the episode
name. "abdominal pain" appears first courtesy of
pk_health_issue being NULL or the lowest in the list and
then it being the first (and only) episode in that group.

> Or is the sort order in fact determined by
> this alpha but only in the case of this initial piece of the chain,
> after which the sequence chains to other medications (or non-
> medications) that associate with that same episode etc

Sure:

        self.__map_grouping2order_by_clauses = {
                u'episode': u'pk_health_issue, episode, substance, started',
                u'brand': u'brand, substance, started'
        }

So, numerically by pk_health_issue (== grouping with no
obvious order as far as humans are concerned), then
alphabetically by episode (within the health issue), then
alpha by substance, then chrono by .started.

> If it is first by undisplayed Health Issue sort, then I imagine what
> we should see is the Unattributed episodes presented together...

They are, courtesy of their pk_health_issue being NULL (two
of which do not compare equal but surely don't compare equal
to any non-null pk_health_issue either and thus group
together ;-)

> would these be by alpha of the episode name, or by chronologic order
> of the episode start?

by alpha of episode name (just as within any other health
issue sub group)

> Might it make sense to present the above grouped at the top of the
> list (like in the health issues list)?

They do, I believe. However, I've made this explicit now:

        u'episode': u'pk_health_issue nulls first, episode, substance, started',
        u'brand': u'brand nulls last, substance, started'

> >>So when the user clicks "Group by Handelsname" can the control cause
> >>Handelsname to be the left-most column,
> >
> >Done. Episode is then put back to the right.
> 
> I am just wondering whether we ever want the components of
> multi-part drug to be separated and non-contiguous in a list.

Sure, think of the poly-pill where each component can relate
to another episode.

> For a moment I wondered whether grouping by Episode should include a
> second-order grouping within Handelname except I suppose
> 
> 1) a patient could have received two components each (originally) as
> individual drugs for separate conditions but then (for convenience)
> be prescribed a combined medication. In this case you can't group
> except by breaking the the first.

Even if two components are combined into a multi-component
brand they still allowing linking to a different episode
each - even now :-)

> 2) one medication can treat two conditions and this becomes even
> more possible with a multi-part drug enabling a tactical choice
> (less available with a single medication) to let another condition
> be shown associated in the table.

The backend already has provisions for that
(multi-indication per component) but we don't yet transport
that into the frontend.

> Therefore maybe there can't be a reliable second-order grouping. I
> only continue to feel a tension as to whether to insert the
> Handelsname between the left-most column Episode

What is left-most depends on the sort order !  ;-)

> >>and within
> >>Stoff by decreasing numeric value of dosis (since a sequence of
> >>presentation of 100 + 50 would be more natural to add than 50 + 100)
> >
> >Oh, OK.   Now, since strength isn't numeric in the backend
> >that'd be rather hard. I have added a third-order sort
> >argument of .started, however, which achieves about the same
> >effect.
> 
> I am realizing these two strengths could have been registered within
> a single encounter in either order giving unpredictable result via
> above

Well, not unpredictable and even influencable (though not
without a bit of effort). It doesn't matter that they were
registered within the same encounter. The row, and
particularly the clin_when thereof, will be of (if slightly)
different values.

> but as the strength's non-numeric maybe not bother.

Not now, anyways :-)

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346