Re: [Gnumed-devel] Re: Info and to-do tracking schema

[Karsten Hilbert]

> Other examples of to_dos that *could* result in new rows in existing 
> tables include office appointments, lab requests, and others, I am 
> sure. But am I wise in thinking it best *not* to write to_dos as 
> future-dated (post-dated)-but-incomplete items into these eventual 
> tables?
I agree.

The simplest thing I can imagine is that there is a todo
table that has these fields:

create table clinical_todo (
    pk,
    fk_type,
    comment text,
    context_link integer
) inherits (audit_fields, clin_root_item);

A generic enter-clinical-todo widget would have the user pick a
type (eg. refill request) and have him enter some info, eg.
"Pharmacy Wilson at K-Mart called for refill on sildenafil".
Such requests would always relate to a given patient (defined
via clin_root_item). The context_link field would serve to
store a non-checked foreign key to a clinical table, say, a
previous prescription. The widget needs to know what to put
there depending on fk_type. It might also be kept as NULL.

Eventually, the responsible user will have a look at his TODO
sheet and notice the refill request. She will call up the
relevant patient (can be done by clicking on an item courtesy
of fk_episode in clin_root_item) and see the patient inbox
(Richard had this).

The patient inbox is perhaps just yet another view at the
clinical_todo table filtered by patient. Perhaps the inbox is
smart enough to know what to do about fk_type=refill and what
to do with context_link in that case (eg. pull up the values
from the referenced script and put them into a new script).

After dealing with the todo clinical rows will have been
created and the todo can be dismissed. The comment could be
added on to to provide status/completion notice, even
automatically. Here the sig field in the staff table comes in
handy. I would opt for deleting the row from clinical_todo or
else we would get a large table in the end most of which is
inactive. Note that deleted rows are still kept in the audit
table.

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