Re: [Gnumed-devel] vocabulary question - doctors, please speak up

[Karsten Hilbert]

On Wed, Nov 29, 2006 at 10:00:34AM -0800, Jim Busser wrote:

> I was thinking something like "Foundational issues".
Sounds fine with me. I'd just like to get some øre input. It
was suggested keeping the German "Grunderkrankung", too.

> Would a mathematical analogy be anything like "prime numbers"...
In fact, sort of, yes :-)  We should like to think that with
the identification of a Foundational Issue we diagnosed
something which doesn't have to be abstracted/grouped at a
higher level. Just like primes cannot be divided any further.

> are we  
> seeking a level of labelling to which manifestations and  
> complications can get attached?
If we equate manifestations and complications with episodes
of (significant) activity of the Foundational Issue, yes.

> I am waiting til I get time to play a bit more with a newer version  
> of gnumed.
One way might be to download the latest live-CD. Another way
is to use a pre-compliled vmware instances. Or else just do
"apt-get install gnumed-client" :-)

> In the meantime if it may affect the answer Karsten is  
> looking for I was again thinking how these "levels" of categorization  
> work. The following is a bit free-form but maybe that is OK :-)
Sure.

> We can have a symptom whose diagnosis is delayed. Diarrhea can later  
> be diagnosed as due to Crohn's. We have previously discussed that the  
> label can change from "diarrhea" to "Crohn's" with the diarrhea  
> information preserved inside the notes.
Definitely. The morphing you describe is most likely one
from "symptom", "syndrome" to established diagnoses. When it
becomes a substantialized diagnoses and turns out to be
expected to be a longer-term issue the doctor is likely to
turn the episode "diarrhea" into a Foundational Issue
"Crohn's". All the information is, of course, preserved. The
client frontend will offer an option in, say, an episode
right-click popup menu saying "promote to Foundational
Issue" which will create a new issue, attach the existing
episode to that issue and allow optional adjustment of the
names of both issue and episode.

> I think we also established  
> that an episode of illness that does not acquire a deeper explanation  
> may not get attached to some foundational issue,
Definitely. This is already supported.

> but until the  
> Crohn's is diagnosed it would be important to be able to view in one  
> place all of the episodes of diarrhea that were *not* yet given some  
> explanation or attachment to a foundational health issue.
Yes, this is useful. It isn't supported yet, however. One
way to support is by grouping unattached episodes based on
codes attached to their labels. This is what Richard seems
to use to pull up related episodes.

> Maybe these  
> unattached episodes of diarrhea would collect with all the episodes  
> of sore throat and all the episodes of cough or bronchitis under  
> Unattached/Other...
Currently, yes, exactly so.

> and these could be viewed by date or by name to  
> permit the recognition that a patient has X episodes of bronchitis, Y  
> episodes of ear infection and Z episodes of diarrhea in a 3-year  
> interval, maybe they have an immune deficiency.
Absolutely, that's what it looks like and that's what the
currently available EMR tree view facilitates.

> When the patient returns with diarrhea, it is not always from  
> Crohn's. It could be gastroenteritis, or lactose intolerance, or  
> Clostridium difficile.
True. In GNUmed the linking is not done automatically based
on a coding system. It is done explicitely by the provider
(and can be undone/changed at will).

If I want to add another episode to the Crohn's I'll do that
via the GUI. If I want to start another unrelated diarrhea
episode I just start a new one that's unattached. If I later
decide differently I can join/split as needed. Eventually, a
tool *suggesting* joins based on codes will come in handy.
But it would need to be written (not hard, though).

> Crohn's sometimes requires surgery. Occasionally patients have lost  
> enough bowel that they get short gut syndrome producing diarrhea. So  
> how would those look in a data structure?
For one thing the Crohn's would be tagged with "operated
on". Then there's an auxiliary table where I can add a few
bits of information on the operation itself. The whole bout
of Crohn's that prompted surgery would likel show up as an
episode. Of course, the discharge letter is linked into that
episode.

If short gut syndrome is established it might enhance the
Foundational Issue label if that seems warranted. Others may
prefer to add another Foundational Issue "Short Bowel
Syndrome". We currently lack facilities to do explicit
internal linking between that and the Crohn's Issue. Which
is a gap in the schema but can be added quite easily.

> Crohn's
> Lactose intolerance
> (History of) C difficile colitis (after it has been treated)
> (History of) laparotomy with small bowel resection
> Short gut syndrome
This might show up as:

11/2001 Crohn's (operated 3/2002)
(established)    (label)        (is_operation aux data)

 - 10/2000 diarrhea
 - 12/2000 diarrhea
 -  3/2001 abdo pain
 -  8/2001 diarrhea
 - 11/2001 Coloscopy: Crohn's
 -  1/2002 DiffC colitis
 -  3/2002 diarrhea: lactose intolerance
 -  5/2003 lap/small bowel resection
 -  7/2003 re-lap/more small bowel resected
 - 11/2003 short gut syndrome

This would be part of a tree showing the EMR grouped by

- Foundational Issue(s)
  - Episode(s)
    - Consultation(s)

The above would be Crohn's == Foundational Issue, all the
lines below that == episodes thereof. The episodes would
stretches of Crohn's activity which where eventually
identified as manifestation of one or more complications of
the Crohn.

> We tend to think of the (History of) as "Past Medical History" and  
> "Past Surgical History" but may it be better to retain these items at  
> the same level of the data structure as they appear above, and simply  
> suppress the retrieval or display of the items we may not want to see  
> until we ask to review more completely the file?
Improved filtering is always useful so, yes, when the use
case is there it will be added.

> I know that in some systems there are special fields into which to  
> type "Past Medical" and "Past Surgical" histories but that impedes  
> the re-use of the data does it not?
That depends on how it is kept in the backend. If it's just
a dumb text field holding a word-processor like list of
lines stating history, then, yes, that's hardly reusable.

> I am sorry if I "run on" again with cardiac examples but if a patient  
> has heart failure and angina, those are "problems" that may have to  
> be managed at the same time as their underlying causes (coronary  
> artery disease, diseases on one or even multiple heart valves) are  
> surely important to keep track of.
Yep, this seems to be the place where content-related
linking of separate Foundational Issues becomes useful.
Whatever the provider decides to be important enough to
track as a Foundational Issue, fine. Make it one. We will
have to provide a linking mechanism so things can be grouped
better at the same level. Will put that onto my TODO list.
For the backend it's easy. Frontend support is not hard
either but needs to get done by someone.

> Going back to the Crohn's example, it can help to be able to produce  
> a relationship view of some of the problems for example the  
> following. But maybe this cannot adequately flexibly be done in a  
> software design and people will take the view that it must be  
> reserved for the human brain to do real-time or else would require  
> heavy tailoring to suit the mind of the individual user.
> 
>       Crohn's
>               (History of) laparotomy with small bowel resection
>                       Short gut syndrome
>               Monoclonal antibody therapy
>               Hematopoietic stem cell transplantation
>       Lactose intolerance
>       (History of) C difficile colitis (after it has been treated)

Translated into GNUmed speak this would be 3 Foundational
Issues (which are interrelated). One of which would be
tagged "operated". Then there would be 3 episodes under
Crohn (assuming those occured sequentially). We don't offer
the level of detail for short gut syndrom -- unless you want
to make it the Assessment Of Encounter of one of the
consulations under "lap with resection".

Also note that this always represents the users point of
view of the situation. I might group things somewhat
differently (assuming that's medically correct):

>       Crohn's
>               laparotomy with small bowel resection
>               Monoclonal antibody therapy
>               Hematopoietic stem cell transplantation
>       (History of) C difficile colitis (after it has been treated)
>       Lactose intolerance
>       Short gut syndrome

Again, that's always the point of view of the user who
establishes the grouping. We do not support user-defined,
separate groupings of the same data - mainly because we
focus on the "a few local providers at one facility working
in unisono" situation where there really should largely be
consensus on the patient situation. This is different from
how a couple of consultants who argue about a difficult case
might want to be able to group things (each to his/her
liking, that is ;-)

So, ultimately, it's in the eye of the beholder.

Some might simply prefer:

I-don't-care-about-Foundational-Issues
  * diarrhea
  * lap/resection
  * Crohn's
  * bronchitis
  * CHF
  * angina
  * tonsillitis

where there's only ever one (virtual) Foundational Issue -
IOW unattached episodes only.

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