Re: [Gnumed-devel] Storage and and representation (formatting?) of past history items

[Karsten Hilbert]

On Sun, Jan 13, 2008 at 10:30:50PM -0800, James Busser wrote:

>> root
>>  issue
>>   episode
>>    encounter
>>   episode
>>    encounter
>>  issue
>>   episode
>>    encounter
>
> Please remind me whether "root" serves as the underlying, foundational, 
> fundamental medical disorder
No, it's the same as saying "Person X" or "EMR of person X".
What you describe is the second level named "issue" -
underlying, foundational medical issue - of which for some
episodes of illness there may not be or (or not yet known).

> ... or does "root" above refer to "clin_root_item" which is not meant to be 
> used for any "clinical" purpose except to make possible the electronic 
> "inheritance" function of being able to link related parts across multiple 
> tables?
The "clin_root_item" is similar but is not the same.
clin_root_item is just a technical artefact while "root" is
a concept. I should have said "root of the EMR sorted
tree-like by medical conditions" but that seemed verbose at
the time ;-)

> The reason that I ask is because a patient could, for example, present with 
> hematuria that turns out to be due to kidney stones and that episode may 
> subside over a few encounters, only to become active after many months or a 
> few years with more problems, so these may be considered multiple episodes 
> of kidney stones where kidney stones (nephrolithiasis) is entered as the 
> "issue" (= clin_health_issue?)
Exactly. The association can be made post-hoc when I realize
that those episodes of pain, of hematuria, of creatinin
elevation are all of the same cause.

> So... what happens if the patient develops pancreatitis and is found to 
> have elevated calcium (hypercalcemia) and it turns out they they have 
> hyperparathyroidism. It is probably reasonable to be able to record in the 
> EMR tree that this patient has had issues of
>
> - hematuria (although maybe this is disagreed, from the point of view that, 
> as a manifestation of the kidney stones, the hematuria was just a symptom 
> and it is satisfactory to just leave hematuria as the name (label) of the 
> enclosing episode that becomes nested under kidney stones)
Eventually it may get nested under that. Until then I
personally keep it as a free-standing episode "hematuria".

> - kidney stones as an "issue" which is believed to have caused the 
> hematuria (even though the kidney stones themselves may have been caused by 
> hypercalcemia caused by hyperparathyroidism)
At the time this becomes clinically evident I would reorder
the EMR to have an issue

        "hyperparathyroidism w/ complications"

under which I would have episodes as needed

        "11/07 hemuturia (nephrolitiasis)"
        "12/07 hypercalcemia"
        "1/08 acute pancreatitis"
        ...

> - hyperparathyroidism (later found to be a parathyroid adenoma)
And when that becomes known one might either chose to
reorder again for the issue "parathyroid adenoma" or relabel
to "complicated hyperparathyroidism due to adenoma".

That is at the discreetion of the treatment team.

Eventually, this may go on and on: the adonma may be found
to be part of a systemic glandular cancer. Which may be
found to be due to a certain genetic defect. Which may be
found to be due to a radiation or chemical exposure. The
foundational issue becomes higher and higher levelled.

Pragmatism in a GP office dicates to make do with three levels:

apparent causating health issue (may change over time)

        episode of activity of symptoms of issue

                patient-provider interaction incident within episode

> Basically what I am appreciating is that if a patient's many manifestations 
> of their problems become "hidden" by virtue of their living at the level of 
> the episode names, then when one reviews a patient, for example presenting 
> with some abdominal pain, and the doctor looks at their EMR tree, they will 
> not see pancreatitis unless they click open sufficient numbers of the 
> child-indicator triangles.
This is true in the current tree.

> This suggests to me that we may need a control 
> that will at least expand all child items to their first level.
This can indeed be useful. What you might be arguing for is
a "clinically_relevant" indicator at the episode level which
defaults to false (because I don't want to see the umpteenth
episode of lumbar pain or flu). With this the user can
indicate that an episode remains relevant even if closed at
a later time ?

> Could/should such a control "live" in the right-click (control-click) 
> contextual menus that are already offered in the EMR tree?
I'd think the "initial plugin" after a patient search such
be much more tailored to quickly informing about the
patient. It shouldn't be the EMR tree browser in the first
place. But that widget hasn't been written yet :-)

> I am thinking 
> that at the level of the top-most item (the patient name which doubles as 
> the EMR menu) we can offer "Open all to..." and then a submenu "issue level 
> / episode level / encounter level". At successively more-deeply nested 
> levels of the tree (for example at the level of any one health issue) the 
> menu item would just say "Open to..." instead of "Open all to..." and the 
> options would be fewer.
That is not a bad idea at all. I earmarked it for 0.2.9.

> Lastly is there a desire to avoid keyboard bindings like 
> Command/Control/Alt + key for example modifier+O for Open, modifier+E for 
> edit?
The code doesn't currently make assumptions about that. I
find them useful but they take time to implement.

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