gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] EMR journal soap row type / representation "ADM" & ot


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] EMR journal soap row type / representation "ADM" & other feedback
Date: Mon, 22 Jun 2009 11:06:47 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Jun 21, 2009 at 03:14:34PM -0700, Jim Busser wrote:

> I was looking at the rows in a journal and identified that the "Adm" is 
> maybe not ideal. In English and with a major amount of hospital activity 
> I am always thinking it means "Admit"

That's why we need native speakers from the trenches and why
I am happy to have people like Liz around who only say a few
words once in a while.

> and also the intended meaning 
> "Administrative" is maybe not correct because these rows were in many 
> cases user-entered by a clinician who was providing a clinical name for a 
> foundational health issue or fpr a clinical episode.

I know. I wasn't sure imploring too much meaning onto them.
Do you think it'd be fine to label issues and episodes as
"soAp" -- because they, indeed, present some sort of
assessment on the situation ?

> Conveniently (at least, often), when an episode name had been provided 
> (for a new episode), this record will be sequenced after the SOAP rows 
> within this encounter, unless more get added before this encounter is 
> closed.
This is rather accidental.

> Can we, in place of "ADM", show "=" in the S O A P column, as this still 
> respects that the row was not a traditional soap row (but is rather a 
> clinician-entered "meta" row) resulting from some clinical evaluation?
Well, all we got is "s o a p" or NULL, database wise. We
could, however, do some post-parsing but before doing so we
should think a bit more on whether it may not be done better
another way (eg. making issues and episodes appear as soAp
rows).

> Likewise shown among EMR Journal rows as "ADM" are the Foundational  
> Health Issues. These had also been user (clinician) entered (when they 
> were not imported from a legacy EMR),
And even there they were most likely created by a clinician.

> and could also be argued to be 
> derived if unverified entities. They could likewise be represented with  
> "=" in the S O A P column?
See above.

> Can the other "administrative" rows such as may arise from encounters  
> created by lab results importers (or from record activation when  
> browsing a record) be de-emphasized in the layout by designating them in 
> the S O A P column with an"ellipsis" (three dots) instead of "ADM"?

Can I take this as a suggestion to use the ellipsis instead
of "Adm" to actually mean "administrational" ?

> Can we remove the word "Foundational" from "Foundational Health Issue" in 
> the EMR Journal and simplify its appearance to
>       "Health Issue: <issue name>"

Done.

> I noticed in the journal an appearance of "Happened... None" for a sOap 
> row "Allergy state: unknown, unasked (date time) and even while I was not 
> (as a user) prompted to intereact with the allergy state I am wondering 
> why it got documented?

It didn't. Clearly "unknown, unasked" (which, perhaps,
should be "unasked, therefore unknown" ;-) is a state which
simply exists, no need to explicitely create it ...

However, the date is confusing as it is a system-generated
state. Oh, wait, the date is only displayed if the user
actually DID work on the allergy state at one time (the
system only generates a null value) but then *decided* to
leave it at "unasked/unknown".

> I suppose the system may be documenting that I did 
> not ask it
In that case there would be no date. Seeing a date means
that at that date did you explicitely decide to leave the
state at "unknown" (or set it to that).

> however I do not like that it is implying I should have, 
> without it having offered to help me do what it seems to have decided I 
> ought to be doing :-)

All Your Care Are Belong To Us !  :->

OTOH, it does sort of help you be reminded of it - it
displays a "?" in the Caveat for that state ...

Do you think it should help more directly ?

IMO that would be a perfect example for using the hook script:

- when a person is activated
        - hook "post_patient_activation"
- if said person is a patient
        - "person.is_patient is True" as per previous discussion
- if allergy_state is unknown
        - emr = person.get_emr()
        - emr.allergy_state['has_allergy'] is None
- prompt user

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




reply via email to

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