[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] clin_health_issue - some thoughts

From: J Busser
Subject: Re: [Gnumed-devel] clin_health_issue - some thoughts
Date: Wed, 24 Nov 2004 08:11:01 -0800

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]