Re: [Gnumed-devel] Nailing down my discomfort with episode etc

[Karsten Hilbert]

On Mon, Sep 05, 2005 at 07:28:42PM +1000, Richard wrote:

> Looking a bit deeper at this today, its obvious that the emr-journal is 
> actually pretty good, and that it is only a matter of re-organising some of 
> its display and converting it to html to make it easier to understand.
I fully agree.

Let me explain the origin of the EMR Journal:

In German EMR applications the soap display is like this:

date | type | narrative
-----------------------
...
...
-----------------------

Date usually is just the date of when the narrative was
entered. Type is pretty much anything, often SOAP. This does
not in any way take into account encounters, episodes or
anything else.

The reason for the current journal to exist is to give
German doctors a way to look at their data the way they are
used to - chronologically but hardly structured. I have then
at least added in the additional data we already *have*.

I don't even envision this widget to exist in a "final"
version of GNUmed - after all it is a useless duplication of
the functionality to display clinical data.

However, you do point out the strong points of it if
compared to the emr tree display: It allows for viewing the
medical data *by encounter* and not limited by episode.

For this very reason I have been saying previously (perhaps
not on the list ?) that there need to be and will be
improvements to the tree widget. Still this does not mean
anyone has to use it (or help me with it either).

> The 
> only current problem I can see with it is that it does not display separate 
> episodes on the same day  - it meshes them all in together ie all lines of 
> say three consultations on the one day are  grouped with all the Subjective 
> lines/ the object lines/the assessment lines/the plan lines, stacked on top 
> of one-another, rather than three separate SOAPs. Probably a mere detail of 
> re-organisation I suspect in the display.
You are correct. I have slightly adjusted the corresponding
SQL query. It should sort by episode now, too: date,
pk_episode, soap_category.

> I still don't see the point of the EMR dump
It does not belong into 0.1.

> perhaps you can explain it to me, 
The point of the dump is that it allows for displaying data
from any table that inherits from clin_root_item without
having to write any extra code when adding or changing any
of the tables.

It's more of a tool for developers rather than for end
users. That's why it's not in the release.

> and the EMR tree doesn't work on my machine.
How so ?

> I've played with the progress notes module a bit and I think I can now 
> understand why the data input side  doesn't make sense to me, and it is 
> around my workflow and how I would normally record notes (and how Australian 
> GP's organise their notes
Which would be how ?

> At one extreme of a medical records system you would keep only free text and 
Quite similar here in Germany.

> the system would be intelligent to either concurrently or later through 
> queries, organise and present information to you in a slected manner. Eg in 
> this system, finding all the text occurrences of 'headache' would bring up a 
> html file listing all consultations containing that key board etc.
This is how our "search data in EMR" is intended to work
eventually.

> At the other extreme you try and enforce some sort of tagging on all 
> consultations, which is what I think (correct me if I'm wrong) you have been 
> doing with the gnumed clinical records backend.
Yes. However, the frontend is supposed to allow for
"hassle-free" ignoring the structure. Eg. there is nothing
you really have to do to apart from using the fields if all
you care is getting data in. This is currently improving as
I am implementing automatic generation of episode names as
we discussed with Ian.

> There-in lies my difficulty. IE as many many consultations in practice are 
> undifferentiated, and not linked, we  may or may not write a summary or 
> episode name  for them
As it stands consultations must be linked to an episode.
However, generating an episode name is going to be automatic
in most cases very soon.

> you are enforcing the user to 
> write a clinical note which may or may not reflect the content of the 
> episode.
Can you explain this part a bit more ?

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