Re: [Gnumed-devel] Refactoring emr_journal progress note output

[Karsten Hilbert]

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