Re: [Gnumed-devel] encounter - translation

[Karsten Hilbert]

On Fri, Nov 06, 2009 at 07:26:20AM -0800, Jim Busser wrote:

> >It is more precise to say: A patient can have multiple
> >encounters/visits -- during each of which a number of
> >episodes (= bouts of illness activity) are worked one.

I should have said: bouts of activity of one particular illness

> Maybe I did not yet use GNUmed enough, however can we not have two
> episodes of care (one episode of care of gout and one episode of
> care for abdominal pain) that overlap in time?

We absolutely can.

>       episode = hopefully-useful but arbitrarily chunked groupings of
> encounters across "whatever mix of not-necessarily-related problems
> happened to be touched"

No.

> On 2009-11-04, at 3:20 PM, <my colleague> wrote:
> 
> >‘Episode of care’ is a very vague concept that probably should not
> >even exist in EMR design, unless I am missing something very
> >badly.
> 
> The purpose of the "episode construct" is to provide an aggregation
> of entries, each of which relate to one meaningful "segment of time"
> in the course of the care of a problem.
> 
> If you imagine a patient with asthma or other chronic lung disease,
> you can imagine the value of being able to have it (visually)
> skeletonized for you, in terms of the frequency (and spacing) of
> exacerbations over time. Any one exacerbation may transpire over a
> period of days or weeks, and these could give rise to a combination
> of visits and phone calls and lab tests orderings and chest x-rays
> and maybe a request for consultation and the consultant's report.
> 
> The above, for any one exacerbation, could easily involve dozens or
> a hundred or more rows of information and so by making possible the
> organizing structure of an "episode" we can provide a usable (yet
> optional) abstraction of any problem. We do not enforce it... the
> user can omit to be bothered to do it thus defining no episodes
> beyond the auto-created default. This leads every entry, and every
> result, associated under (say) "asthma" to only ever aggregate under
> that single, default, treated-as-never-ending episode.
> 
> Episodes would make it very fast to interpret disease activity as
> may be needed to justify escalations of therapy.
> 
> Episodes offer further value when juxtaposed. You might argue the
> following obvious, but less-obvious will also benefit…
> 
> Suppose you have a patient who presents to a clinic on three or four
> occasions with abdominal pain and diarrhea, one of which is
> associated with bleeding. Suppose it was possible to see that these
> started three months ago after the reactivation of gout. A listing
> across episodes could show the original episode of gout, below which
> might be listed unrelated minor things, but followed 4 months ago by
> a flare of gout and then another and, between those two, episodes of
> abdominal pain and diarrhea.
> 
> An obvious benefit in such a "threaded" EMR becomes the possibility
> of an "aha" moment to better recognize the existence of relevant co-
> factors (alcohol, colchicine and anti-inflammatory drugs).
> Medication lists alone may not achieve this...
> - the colchicine could have been provided more than a year ago, and
> could have dropped out of view in a prescription list
> - the NSAID could be over-the-counter and not captured
> - even if the above are in view, but nested among a list of a dozen
> medications, their relevance can be hard to see.
> 
> >I have no idea what is meant by ‘foundational issue’.
> 
> 
> Foundational issues are meant to serve as the "spine" of patients'
> problem list, where all problems can exist at one of two levels...
> the major level would be the attributed "basal or root"
> (foundational) condition that is responsible (or attributable) as
> the cause of a disorder, or of a risk state, such as:
> 
> - diabetes mellitus
> - post-splenectomy state
> 
> and we could understand the diabetes mellitus to be the organizing
> basis for episodes of DKA or hypoglycemia or poor control. This is
> the second level. Some undiagnosed illnesses may present with
> symptom episodes that remain perplexing but pending a satisfactory
> working or presumptive diagnosis should be kept at the second
> "unattributed" level until attribution is then possible.
> 
> We could also understand that in the case of post-splenectomy state
> above, a motor vehicle accident that gave rise to the splenectomy
> could have easily qualified as an earlier foundational issue… one
> which "spawned" a "secondary" foundational issue of
> "post-splenectomy state". A key distinction is that the splenectomy
> will always remain clinically important and will justify to be kept
> in view, whereas the MVA itself will not.
> 
> Likewise, at the point where a diabetic would evolve blindness, or
> renal failure, or any other secondary condition that gives rise to
> its own need for management, that condition would get promoted to be
> a foundational issue in its own right.
> 
> Maybe "Base" or "Basal" or "Fundamental" would be better words...
> maybe even "Underlying" ... Given the above description, what would
> you favor? We should maybe also keep an association of the word
> "condition".

Tha explanation is perfectly fine. I am highly interested in
what flows from this interaction.

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