[Gnumed-devel] episodes (was: need assessment from fellow clinicians)

[Jim Busser]

> > - active problems (aPs) are a subset of all of a patient's problems, 
> > so aPs can
> > (best?) be regarded as those problems that have the attribute 
> > "active".
> Yes and no. Except that I would propose to define aPs
> backwards using this algorithm:
> 1) grab all AOEs that are labelled "permanently relevant"
> 2) look at active episodes (how to determine that is up for grabs)

how about:
an episode is active until its (most recent) AOE is assigned some state 
other than "xxxDEFAULTxxx" or "active"

> 3) of those grab the most recent AOEs

> Or easier:
>
> 1) grab most recent AOE per episode
> 2) sort most-recent first

grabbing more than the active episodes will include those of 
questionable usefulness. Suggest any inclusion of the inactive ones be 
made optional as the means by which to extend the selection i.e. to 
troll among the "less active/inactive" episodes for problems that may 
have missed getting coded "permanently relevant", and/or in order to 
"clone" the inactive episode/problem into a new one

> > Yet problems, while active, can have further attributes:
> Those are not further *attributes* but rather
> further *states* combined with attributes, IMO.

good clarification / refinement

> > ...active-uncontrolled (by definition most "active" & likely source 
> > of RFEs)
> > ...active-controlled (parameters [like symptoms, measures] 
> > satisfactory)
> > ...inactive-dormant (able to recur)
> > ...inactive-cured (unable to recur e.g. appendicitis post 
> > appendectomy)
> [the most recent] state may be reflected in naming
> I am not really sure we need to hardcode the dormant/cured
> state into the tables ?

agree with limiting the hardcoding.


> > if coded as controlled or uncontrolled, be automatically understood
> > to be "active" whereas once the back pain improves, or the diabetes 
> > proved to be
> > gestational or steroid-related, these could be coded "dormant" thus 
> > understood to be
> > "inactive".
> The episode timeout (or other lifetime limiting mechanism)
> should do for "dormant".

A timeout risks hiding, from the doctor's view, the need for further 
care for any episodes that were not concluded. At minimum, the practice 
or doctor should be able to turn a timeout off, and this would 
preferably be the default.

> > - if within any one "open" episode more than one problem is being 
> > dealt with,
> Never, conceptually. That's what the most recent AOE == aP
> paradigm is based upon...else we
> would be equating aPs with "symptoms that sufficiently bother the
> patient to seek care".
> Episode of Care ==
> "Episode of Care for one Particular Health Issue".

The "for one Particular Health Issue" resolves the ambiguity that had 
been giving me trouble.

> > does
> > the episode remain "open" until the last of the problems achieves the 
> > status active-
> > controlled (or can an episode be "forced" closed if the patient and 
> > doctor agree
> > that partial control is all that can be achieved until the patient 
> > can later engage
> > again in a future episode)
> IMO up to the doctor/patient, not the programmer :-)

But the backend is planned to support a data value of "closed" for the 
episode, yes?

Lastly, I would think the "episode" is merely the entity/value which 
either defines a single encounter, or links together a series of 
encounters, to constitute any single distinctive episode. Is it not 
enough that the episode is "characterized" by both the RFE and the AOE, 
do we need or actually even want a separate "name" for each episode?