Re: [Gnumed-devel] need-to-know change to backend

[Karsten Hilbert]

> Encounters in GnuMed are intersections, or interactions, between:
> - a patient, or patient information (such as the existing chart, or 
>   new test results, or enquiries about the patient's records or care) 
> and
> - a health professional possessing GnuMed privileges (though an 
>   encounter can be pre-entered on behalf of such a person by 
>   non-clinical staff)
I understand it that way, yes.

> Encounters are further characterized or defined by a datetime stamp, 
> by the gnumed provider, by the type of encounter (chart review, phone 
> call, visit) and, if a physical encounter, by the location or site.
Yes.

> As a description of the encounter the schema presently suggests that 
> applications should display "<date> (<provider>)" plus, if the 
> description is "xxxDEFAULTxxx", some marker for "default".
Yes, if no explicit name is given this is our current
suggestion for application writers.

> I would suggest the encounter_type also be displayed.
Updated the schema to include this.

> Encounters have a dual meaning i.e. meaning each portion of (e.g.) a 
> visit, dealing with each of possibly several active problems,
Yes.

> versus meaning these portions taken collectively.
Yes.

> Both meanings have value 
> and so rather than arbitrarily deciding that one is right and the 
> other wrong, can we let the meaning be defined by the context of 
> discussion (usually the portion, or "thread", when discussing 
> episodes).
In the Dutch/Belgian model one aspect is called
encounter/contact while the other is called
sub-contact/partial contact. I am fine with either term plus
portion- or thread-of-encounter. I agree it is paramount to be
clear on which is meant.

> Episodes are user-defined collections of encounters, where each 
Being picky: episodes are *recognized* by users but *defined* by
nature (both of which may not coincide).

> episode represents an aggregation, by problem (or by symptom cluster) 
> within one or more encounter sessions, whether the problem (or 
> symptom cluster) be
Agree.

> Each episode is described by the most recent encounter's 
> clin_narrative as follows:
> - by an Assessment of Encounter (AOE), if one exists
> - by a "simple" (non-AOE) SOAP "Assessment" (soAp) row, if no AOE row exists
> - by the reason For Encounter (RFE) if neither an AOE or soAp row exist
According to recent discussion we will try to have an explicit
defines_episode field in clin_narrative that can only be true
for one single clin_narrative row per episode. This would
then "describe" the episode instead of
clin_episode.description (which verges on the brink of
oblivion). However, in absence of any such clin_narrative row
we would still need a fallback mechanism for which the above
seems to be a/the likely candidate.

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