Re: [Gnumed-devel]

[Karsten Hilbert]

> ok , if the clinical_episode is only just to characterize time place and
> person,
Well, no. Here is what the comments say:

comment on table clin_episode is
        'clinical episodes such as "recurrent Otitis media", "traffic accident 
7/99", "Hepatitis B"';
comment on column clin_episode.id_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
         "__default__" 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,

> an you might be dealing with multiple issues when you see
> someone
Conceptually, during one Encounter you are dealing with
multiple Episodes, which may or may not belong to the same
Health Issue.

>       Clinical episode has a text field,which I'm not sure what its for
> (?unstructured progress notes) ,
comment on column clin_episode.description is
        'descriptive name of this episode, may change over time; if
         "__default__" applications should display the most recently
         associated diagnosis/month/year plus some marker for "default"';

And:

-- about the only reason for this table to exist is the description field such
-- as to allow arbitrary names for episodes,

Also, the Dutch paper cited in the writeup says, that the
"title" of an episode should be the current diagnosis attached
to it such that one can follow the progress of refining
diagnoses by looking at the changing episode "title". I find
this a tad too narrow a view and hence the blurb about the
__default__ being such and such with the option of explicitely
setting a title in .description.

>  but if it's just to aggregate time place person, I suppose it's
> acceptable as  a separate table, otherwise
> just use a multi-field primary index for clin root item.
Exactly how would you do this? Please post example tables. I
need to know how you intend to delimit episodes cleanly.

> I supppose someone is envisaging the system will be better than , say
> than OSCAR or OIO
I surely hope so.

> because it will have some sort of knowledge classifier
> that will automatically link your clin_root item to a patient issue;
Not sure about the automatic part.

> or like one Australian e-med system, ask what the clinical issue is
> after each prescription.
My plan is to have a "currently active issue/ episode/
encounter" to which any new input is attributed unless the
user explicitely switches to another issue/episode/encounter.
Of course, this will mean that >75% of data will end up
attached to the "default" issue/episode and system-generated
encounters (the latter of which is probably good).

>  Luckily, it isn't organized so that a root_item can link to more than 1
> clinical issue, or will that feature be required as well? (i.e.
> root_item_clinical_issue_link table).
This is one excellent point. I don't have the answer. A
clin_physical item "retinal scan" may belong to "ongoing
diabetes care", "vascular disease staging" or "post-traumatic
checkup", all in one and the same patient. This must be left
to clinical prudence I suppose.

> BTW, tone down the Domain Expert put down a bit, I've  suffering from
> people with that kind of attitude ( all that night shift for a drift
> into GP land). 
Sorry about your feeling bad. I'll happily acknowledge any
errors in the medical, computer science and social field that
I may have made.

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