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

[J Busser]

Self-replying, but anyways...

If a message_and_to_do table were implemented, there are some items 
that would eventually need to get written into existing tables in the 
schema.

For example, a phone message from a pharmacy, taken by the front desk 
that a patient has run out of medication and will need a new or 
renewal prescription *may* translate into a new prescription for an 
existing medication or, if the doctor decides otherwise, into a new 
medication, or a revision to existing medications.

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? Reasons include:

- it is more programming work and slower(?)  to have to fetch and 
assemble all of the to-dos from the various places where they might 
be sitting, not to mention risky (in the event that important but 
scattered to-dos fail to be included in queries)

- it is messy (potentially confusing, clinically) to prepare, and to 
provide to another clinician, a summary of a patient's information of 
the various sections are littered with items that have not yet been 
done or approved, better to put pending or future-acting items all 
together, that way a consultant who is sharing care of the patient 
can see what is already lined up and the status of items that may be 
in process

The benefit that *might* have come from writing to_dos directly into 
the (eventual) destination tables would be to pre-populate the fields 
with pertinent information however the benefit is (IMHO) not worth 
the risk and besides, we would still need a structure by which to 
guide which office role or individual is to be looking after such 
items and what is their status, and details pertaining to the efforts 
to arrange them, whether the patient has been made aware of the 
booking etc all of which are reasons why I think we need another 
table for this anyway.

But maybe the message_and_to_do table could contain a pointer (fk 
belonging to the source of the issue, or a program module such as the 
prescription-writer) to the type of item needing to be done. That 
way, once it becomes meaningful and appropriate to write more details 
elsewhere (for example, to write the prescription) it might be done 
more easily. Perhaps a link to the medication that will need to be 
re-ordered, or to the lab result that is the basis for requiring a 
patient to be called back into the office could be useful.