[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Clinical reminders
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Clinical reminders |
Date: |
Mon, 5 Mar 2012 10:57:27 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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