[Gnumed-devel] the trouble with sub-episodes/sub-issues/non-episode problems etc - a solution ?

[Karsten Hilbert]

Hi all,

we've been having a problem with structuring narrative come
up on the list recently. It seemed to boil down to this:

People want to be able to structure notes - particularly
within one and the same episode of care. Such structuring
pertains to one and the same health issue.

The problem was that we do not allow more than one open
episode per health issue. Currently it is thought that this
makes sense along the lines that "a patient can only be sick
once for a given disease at any given moment in time".

People argued that, however, there are cases where certain
quite well distinguishable "lines of attribution" can be
found within one sick-episode. There isn't really any
arguing with that as anyone practicing GP level care can
attest to.

During a discussion with our release person Sebastian up
came the following thought:

If people want to structure free text progress notes why not
let them ? And, in fact, not just "allow" but rather
programmatically support doing so ?

I would imagine this like so: During entering a progress
note I feel a need to structure into "poor control" and
"foot care". Hence I press, say, <ALT-L> within the progress
note editor. This enables me to enter a *L*ist of free text
headings I want to structure into. The list is copied
*textually* into the current progress note editor field for
me to add text under it's headings. The list is also kept in
memory for re-use. In other fields of the same progress note
editor I can press <ALT-L> again to edit the list and copy
it into that field. This allows me to add arbitrary
structure to my notes fairly simply. Re-parsing the list in
existing text would simply be based on indentation (a bit
like Python + Wiki) with some hard-n-fast rules:

- list items start in the first column
- item content must not start in the first column
- the list may not contain empty lines
- the list is bounded by empty lines (top/bottom) and/or
  the start/end of the text field

IOW: Break the rules and the list is not recognized.
Re-comply with the rules and the list is recognized again.

*If* the list was kept in the database per progress note it
*could* be re-used across encounters (but needn't be enforced
in any way). This would be one level below the formal
structure yet would allow for the arbitrary structuring
that's apparently needed.

One could then write a frontend that stores all the data
under a dummy episode and/or health issue and just supports
this free list structuring.

Does this make any sense ?

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