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

[J Busser]

At 10:39 AM +0200 4/15/05, Karsten Hilbert wrote:
> "alternate name for past history could be 'problem list'"
> - good :-)

A problem list, beyond "past history"that is being carried
forward, includes anything new at the current encounter.

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

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.

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:

field1: clin_health_issue.description
field2: clin_health_issue. is_active
        (True for active ongoing)
field3: clin_health_issue. clinically_relevant
        (True for significant, whether or not it's active)

That is all that you really need if what you are doing is importing
into the current patient. You just need to be sure that it *is* the
same patient. The low tech way to do this would be to have your
"source" method provide and prepend to the file a comment line:
# <patient lastname, given names>, <dob> <other>

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?

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 ;-)

> Notice that, yes, there can be a clin_health_issue.is_active =
> True *without* any clin_episode.is_open = True attached.
> Example: Diabetes certainly is an active problem all the time
> but there need not be a currently open episode because it's
> under good control.
>
> Inactive but significant would be something that does not
> currently affect health (eg post-appendectomy state) but may
> well influence later medical decisions (differential diagnoses
> to acute appendicitis are more likely in post-appendectomy
> patients).

The above are helpful examples.

> "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?

> Questions:
>
> What is "Operation" used for ? Sure, it tells whether a problem
> is an operation or has been operated on but what do you use
> this information for ?  I would expect (I do so, that is) to
> enter issues as "post-appendectomy" which makes it
> self-explanatory. The only obvious advantage would be that the
> operation field makes it safely processable/queriable.
>
> The same question stands for "laterality".

What had been a clinical_health_issue of "abdominal pain",
causing a person to be sent to hospital, gets treated with
appendectomy. At the office encounter in which appendicitis
was suspected, it would have appeared in the soAp row and
the need to send to hospital entered in the soaP row (Plan).

The appendectomy would not (normally) be done at a facility
where GNUmed is in use as the EMR, but we should consider the
general case where for a treatment or "operation" is so.

Some coding systems include procedures, Could such a code
be attached to the soaP row? Would a code attached to a
soAp row suggest a diagnosis whereas a code that denotes
an operation be able to be attached to a soaP row?
And BTW are we still referring to this step "coding"?

If the patient had presented to a doctor using GNUmed in the
course of the actual illness, the description for the
clin_health_issue could have been "abdo pain" and successively
modified over time:
- at the end of the visit --> to "abdo pain - ? appendicitis"
- after the appendectomy --> to "s/p appendectomy".

... 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.

So when newly creating a patient record in GNUmed perhaps the
doctor will have to make a choice whether to enter both the
inciting illness and the status-post-operation as distinct
clin_health_issues. Perhaps in their legacy EMR they had
"appendicitis" as a Past History item, inactive but significant
and they also had an Operations item "appendectomy". In
moving to GNUmed they *could* simply enter
"s/p appendectomy" at a cost of losing richness and structure
I can understand Richard would want to preserve. So how about:

1. create a clin_health_issue to record (if of interest) the disease
or disorder that caused an operation to be done, otherwise
input a description as "status post..."

2. enter a soap note with any desirable details of the operation.
Not sure where details should go within "soap". If patient self-report,
then in Subjective. If from credible collateral,  it is yet info that
the doctor did not personally create, so maybe the soap row
should yet be "typed" as "s". 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).

3. decide where in the soap to put (code)? the operation. I guess
within the scenario, it is a History item, except when rendered in
the office/surgery. People can give it whatever text "name" they
want and it is next a matter of deciding how to code it so that
one patient's "appy" and another's "appendix removal" can both
be queried. Is our clinical coding supported as pairs
(coding_system, coded_value). Whereas some people may choose
to use ICD9, others ICD-10CM, others Reid etc and others a
combination (all optional) are we here proposing that GNUmed
by default include a gmOperations coding system with item
descriptions to be built up by those using any one implementation?