[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Refactoring emr_journal progress note output
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Refactoring emr_journal progress note output |
Date: |
Tue, 7 May 2013 17:36:32 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, May 06, 2013 at 06:31:42PM +0000, Jim Busser wrote:
> I am using a GNUmed placeholder to output the past 12 months (52 weeks) of
> progress notes on a patient thusly:
>
> $<emr_journal::soap//{\footnotesize %(date)s } & {\tiny %(modified_by)s} &
> {\tiny %(soap_cat)s} & {\small %(narrative)s} \tabularnewline//very long
> line//52//tex::>$
You may want to consider looking at
u'soap_for_encounters', # lets the user
select a list of encounters for which
# LaTeX formatted progress notes are emitted:
# "args": soap categories // strftime date format
If anything it may help to better define your requirements
if you describe the shortcomings of that placeholder in
relation to your intent. Maybe we can/should improve *that*
placeholder.
> In this example, I
>
> - inputted an allergy
> - created a problem (using "Simple notes" plugin), and
> - created a progress note (in Notes plugin)
>
> After which the output (see screenshot of table) was presumably determined by
> postgres-assigned date-time stamps:
>
> a Putative subacute thyroiditis (in December 2012) resolved without
> evidence of anything more than mild goitre and small simple cysts not
> requiring intervention.
> p Inform patient there had been a typo in the original US report where
> the right cyst had been reported in cm not mm.
> a Health Issue (active, clinically relevant): Allergies/Intolerances;
> a Episode (closed): Allergy detail: Penicillin;
> s Sore throat improved post-clarithromycin for intercurrent "Strep throat"
> o Asymmetric thyroid slightly larger on the right.
> Feb 21 2013: TSH N, anti-TPO < 28 U/mL
> Apr 18 2013 US dimensions were
> right lobe: 1.7 * 1.5 * 6.7 = 17.1 cm^3
> left lobe: 1.8 * 1.4 * 5.1 = 12.9 cm^3
> simple cysts left lower pole (max 7mm) and right upper (max 5mm)
> a Episode (open): Goitre, mild, with 2 small simple thyroid cysts;
> o Allergy (allergy): blistering rash substance: Penicillin; allergene:
> Penicillin;
> o Allergy state: does have allergies (last confirmed 2013-05-06 10:49)
>
> but the above sequence breaks the convention in which we are used to
> understanding (brain-parsing) clinical notes.
The EMR Journal is dumb by intent, concept, design, and
implementation. It is a journal, so purely chronological. It
doesn't have any sub-structure (apart from time and SOAP
order). The journal is oblivious to the fact that its data
can mean anything other than rows of SOAP data at a
particular time each.
> Better would be:
>
> a Health Issue (active, clinically relevant): Allergies/Intolerances;
> a Episode (closed): Allergy detail: Penicillin;
> o Allergy (allergy): blistering rash substance: Penicillin; allergene:
> Penicillin;
> o Allergy state: does have allergies (last confirmed 2013-05-06 10:49)
>
> a Episode (open): Goitre, mild, with 2 small simple thyroid cysts;
> s Sore throat improved post-clarithromycin for intercurrent "Strep throat"
> o Asymmetric thyroid slightly larger on the right.
> Feb 21 2013: TSH N, anti-TPO < 28 U/mL
> Apr 18 2013 US dimensions were
> right lobe: 1.7 * 1.5 * 6.7 = 17.1 cm^3
> left lobe: 1.8 * 1.4 * 5.1 = 12.9 cm^3
> simple cysts left lower pole (max 7mm) and right upper (max 5mm)
> a Putative subacute thyroiditis (in December 2012) resolved without
> evidence of anything more than mild goitre and small simple cysts not
> requiring intervention.
> p Inform patient there had been a typo in the original US report where
> the right cyst had been reported in cm not mm.
>
> However the challenges are several …
>
> 1) sort order within the current emr_journal appears to be
> purely datetime stamp,
In fact, the ORDER BY clause affected by the emr_journal
placeholder is
ORDER BY vemrj.clin_when, vemrj.pk_episode, scr, vemrj.src_table
being applied to the query
SELECT
to_char(vemrj.clin_when, 'YYYY-MM-DD') AS date,
vemrj.clin_when,
coalesce(vemrj.soap_cat, '') as soap_cat,
vemrj.narrative,
vemrj.src_table,
(SELECT rank FROM clin.soap_cat_ranks WHERE soap_cat =
vemrj.soap_cat) AS scr,
vemrj.modified_when,
to_char(vemrj.modified_when, 'YYYY-MM-DD HH24:MI') AS
date_modified,
vemrj.modified_by,
vemrj.row_version,
vemrj.pk_episode,
vemrj.pk_encounter,
vemrj.soap_cat as real_soap_cat
FROM clin.v_emr_journal vemrj
Some clin_when will be explicit (say, of a hospital stay)
while others will be set implicitely (but only once, upon
first write of a row, namely to then-now).
> and I am not sure we can predict the sequence in which
> postgres will be writing various rows
PostgreSQL will write the rows in the order we tell it to.
> 2) maybe it is possible within emr_journal for all rows to
> sort by encounter
This would deviate from the concept of journal (of entries,
not of encounters) and seems indicative of a mismatch of the
desired output and the placeholder used.
> and then, within encounter, by health
> issue (if applicable) then by episode
The last two are redundant to each other except for the
fringe case of documenting something into one episode of a
health issue, closing the episode, opening a new episode on
the same health issue and documenting some more into that
new episode.
> 3) can we do anything to make
>
> s
> o
> a
> p
>
> sort and be outputted in that order?
We already do as per the ORDER BY above.
> 4) currently, we are assigning row type "a" to more than
> the traditional "assessment" … we currently also assign
> "a" to the namings of health issues and episodes.
It never occurred to Weed et al that episode and/or issue
descriptions are, by their very nature, of assessment value
as well -- that question probably never presented itself
because writing good headings intrinsically means assessing
what is subsumed (unless writing non-fiction, in which case
this may or may not apply; whereas diehards will assure it
always applies even then - we just sometimes don't get it).
> What would be the involved if we should desire to assign
> such items instead to a different row type, like "A"?
The character in itself is meaningless. The A in SOAP is a
DATATYPE (like integer), as far as GNUmed is concerned. It
could be X or ? or > for all it cares. All it knows is "this
is of type <assessment>". The "SOAPU<NULL>" are simply
(hopefully) mnemonic (and surely historically rooted)
choices.
What other type would one assign to episodes or issues ?
Maybe "U", certainly not <NULL> (as that would neglect their
clinical meaning).
What you are considering is introducing another SOAP-model
datatype. That better be extremely well thought out. M (for
Metadata) ? But we already knew that courtesy of such soAp
arising from clin.episode or clin.health_issue.
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346