Re: [Gnumed-devel] help on encounters

[Karsten Hilbert]

> 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?
Quite right. However, I would postpone decision on episode
closing until the next encounter no matter whether there was a
booked appointment or not. A booking doesn't mean the patient
will show up. Usually, a "long" time will elapse before the
next episode. Episodes end when they appear to have ended. I
would not try to anticipate their ending.

> 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?
Exactly.

> I am still pondering how "extra rows" work.

> 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).
It serves no purpose but it can be done :-)   I simply don't
yet see a convincing point in NOT allowing it.  I agree there
are problems on how to best represent multiple rows.

> 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 
OK, sorry, bad English on my part. Should be "readup on chart",
not "review" in the common English use.

> 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).
In most cases, yes. An encounter is closed and that's that.

> 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
Anyone code it up and I'll take a look.

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