Re: [Gnumed-devel] clin_health_issue - some thoughts

[J Busser]

At 6:40 PM +0100 11/14/04, Karsten Hilbert wrote:

> I'll try to propose a structure this week
> that implements the
> defines_* fields in clin_narrative thereby consolidating
> the
> is_active/is_clinically_relevant business
> if no one objects.
> snip...
>
> Further discussion welcome.

I think we want to understand how adequately would the health_issue / episode / diagnosis schema meet our clinical needs.

I have been thinking a lot about "episodes" because how we frame them, and enclosing health_issues, is key to deciding what we intend them to mean, and how they can be used.

At its narrowest, we may want an episode to be able to capture a single symptom, or a patient concern (e.g. a risk factor perceived, or truly present, or potentially present as with family history) or an abnormality on examination, or on testing. One episode may capture the entirely, or only a slice in time, of the eventual longtitudinal thread of care encounterlets (my term, if people will suffer it, to distinguish from overall encounters [visits] the snippets within each encounter that pertain to a given thread).

Whether a user bothers to segment this longtitudinal thread into discrete episodes is entirely optional and two clinicians might choose different cutpoints. It is interesting to consider that after a clinician flagged an episode to have become "inactive", a patient could return to ask questions, or obtain clarification, that does not really warrant a "new" episode, so can we permit a new encounterlet to be attached back to the most recent, pertinent episode even though it was already changed to inactive?

Perhaps the impetus to change an episode from is_active to "not" is when it becomes superceded by a new episode, as warranted by some new development (as suggested for example by Karsten in a previous email e.g. at a point of "loss of BP control"). In this case, the function of is_active becomes instead is_open (or its opposite, is_closed) to denote that beyond a certain point, no further encounterlets should be attached, because they should instead be linked to the superceding, "open" (not closed) episode.

In database terms, the is_active column just served to communicate that that the (computer) episode status remained "active", but this terminology competes with our clinical mode ("active" health issues, disease). Patients who feel better, and whose problems may in fact have become inactive, may decline to come back until a need arises. When they next come back, perhaps for some other issue, you may discern that earlier *clinical* episode may not have been "active" at all. More correctly, it is just that the (computer documentation) episode has remained "open".

Is_open might serve a clearer purpose, as above. Now some may be thinking "well, we still need is_active as the basis to filter (in) episodes of interest" - but do we? That which is not "clinically_relevant" will not be very important, but may need to stay in view because there are still actions pending e.g. a need to see the patient again in followup, a test request whose result is not yet returned, a quick phone discussion you need to have with a colleague / consultant. *** But *** I would say  "why not let the existence, or lack, of such things be the determinant of whether an episode is 'active'".? After all, why would you want to keep in view an episode that was "active" yet for which there are no incomplete or unreviewed tasks, results, or plans/arrangements for the patient to come back? If there remains a benefit to keeping is_active, it might be nice if we could prevent or dissuade a user from changing it to is_active while test requests remain unresulted and unreviewed etc.

---

I am working on some use cases to better illustrate episodes and what we may want them, and the health_issues and diagnoses, to be able to accomodate.