[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: J Busser
Subject: [Gnumed-devel] Re: Info and to-do tracking schema
Date: Mon, 27 Sep 2004 09:06:26 -0700

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]