Re: [Gnumed-devel] Clinical reminders

[Karsten Hilbert]

On Mon, Mar 05, 2012 at 01:32:06AM +0000, Jim Busser wrote:

> > This is GNUmed showing a clinical reminder.
> > 
> > Reminders are inbox messages with a non-null due date.

...

> I mostly like it, but I was not clear on where in GNUmed we would be storing 
> per-patient clinical reminders.
> 
> Is a "reminder" a reminder of a "to do" item?

That depends on the payload of the reminder, that is, what
one puts inside the inbox message that's being equipped with
a non-null .due_date.

> Are "to do" items to be thought about as either
> 
>       a) auto-generated (e.g. from clinical decision support) or

They might, but not currently.

>       b) explicit, per-patient to dos

Currently remeinders are manual and explicit only.

Say, I think to myself: "Oh, this patient needs followup
colonoscopy in 5 years." So I go and add an inbox message
for this patient saying "refer for colo" with a .due_date of
"+5y" - that's what I enter - and GNUmed helpfully
calculates now + 5 years and stores that. In <5 years, when
I next activate this patient, GNUmed tells me: "Colonoscopy
is due".

GNUmed does not actively remind me of things due *unless I
open the relevant patient* but I have provided a report to
query for pending reminders across all patients which could
be printed at the start of each work day or something like
that.

> and do these best live in the inbox?

They do, ATM.

> We have had some discussion of inbox vs waiting list. One
> idea would be that the waiting list should only be for
> patients waiting for appointments,

At least that had been the design idea.


> although a variety of to-dos are in fact nicely manageable
> using the zone system (which inbox does not offer).

Weeell, in a way the inbox does, too: one might (ab)use the
"type" - but it does not lend itself to such use as easily.

> So while it is sounding as though GNUmed v 1.2x (client) will gain new inbox 
> item functionality like
> 
>       due date
>       expiration date
> 
> and while I agree that such attributes are needed for
> to-do items, is the concept compatible with an Inbox? The
> difficulty that I am having is because, to me and maybe
> others,  an Inbox is something we are supposed to "clear".
> It is not normally a place to "leave things" until done
> including things that are not to be done except in the
> future.

I agree it may feel slightly awkward to some people to have
due/expiry on inbox items.

However, inboxen surely can have a sorting, or several
trays, relating to due-ness ("due now" vs "due later"). If
one stresses the message delivery metapher then there's
plenty of precedents, too. Think of timed delivery - you
don't want Valentine's roses to arrive the 13th of February.

As for expiry, items within my inbox-to-clear may well carry
an expiry date: "Look at this offer (which expires tomorrow,
though).", so if I only get to it the day after tomorrow I
can safely ignore it (and yell at my secretary as to why
this still sits in my inbox ;-)

Nonetheless, I do agree issues like that warrant spending
a thought or two.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346