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

[Karsten Hilbert]

> how about:
> an episode is active until its (most recent) AOE is assigned some state 
> other than "xxxDEFAULTxxx" or "active"
that's one way

> >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.
The above was not assuming an active/inactive flag. The less
active the further down the list an episode would appear.

> 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.
Turning off the timeout on a per-episode base is a lot of
trouble and doesn't incur less work than adding an is_active
flag to the episode table.

> But the backend is planned to support a data value of "closed" for the 
> episode, yes?
It does not have one right now but that's trivial to add.
Probably a combination is best: Make is_active=true the
default. Grab only is_active episodes. Display them sorted
most-least recent.

> 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.
Quite correct. It doesn't actually contain too much data
either right now.

> 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?
A good thought. When I was designing the episode table I did
not clearly understand RFE/AOE/aP/soAp yet. If people tell me
drawing the episode name from the most recent AOE resp. aP is
OK I'll be happy to do that. It seems to make sense.

Here are the relevant tables/views:

*-----------------------------------------------
create table clin_episode (
        id serial primary key,
        fk_health_issue integer
                not null
                references clin_health_issue(id)
                on update cascade
                on delete restrict,
        description text
                default 'xxxDEFAULTxxx',
        unique (fk_health_issue, description)
) inherits (audit_fields);

select add_table_for_audit('clin_episode');

comment on table clin_episode is
        'clinical episodes such as "recurrent Otitis media", "traffic accident 
7/99", "Hepatitis B"';
comment on column clin_episode.fk_health_issue is
        'health issue this episode is part of';
comment on column clin_episode.description is
        'descriptive name of this episode, may change over time; if
         "xxxDEFAULTxxx" applications should display the most recently
         associated diagnosis/month/year plus some marker for "default"';

-- unique names (descriptions) for episodes per health issue (e.g. per patient),
-- about the only reason for this table to exist is the description field such
-- as to allow arbitrary names for episodes, another reason is that explicit
-- recording of episodes removes the ambiguity that results from basing them
-- on start/end dates of bouts of care,

create table last_act_episode (
        id serial primary key,
        fk_episode integer
                unique
                not null
                references clin_episode(id),
        id_patient integer
                unique
                not null
                references xlnk_identity(xfk_identity)
                on update cascade
                on delete restrict
);

comment on table last_act_episode is
        'records the most recently active episode per patient,
         upon instantiation of a patient object it should read
         the most recently active episode from this table,
         upon deletion of the object, the last active episode
         should be recorded here,
         do *not* rely on the content of this table *during*
         the life time of a patient object as the value can
         change from under us';

create view v_pat_episodes as
select
        chi.id_patient as id_patient,
        cep.id as pk_episode,
        cep.description as description,
        chi.id as pk_health_issue,
        chi.description as health_issue
from
        clin_episode cep, clin_health_issue chi
where
        cep.fk_health_issue=chi.id
;
*-----------------------------------------------

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