Re: [Gnumed-devel] progress note popups (was: question re prog note when entering phx)

[Karsten Hilbert]

On Fri, Apr 22, 2005 at 07:32:39PM -0700, Jim Busser wrote:
> 
> At 6:03 PM +0200 4/22/05, Karsten Hilbert wrote:
> > So off I go typing "phx" into the progress note (in a Soap line).
> >Right after typing the "x" in "phx" up pops the past medical history
> >widget
> 
> Is it already determined workable to have this design

This exact workflow only by myself simulating a real encounter
with real data. Very similar workflow(s) have been discussed
as workable on the list.

>, in which
> (I gather) the program would be able to continuously monitor
> and "trap" any string that matches an item previously defined?
Actually, only the cResizingSTC class traps those keywords.
So, any place we use this class (currently the "new progress
note" widget) will trap the keywords.

> Would these previously-defined items "live" somewhere in the
> backend and, if so, where?
Currently they are hard-configured, eg. the widget class
itself is taking the keywords and actions from a configuration
dictionary but that dictionary is currently hardcoded. The
intent is, however, even for 0.1 to make that configurable
without changing the code.

> Are they envisioned to be "localizable"
Sure, since they are configurable they are localizable any way
you wish. In fact, the very same popup for "phx" is already
bound to "ea:", too, "ea" abbreviating "EigenAnamnese", the
German "Past Medical History" term. The ":" is there to allow
typing "each" without having the popup appear after "ea"
already. Could have used "ea$" or whatever, for that matter.

> and what is it about their
> design that would have them active only within the progress notes
> widget?
Because only the progress note widget looks for them...

> Would it be something about the way that the client is written
> and would it call to some special middleware? Does any of this need
> to be defined and at what stage (post 0.1, 0.11 etc).
It's certainly helpful to find a decent set of keywords
for default installs even for 0.1.

> The part about "replacing the... in the original progress line
> with "..." - is it felt that the replacement is best planned to be
> a literal string of text without any kind of pointer to the
> [past hx item or script item or vaccination item etc] that is
> being referred to?
Yes. The structured data isn't lost though because it's saved
in the EMR from the popup.

> Ian back in November
> http://lists.gnu.org/archive/html/gnumed-devel/2004-11/msg00045.html
> proposed that popup contents be held in RAM (until a record in the 
> backend has been created to hold them). He also suggested that it 
> makes little sense to commit the popups
> before committing the SOAP data.
Well, there IS merit in that approach (namely one can re-edit
those parts) but it's a lot more complex to code.

> But would we not prefer to the 
> committing of what is in the popup before leaving it to continue 
> completion of the progress note?
I do and that's what the current code does.

> If that were the case, a backend 
> record will have been created and the original soap row that is being 
> returned-to could contain a reference to the issue or item (script, 
> family hx, vaccination) that is being referred to.
It could but that would leave us with having to invent some way
to refer from plain text to the items created - which can be of
ANY type of medical data after all. Not something for which I
see a particular clean way of doing.

> Dunno if we aim to 
> have a markup language within the soap rows
Shudder. It's certainly possible though. Also, it's very prone
to later not being able to be used because we (had to) change
the markup language.

> Still on this issue of whether or not to commit the contents of a 
> popup before committing the soap note, is it alternately contended 
> that, in the case of a prescription, you might "draft" a treatment 
> for one health issue but then realize, as you look after a second 
> health issue, that its management will impact the first and require a 
> dose adjustment --- maybe even abandonment --- of the original drug? 
> So maybe you would commit a *past history* item within a popup, but 
> not a prescription, until *all* new drug orders (and drug dosage 
> changes even when no new supply might be required)  can be committed 
> all at once?
Well, as for prescriptions I would do it like this: from any
progress note submit drugs to be prescribed during this
encounter. Those can live in some intermediate storage/table.
When done with the patient - or explicitely when pressing
"print script" be shown the list and ACK it for actually
prescribing. Also the intermediate storage is where a script
for the current encounter would "accumulate" - and can hence
be change any time from a dedicated widget - the need for
which you clearly demonstrated...

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