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

[Rogerio Luz]

Nice request ... Maybe get all your "TO-DOs" (say you saw 5 patients yesterday you have To-do´s made out yesterday) appear in your INBOX and IF there are ANY To-do´s, the INBOX become the default view when loging in to GNUmed.

 

Is this remotelely possible ?

 

Rogerio

 

PS: I have been reading on Python ... Is there somewhere anyone knows on the wx Gnumed uses out there so I can start coding ?? :)

2009/5/1 Jim Busser <address@hidden>

My medical protective association runs a series called "Safer care: Preventing adverse events" and one of these is available publicly here:
       http://www.cmpa-acpm.ca/cmpapd04/docs/resource_files/infosheets/2009/com_is0994-e.cfm

What it points out is that a result or a communication can require that another step be done and if that step is not done (and particularly if it is lost track of, even if it was recorded somewhere) there can easily be a bad outcome.

In the example a patient had a mammogram which:
1) recommended a followup in 6 months, but the MD (despite having ordered the test) apparently did not see the result, and had no system to make sure ordered tests were followed up as to their result
2) the next mammogram was done at 11 months and on account of the untracked original was ordered by the GP on a "screening" basis not on a "diagnostic" basis.

The radiologist advised an ultrasound and performed it themselves the same day however that was not referenced in the perhaps-already-dictated report of the mammogram. The ultrasound report was attached to the mammogram report and was apparently not appreciated (showing the vulnerability of a paper system however a scanner could pull two sheets as one).

At any rate, the doctor waited for a report of the ultrasound, not realizing it had already been done. It was normal and as per the second mammogram the next step was to have been an excisional biopsy. This only happened more than two months later when, as part of seeing a different doctor in the group for an unrelated reason, the patient's chart was requested and the results reviewed.

I think it is important to build this into GNUmed sooner rather than later because it is so tightly coupled to managing a patient's health issues information which we are arguing as something GNUmed can do very well. I have dredged up an old post (2004) about a possible to-do tracking schema (below).

It would make sense to be able to access and perhaps trigger into the creation of a to-do from
- the "plan" of a soaP note
- a test result
- a document archive item (part?)
- the medication list?

I would like to add to the minimum data specification:

1) I think it should have an escalate_when field... a widget could offer
       day(s) week(s) month(s) from now
with a default of 1 which would allow even the most important of things that did not get handled the same day to come up for review (escalation) the next day. For anything that is not so important, a key binding that would jump the setting to "week(s)" and to "month(s)" would with a minimum or work allow most other items to have their review (escalation) date easily moved later into the future.

2) it should have some kind of "assignee" or "assign to" field... I can't remember whether GNUmed / Postgres is already set up to support groups for example to assign an item to Nurse or Reception or Referrals etc if those roles are handled by more than one person.

Begin forwarded message:

From: J Busser <address@hidden>
Date: May 23, 2008 10:45:46 PM PDT (CA)
To: Karsten Hilbert <address@hidden>, address@hidden
Subject: Re: [Gnumed-devel] Re: Info and to-do tracking schema

At 11:34 AM +0200 10/1/04, Karsten Hilbert wrote:

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.

This can wait 'til you are back from "training" ;-)

How is a "non-checked" foreign key different from other (default "checked"?) foreign keys? Is it a matter of storing the "value" of what would be the foreign key, without defining or requiring the field to be treated "as" a foreign key, in case for some reason it is desirable to modify table content independently?

If a foreign key that is "non-checked" does not function truly or properly *as* a foreign key, should we name it something other than fk_? like ncfk_ or ek_ for external key?

_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel