encounter - translation

[Karsten Hilbert]

Regarding the encounter concept:

in GNUmed this is a fusion of

   a database session in technical terms

and

   a participant-health care system interaction in conceptual terms

Most of the time it will involve a patient and a provider. In all
cases it will involve access to the medical record of a patient.

One could also think of it as "one incidence of care" which
happens within an "episode of care".

HTH,
Karsten
--
DSL-Preisknaller: DSL Komplettpakete schon für 16,99 Euro mtl.!*
http://portal.gmx.net/de/go/dsl02


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jerzy Luszawski]

Wednesday 04 November 2009 13:26:46 Karsten Hilbert napisał(a):
> Regarding the encounter concept:
> Most of the time it will involve a patient and a provider.
But a "provider" is not necessarily a physycian, it may be lab or rehab - true?

> One could also think of it as "one incidence of care" which
> happens within an "episode of care".
Yes! So the Polish translation will fit nicely, because it means "event" or "incident" :)

I will move on with translation.

Jerzy Luszawski





_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

> Wednesday 04 November 2009 13:26:46 Karsten Hilbert napisał(a):
> > Regarding the encounter concept:
> > Most of the time it will involve a patient and a provider.
> But a "provider" is not necessarily a physycian, it may be lab or rehab -
> true?

That is correct. It could even be an importer script automatically
importing lab data on behalf of a patient. In that case no human
being would be involved.

Karsten
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Wed, Nov 04, 2009 at 08:58:23PM -0200, Rogerio Luz Coelho wrote:
> Subject: Re: [Gnumed-devel] encounter - translation
>
> These enconter - episode - issue translations are still a big step on my
> translation ... I grasp the concepts and I understand where they come from
> ... but they seem unaplicable in my practice settings (my brazilian brain
> can't seem to get to how to translate it)

Imagine a patient with arterial hypertension, diabetes
mellitus 2, and coxarthrosis deformans. This patient also
currently suffers from a minor common cold (I am consciously
avoiding the word "flu").

Now tell yourself:

        "This patient suffers from arterial hypertension, diabetes
         mellitus 2, coxarthrosis deformans, and a minor common
         cold."

Now tell yourself that you don't worry about the common cold
because it'll be over in 5 days:

        "This patient suffers from arterial hypertension, diabetes
         mellitus 2, and coxarthrosis deformans."

Now become lazy and say:

        "This patient suffers from 3 health issues."

Now fill in the blank in this pseudo-brazilian sentence:

        "El paciento suffero de 3 ..."

(never mind, I tried ;-)

Does that help ?

> I got so far:
>
> issue can have multiple episodes

Stop right there. Encounters are orthogonal to that.

> that can have multiple encounters (visits -
> this one I fully get ;), but it seems it is not a tree view you guys have in
> mind ...

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.

This structure IS NOT really a tree !  That is also the
reason why the same encounter will show up more than once in
the tree view -- once under each episode worked on during
that encounter.

> PS: Of course this discussion is kind of "lost-in-translation", what I
> should be thinking is how to make my view of issue-visit fit the way the DB
> is set up ;)

No no no. You should NOT do that. You should

a) try to understand why GNUmed thinks longitudinal health
   care *can* be structured like that

b) try to find good arguments *against* this issue-visit concept

We can then evaluate together whether those arguments
invalidate the model.

You will come to an understanding of why the issue-visit
model is (AFAICT) a valid way of structuring care. It is not
the ONLY model, though, I suppose. So, your own model may
well be valid, too.

> -- although as one of my teachers said in the past
> (administrative concerns should fit the practice, not the other way around).

GNUmed tries to present one (hopefully) well-thought out
model. It is not without flaws - of which I'd love to hear.

However, the above definitely is a basic design concept for
GNUmed - we try not to give up proper medical thinking for
administrative reasons.

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


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

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

_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[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


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

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

>> ‘Episode of care’ is a very vague concept

This surely is true as in that the "end" of an episode can
only really ever be recognized in retrospect.

Dealing with vagueness is one of the core specifics of GP care.

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


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Rogerio Luz Coelho]

Ok so I´ll try to explain how I am using so far GNUmed and the way it stores my patient data:

*** I am not currently connected to a GNUmed DB so the terms in English could be messed up.

1st Visit) Patient gives name and DOB and tells why she came to me
- back pain.

-- ) Put "I have back pain" in the RFE field

-- ) take family history if any
  -- FUNDATIONAL HEALTH ISSUE = "Family History" with multiple --notes-- one for each     problem that is relevant (precocious CVD, genetical issues, Cancers, etc..)

-- ) take personal history
 -- ONE FUNDATIONAL HEALTH ISSUE PER PROBLEM = Hormonal Birth Control, Skin Problems, Osteo-Muscular problems, etc... AND a ISSUE called "Back Pain"

-- ) Start to colect the SOAP

-- ) Enlist all Measurements that are of note (I sometimes also put the REALLY important ones in the sOap field - so you can see them the next time you see the patient when you click on the open encounter view of the Note applet)

-- ) Define the Summary of the visit (here I think I start to get in some problems with the design)  as " First Visit, Back Pain , asked to do this and that and return in 2 weeks"

_____________________________________________________

2nd Visit) Now 2 weeks pass and patient is better but not 100%

-- ) Click on "Back Pain" in the Note Plugin, new Note has "Back Pain" on the title.

-- ) RFE = " Better but not 100%"

-- ) SOAP

-- ) Summary = " Better but not 100%, start acupuncture and return weeklly for 1month"  ** ;) my free on-list merchandising ;) **

-- ) Save = GNUmed asks if I want to close the new or old (see ??? - I am thinking a little different of the design, because it seems obvious to me that if it was supposed to work the way I am doing things the client would not ask me nothing ;)

*** on the way out patient says "Oh doctor, I want to discuss also my Birth Control Method"

-- ) Click on "Hormonal Birth Control" and a new Note opens.

-- ) RFE = Birth Control Guidance

-- ) SOAP

-- ) Summary = Changed Birth Control method to Hormonal Pills with Drosperidone and only 4 days off = "Yaz"

-- ) Save

________________________________________

3rd Visit) one week later patient tells us she is better form back pain after last acupuncture session, seems 100%

-- ) RFE = Better, maybe 100%

-- ) Click on "Back Pain" - new note is created

-- ) SOAP

-- ) Summary = "Better seems 100%"

-- ) Click on "Hormonal Birth Control"

-- ) SOAP

-- ) Summary = "All is fine with 1 week use"

Save
______________________________________

Any thoughts?

You see my method of using GNUmed is a Problem --> Visit paradigm.

Please feel free to enlighten what you think could change for easier use :)

Rogerio     




_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Sat, Nov 07, 2009 at 07:26:45AM -0300, Rogerio Luz Coelho wrote:

> Ok so I´ll try to explain how I am using so far GNUmed and the way it stores
> my patient data:
>
> *** I am not currently connected to a GNUmed DB so the terms in English
> could be messed up.
>
> 1st Visit) Patient gives name and DOB and tells why she came to me
> - back pain.
>
> -- ) Put "I have back pain" in the RFE field
>
> -- ) take family history if any
>   -- FUNDATIONAL HEALTH ISSUE = "Family History" with multiple --notes-- one
> for each     problem that is relevant (precocious CVD, genetical issues,
> Cancers, etc..)
>
> -- ) take personal history
>  -- ONE FUNDATIONAL HEALTH ISSUE PER PROBLEM = Hormonal Birth Control, Skin
> Problems, Osteo-Muscular problems, etc... AND a ISSUE called "Back Pain"

Personally, I would make the "back pain" an *episode* first,
unless I know it really is a long-term underlying issue.

> -- ) Start to colect the SOAP
>
> -- ) Enlist all Measurements that are of note (I sometimes also put the
> REALLY important ones in the sOap field - so you can see them the next time
> you see the patient when you click on the open encounter view of the Note
> applet)
>
> -- ) Define the Summary of the visit (here I think I start to get in some
> problems with the design)  as " First Visit, Back Pain , asked to do this
> and that and return in 2 weeks"

IF during that encounter the only *active* problem being
worked on is the "back pain", then, yes, that makes sense.
Otherwise I would put it into the soAp of the back pain
note. The AOE / Summary would become "new patient / back
pain" for me.

> 2nd Visit) Now 2 weeks pass and patient is better but not 100%
>
> -- ) Click on "Back Pain" in the Note Plugin, new Note has "Back Pain" on
> the title.
>
> -- ) RFE = " Better but not 100%"

To me that's Soap, but, hey, you decide. I would write "more
back pain help wanted" or something like that -- what the
patient *wants*.

> -- ) SOAP
>
> -- ) Summary = " Better but not 100%, start acupuncture and return weeklly
> for 1month"  ** ;) my free on-list merchandising ;) **

Again, I'd put that in soAp. Again, IF only back pain was
worked on the Summary would be: "back pain: start acupuncture"

(my way of doing things)

> -- ) Save = GNUmed asks if I want to close the new or old (see ???

Huh ?  That episode of back pain is still going on, isn't
it? That second visit should be part of that first episode.
It will be a new encounter, however, that's true. But if
that encounter truly is 2 weeks back it will not be
considered for continuation (unless you've got really weird
configuration going on in your database)

>  - I am
> thinking a little different of the design, because it seems obvious to me
> that if it was supposed to work the way I am doing things the client would
> not ask me nothing ;)
>
> *** on the way out patient says "Oh doctor, I want to discuss also my Birth
> Control Method"
>
> -- ) Click on "Hormonal Birth Control" and a new Note opens.
>
> -- ) RFE = Birth Control Guidance

No. This is still the very same visit. So you need to *add*
to the RFE which might become:

        "back: <100% better // birth ctrl: review"

> -- ) SOAP
>
> -- ) Summary = Changed Birth Control method to Hormonal Pills with
> Drosperidone and only 4 days off = "Yaz"

Again, same visit, so *adding on*:

        "back pain: start acupuncture // birth ctrl: now Yaz"

> 3rd Visit) one week later patient tells us she is better form back pain
> after last acupuncture session, seems 100%
>
> -- ) RFE = Better, maybe 100%
>
> -- ) Click on "Back Pain" - new note is created
>
> -- ) SOAP
>
> -- ) Summary = "Better seems 100%"

AOE: "back: seems 100%"

> -- ) Click on "Hormonal Birth Control"
>
> -- ) SOAP
>
> -- ) Summary = "All is fine with 1 week use"

AOE: "back: ~100% // birth ctrl: OK @ +1/52"    ;-)

> You see my method of using GNUmed is a Problem --> Visit paradigm.

I see, yes.

> Please feel free to enlighten what you think could change for easier use :)

Well, what you *could* do is to serialize per-problem SOAP
input and force a new encounter for each problem and make
them chronologically consecutive.

This would give you some pain, however, when you discover
you want to document something else after you already forced
the new encounter for the next problem. It won't be
impossible because GNUmed now supports editing previous
notes which you could use to add on to a "previous"
encounter but it's not particularly convenient.

Here's the big BUT to all of what I said above: Whichever
way you use GNUmed - it is important that it helps your
practice. It is not important what I think you should or
could do !

You might want to add a wishlist item on launchpad along the
lines of:

        Improved integrated editing of previous encounters'
        notes and/or enable the notes editor to load old notes
        for editing.

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


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel