Re: [Gnumed-devel] help on encounters

[Jim Busser]

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