[Top][All Lists]
[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