Re: [Gnumed-devel] clin_health_issue - some thoughts

[J Busser]

At 4:05 PM +0100 11/24/04, Karsten Hilbert wrote:
>  > So if we keep it at all, is_active should have to be automatically
> >  set to inactive when a new episode is created (within an issue).
> I am not so sure. Consider this use case:
>
>  1996 traffic accident with polytrauma
>
> In my charts this would become a health issue
>
>  "post-polytrauma (traffic acc '96)"
>
> Suppose that patient suffers several long-term problems from
> that.
>
> 1) recurrent back pain
> 2) an episode of osteomyelitis at the site of metal plating
>
> I can perfectly imagine each of such episodes being active at
> the same time, eg.

Ah, here is where the design has been troubling me. If the health 
item is an overarching one as is the case with your post-polytrauma 
above, it is the only link across the various episodes. As a result, 
all of the back pain episodes (some variably named as the details 
within tempt modified AOEs) will be interspersed among the 
osteomyelitis episodes... this example is not so compelling because 
maybe there is only one episode of osteomyelitis... but in the event 
of mutliple "issuelets" each of which have several episodes we have 
no means to isolate, and view as a series to retrospectively 
scrutinize, the series or thread of episodes that pertain to any one 
issuelet. Sorting by AOE will not cut it since the naming by design 
has not had to remain constant across the AOEs for that issuelet.

For example if diabetes mellitus is the overarching issue, I can 
foresee threads of episodes pertaining to issuelets:
- adequacy of glucose control (containing e.g. diet/wt loss info or 
is this "obesity")
- hypoglycemia (ay warrant splitting from general control)
- neuropathic pain
- foot care issues
- retinopathy care
- proteinuric renal impairment (or is this a separate issue)?

Maybe diabetes mellitus should not be the "issue" but should instead 
be a "diagnosis". That would better permit what I call "issulets" 
above to be allowed to be issues in their own right, linked via soAp 
/AOEs to a diagnosis record. The diagnosis could have a (?pivot table 
or other mechanism?) by which to tree-display the issues that had 
been attached. Issue episodes, over time, may link to more than one 
diagnosis, permitting the issue to be shown with an appearance under 
each. "Lung disease, on home O2" as an issue could be linked to any 
combination of emphysema, status-post lobectomy for lung cancer, 
asthma. It is true the lung cancer during its evaluation and 
management may have been an issue but if it was surgically cured it 
may no longer be an issue that needs management, only its 
consequences need management. So maybe in the example above diabetes 
could also have been an issue during its initial diagnosis but once 
it is diagnosed we manage it according to its component issues or 
"issuelets". Diagnostic codes exit for Karsten's poly-trauma so each 
of his 1) and 2) could be issues which they shared, in common, being 
coded to that item.

A limitation of the diagnostic codes is that their names 
("hypopotassemia" as a poor example) can feel clinically unnatural or 
otherwise fail to optimally describe our particular patient's flavour 
however there is no reason why we cannot, in the diagnosis table, 
have a field that lets us taylor the description usefully to our 
patient... the code remains as correct as it would have been before 
such tayloring and the "proper" description always remains available 
to be looked up in the source code table.