gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] help on encounters


From: Jim Busser
Subject: Re: [Gnumed-devel] help on encounters
Date: Mon, 12 Jul 2004 00:54:39 -0700

On Jul 11, 2004, at 9:33 AM, Karsten Hilbert wrote:
- supposing at the end of the visit, or even a week after the visit is
done, there is a plan or request by the patient or doctor for followup.
New encounter, clearly.

I can understand that there is now a new RFE but I do not understand an
attachment to the visit that has already concluded.
A new encounter should be created.

The RFE will relate
to the next visit, i.e. to the next encounter for this health issue.
Exactly (the next encounter * for the next episode * of this
health issue).

Whether the next encounter would be a *next episode* would depend on whether or not, in the judgement of the doctor, that last episode had concluded, right? If they had judged it concluded, then yes, but if at the end of the last visit they decided a followup would be necessary, or if after the last visit they had not yet decided on a followup, but felt they had to think over the case further, the episode could remain "open", and the next encounter could link within the *ongoing* episode, right?


- supposing before this next visit (which may not even be scheduled
yet), the doctor wishes to record a discussion with a consultant. I can
see how the discussion could lead to a modification of the Assessment
and/or of the Plan but how to handle this?
Either create a new encounter...
Or add on to the last encounters' data directly.

Is adding (without creating new rows) achieved by "replacing" a row (recoverable via audit) with a copy, whose text would be modified / extended, and which would carry the newer timestamp?

Or
link new clin_narrative rows to the last encounter.

I am still pondering how "extra rows" work. I can seen how in a one-issue encounter, you might have 2 Soap rows (one being designated RFE), and up to 2 soAp rows (one being AOE), so the widget could present (in arbitrary order) something like

RFA
  S
  O
  A
  P
AOE

I can see how in an n-issue encounter, we might have n times the above rows linked to the encounter, yet if a user wanted, each health issue / episode / encounter combo could be cleanly teased out, enabling viewing in a similar fashion to the above on a per-issue basis if that is desired.

I am however having trouble with what purpose it serves to be adding *extra* SOAP rows beyond those above to any one issue within an encounter (not counting "replacing" a row as discussed above). We seemed to have already established that content within SOAP should be able to be parsed so that ought not be a factor. --- If in order to access (view) the last encounter, I have already had to create a newer encounter "chart review", might it make more sense to be "adding any new rows" to the current "chart review" encounter (maybe renaming the encounter type "chart update") rather than adding to the earlier encounter? It is just that, while I agree an *episode* may remain active and open, a particular encounter really shouldn't have these properties once the doctor is satisfied with their RFE/SOAP/AOE note and has "signed off" (i.e. unset limbo - see footnote). Anyone else have a view on this?

Footnote - I found, and bookmarked on the wiki DeveloperReference page, a link to 'limbo table entries" posted by Horst to seeming agreement but I gather has yet to be incorporated into the audit table schema:
http://lists.gnu.org/archive/html/gnumed-devel/2003-01/msg00133.html





reply via email to

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