Re: [Gnumed-devel] Mistaken Patients - PNG enclosed (was: A question re demographics)

[Karsten Hilbert]

> but presumably you cannot have each patient "active" in separate 
> windows (which would facilitate going back and forth) - or can you?
No. The current client is built around the core concept of one
single active patient at any one time. You could, however,
open several GnuMed instances at once.

> Instead of deleting, why not just update the records by linking to the 
> RIGHT patient? I can see no reason, other than doing so accurately / 
> completely.
Probably Horst's system doesn't afford that.

> Would seem to require that, for example, for a SOAP entry:
> 
> - clin_narrative rows be updated on:
> - - fk_encounter  - doable in one step for all affected rows
>       e.g. by selecting what SHOULD have been the correct
>       patient appointment) and
If it's a new encounter one could just point the encounter row
to the correct patient and be done with it.

> - - fk_episode - a bit more work but still a savings?
>       i.e. if there are three RFEs, each would need to be mapped
>       to a suitable episode of the target patient, however once done
>       for any one RFE, the related SOAP / AOEs could "move" with it
A bit trickier. Yes, that'd include finding all the rows in
all the tables that link to the wrong episode and relink them
to the correct one. Finding nearly all of them can be done
through clin_root_item. Updating them can NOT be done through
clin_root_item, unfortunately, as PostgreSQL inheritance
limitations doesn't allow that to happen properly.

Except for when it was a new episode which could just be
relinked to the proper patient.

> - the ancestor clin_root_item would have its corresponding
>       fk_ fields updated to match (hence will also have been audited)
Nope. One would have to update clin_root_item descendants
which would punch through to the corresponding rows in
clin_root_item.

> The wrong patient could have had new clin_health_issues and episodes 
> created which would either need to be deleted or updated, depending on 
> whether suitable values already exist.
Right.

> Is the above a sensible way to do things, and does it depend only on 
> someone who makes this error often enough (or who gets frustrated soon 
> enough) that it becomes worth their while to get it coded up?
That sounds about right :)

> PS what would the reason be that the table clin_root_item specifies an 
> Fkey (for example, clin_episode.id) while the table clin_narrative does 
> not?
Because clin_narrative inherits that key from clin_root_item -
the whole point of it.

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