Re: [Gnumed-devel] clin_health_issue - some thoughts

[Karsten Hilbert]

> > because it is to this top one  that any new encounterlets should 
> > likely (and perhaps exclusively) be attached. I think that to back 
>                       ^^^^^^^^^^^
> IMHO this is a must, else my understanding of episode is totally wrong.
Imagine a post-polytraumatic patient. I would define a health
issue "post-polytrauma 1987". The patient might suffer
temporally unrelated (eg. overlapping and/or distinct)
episodes of osteomyelitis, back pain, spells of dizziness. All
of which would be episodes to the polytrauma issue (again, if
*I* took care of that patient). So it boils down to clinician
preference. We cannot preclude clinicians to make such choices
(but we can make it sufficiently hard GUI-wise to discourage
them from inputting "garbage").

> I have always wondered why episodes can't be inferred
> directly via timeouts (as we currently do with encounters),
> but on a larger scale.
I guess they pretty much can. Or rather a suggestion for
closing an episode and opening a new one when the patient
comes back could be guided by timeouts. Which should not
hinder the clinician to add another overlapping episode to the
issue (which MUST have a different name - this we enforce in
the backend).

> With is_active, is_clinically_relevant, etc., truth be told,
> I've never been happy with these flags, especially at different
> levels in the hierarchy, with no clear sematic meaning at the
> various levels (I'm not even convinced 'active' and
> 'clinically_relevant' are separate concepts.)
We have better naming now:

health_issue.is_active
health_issue.clinically_relevant
 (those two perhaps warrant improvement)

episode.is_open (not is_active)
no episode.clinically_relevant anymore

> The GUI is going
> to be a mess with tickboxes all over the place, and ticking
> them a right royal pain.
I don't think we need to many tick-boxes in standard workflow.

> I'm not sure how useful "is_active"
> really is, even if you declare an issue "closed", you never
> know when the patient is going to come back with a recurrence,
You never know but in many cases you are going to be right
anyways.

> treatment failure, etc., it's only really closed when a
> reasonable amount of time has elapsed.
At which point it should be offered for closing by the system.

> IMHO there is one concept, a continuous variable: the
> "importance" of a health issue, determining how they are
> displayed (most important at the top)
eg. clinically_relevant

> (episodes can't be
> important or not, as they are strictly time-sequential
Agree.

> This,
> again, should be inferred, a health issue is important if there
> have been recent episodes,
This could be built in regardless of whether we have that
relevant flag or not to test the workability of this idea.

> moreso if there are any outstanding
> results, recalls, etc,
This will be cumbersome to detect reliably.

> This means clin_diag needs an "actual_time" field,
It already does. In fact, any clin_root_item descendant
already does.

> so when the patient reports their open chole in 1979, that
> goes straight to be bottom of the list,
Unless you would want to mark it clinically_relevant (since
you might just be investigating the possible presence of
bilio-digestive system cancer in that patient).

> This should actually be the "fuzzy date" type that was mooted ages ago.
I still have it here on my hard drive.

> > In trying to better understand the relationships of the problems to 
> > each other, it can be helpful (as an option) to be able to have a 
> > user-controllable grouping or sort order. I will try and make the 
> > case for it in some use cases.
> Please don't add a fourth layer to the issue-episode-item hierarchy.
I would second that caution.

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