[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] clin_health_issue - some thoughts
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] clin_health_issue - some thoughts |
Date: |
Sun, 28 Nov 2004 14:53:19 +0100 |
User-agent: |
Mutt/1.3.22.1i |
> > 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
- Re: [Gnumed-devel] clin_health_issue - some thoughts, J Busser, 2004/11/17
- Re: [Gnumed-devel] clin_health_issue - some thoughts, Karsten Hilbert, 2004/11/17
- Re: [Gnumed-devel] clin_health_issue - some thoughts, J Busser, 2004/11/18
- Re: [Gnumed-devel] clin_health_issue - some thoughts, Ian Haywood, 2004/11/19
- Re: [Gnumed-devel] clin_health_issue - some thoughts, J Busser, 2004/11/19
- Re: [Gnumed-devel] clin_health_issue - some thoughts,
Karsten Hilbert <=
- Re: [Gnumed-devel] clin_health_issue - some thoughts, J Busser, 2004/11/28
- Re: [Gnumed-devel] clin_health_issue - some thoughts, J Busser, 2004/11/28
- Re: [Gnumed-devel] clin_health_issue - some thoughts, Karsten Hilbert, 2004/11/29
- [Gnumed-devel] Aggregating health issues on screen., Richard Terry, 2004/11/28
- Re: [Gnumed-devel] Aggregating health issues on screen., Karsten Hilbert, 2004/11/29
- Re: [Gnumed-devel] Aggregating health issues on screen. - Contextural Info, Richard Terry, 2004/11/29
- Re: [Gnumed-devel] Aggregating health issues on screen. - Contextural Info, Karsten Hilbert, 2004/11/29
- Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Info, J Busser, 2004/11/30
- Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Info, Karsten Hilbert, 2004/11/30
- Re: [Gnumed-devel] clin_health_issue - some thoughts, Karsten Hilbert, 2004/11/29