gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] encounter - translation


From: Jim Busser
Subject: Re: [Gnumed-devel] encounter - translation
Date: Fri, 06 Nov 2009 07:26:20 -0800


On 2009-11-06, at 2:23 AM, Karsten Hilbert 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.

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?

I had been thinking of the episode concept as enabling the clustering (linking) of a series of interactions (encounters) per problem so that these episodes would actually be episodes of care *per problem* however if I now differently understand

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

then it is both a new understanding and invalidates what I recently explained to the Canadian-Polish doctor who questioned the whole value of "episode of care":

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".

reply via email to

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