Re: [Gnumed-devel] Past History and Operations (was: please, we need feedback)

[Karsten Hilbert]

On Fri, Apr 15, 2005 at 09:13:30AM -0700, Jim Busser wrote:

> A problem list, beyond "past history"that is being carried
> forward, includes anything new at the current encounter.
Unfolding this means that past history is anything that came
up during an encounter (eg it was the title of an episode) and
later was deemed significant enough to keep around for one
reason or another. Which would mean it had become a
clin_health_issue. Good. (Note that not everything need to
have come up in one of *our* encounters. They patient may just
tell us about it, eg. relate what is traditionally known as
"past medical history".)

> If agreed, a problem list is then a combined result of
> - pre-existing active (therefore ongoing) problems
> - plus pre-existing inactive but significant problems
> --> note, at the point of beginning to use a new EMR,
>         above items would need to be "newly entered"
>         (unless feasible to import)
> - anything *new* at the current encounter
I agree. I would, however, enhance that last point to
"anything new that has come up pretty recently and is not
closed yet" - IOW a clin_episode that isn't closed yet.

> The "anything new" should be input through whatever
> is GNUmed's principal, clinical encounter widget, in
> order to reap any extra benefits that the method would bring.
Sure, the current progress note input widget - ugly as it may
be - allows to create new episodes. I am currently working on
allowing it to create clin_health_issues (IOW past history
items) when the keyword "phx" is typed in (will pop up a past
history edit area).

> The tidiest (low-tech, non-query) method by which to bring
> in "past" items in the midst of an encounter could be to pre-
> define a very simple file format in which the user can grab a file
> prepared at the time, or in advance, formatted to contain data
> to satisfy:
If formattable in advance what would be the point in delaying
the import until the encounter ?

If imported during the encounter why would we want to use a
"file format" instead of a widget ?

IOW what is the *source* of phx items you are referring to,
here ? Another - legacy - EMR ?

> The most painful (low-tech, non-query) method would be to
> have, next to oneself, a screen with the legacy app showing the
> info and cutting and pasting or else the paper chart and just
> typing it in. For this implementation, in order to input the items
> as clin_health_issues, is it proposed to use a "special" widget limited
> to clin_health_issue .description,  .is_active and .clinically_relevant?

Absolutely! In fact, we (Carlos and me that is) are combining
several concepts brought forth and laid foundation for by the
fine works of Richard and Ian: The resizing STC SOAP widget
with keyword popups, the edit area and the phrasewheel. In the
SOAP STC a keyword would popup an edit area of PHX which would
contain phrasewheels to facilitate rapid, context-supported,
dedicated input of PHX items.

Another place to allow adding/deleting/moving/modifying
episodes/encounters/issues is the EMR tree. Foundations for
that were laid by Syan.

> And of course, any issues recognized to be "new" at the
> encounter, once these have been entered and the encounter is
> concluded, effectively join (become part of) what will, at the next
> encounter, have been the past history ;-)
Yep.

> >"progress note may take a past history item as presenting problem"
> >- yep, we do that :-)
> 
> ... by virtue of "past history" items having been input as
> clin_health_issues?

Exactly. I am trying to find out (and getting confident that it
is) whether a clin_health_issue is sufficiently identical to a
past history item. It so seems given the additions I already
made to clin_health_issue (age_noted, is_confidential*,
is_cause_of_death).

 * until better implemenatation of confidentiality in 1.x ...

> What had been a clinical_health_issue of "abdominal pain",
> causing a person to be sent to hospital, gets treated with
> appendectomy.
Sure but is there value in capturing the "has been operated"
state in a dedicated field in the backend as opposed to simply
naming the past history item (eg clin_health_issue)
appropriately, eg "s/p appendekt (Crohn)" vs. "s/p appendekt
(post-abdo-pain)" ?  The advantage would, of course be to be
able to reliably *query* on the state of that operation flag.
Is that worth it I ask ??  If clinicians jump up and tell me
"Why of course! Because..." I'll attribute this to my newbie
state in medicine and add the field to the backend. I suspect
there is value because Richard does have the field. That's why
I am so stubborn in asking for the reasons.

> Some coding systems include procedures, Could such a code
> be attached to the soaP row?
Most definitely. In fact, the current (eg. 0.1) implementation
does not really attach codes to rows. It simply provides
code/system combinations associated with a term (free text) -
which then just happens to match a given narrative somewhere
in, say, a soaP row.

> ... whereas if the issue is being newly created in GNUmed as a
> past history item it may begin as "s/p appendectomy".
> 
> Now here is a question... in some cases the appendix is removed
> because of appendicitis incidentally noted while in the abdomen
> for a concurrent illness. In other cases it can be decided by a
> surgeon to remove an appendix in the absence of appendicitis.
> In every cases the patient could be designated as
> "s/p appendectomy" but that would obscure the nature of the
> past illness. I suppose if the illness had evolved within GNUmed
> this will be able to be reviewed without too much trouble. But
> even so supposing the patient had Crohns disease you would not
> replace the Crohns item with "s/p appendectomy", you would
> add the latter to clin_health_issues.
Sure, in that case I'd add a clin_health_issue
"s/p appendectomy (elective/Crohn's)". Richer descriptions as
to the how, why, and when could be attached to that health
issue via some proxy episode (closed) linking a few SOAP rows
as needed.

> As a separate thread we could remind
> me what we thought about alternate GUI forms / kinds of SOAP
> labels in place of or adjunctive to Subjective Objective (Hx Px etc).
Patient complaint
History taken
Findings
Assessment
Plan

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