Re: [Gnumed-devel] clin_health_issue - some thoughts

[Karsten Hilbert]

> But if over time there is
> - more than one episode of back pain
> - more than one episode of spells of dizziness etc
> 
> ... it would be entirely reasonable to want to be able to aggregate 
> them
I agree. String proximity could help, eg. "lower back pain"
sorts closer to "back pain, lumbar" than "leibinger induced
osteomyelitis". Which could be applied *within* episodes
belonging to one and the same health issue thereby not
generating significant amounts of false positive matches.

> but there is no mechanism by which to do so
True.

> you would have to 
> pick them out visually and this gets even harder if each episode 
> takes on the name of a changeable AOE. And what happens if the 
> health_issue is sufficiently broad that its various episodes do not 
> all fit within a single GUI screen?
That is where your suggestion of "show relevant ones only with
a show all button". Also, the space issues isn't specific to
how to sort/link episodes.

> I am a bit stymied because I cannot tell whether no-one on the list 
> thinks it useful to be able to aggregate (to see grouped together in 
> a GUI widget) any relationship among episodes, or whether there is 
> subconscious agreement and only a nagging feeling of how to do this 
> without complicating the data structure.
I for one think it is useful. I also, however, tend to think
that in many if not most cases there'll be only very few
concurrently open episodes per issue. I have the feeling that
screen space will suffice. After all we got Richard's designer
skills available (no sarcasm intended).

> If we stay to Karsten's proposal that a health_issue is a "cause" and 
> an episode is a cluster of "problem activity" -- but various episodes 
> can either be different problems, or "newly opened" incarnations of a 
> previous problem, then we need to keep the names of the "newly 
> opened" episodes the same as the names of the older ones
That is another way of doing it.

> the "problem" can 
> have all of its episodes named identically based on some user-defined 
> name maybe updated via AOE (however we would then lose the ability of 
> the AOE to speak specifically to the episode in question ).
Not quite. The AOE can still be there to convey meaning on the
current state of affairs. It needn't be the row naming the
episode. GnuMed is flexible (complicated ? ;-) enough to allow
for *any* narrative row (well, it must belong to the episode
in question) to function as the name of said episode.

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