Re: [Gnumed-devel] Measurements and Documents and associations

[Karsten Hilbert]

On Thu, Jul 02, 2009 at 12:27:40PM -0700, Jim Busser wrote:

> ---> = request for comment
>
> Recently we had conversation about imports (e.g. lab imports) being  

Not being but rather "being probably useful to be". It all
depends on the actual use case to solve.

> their own encounter, even though the event could have happened  
> concurrently with (during) a clinical encounter --- say, an in-praxis  
> visit, on the same patient.


> I am noticing, in Kirk, that measurements appear as part of his in- 
> surgery encounter.
>
> ---> I am wondering if that is just an artifact of how they got  
> originally created

It is. The bootstrapper simply inserts them into the
encounter that exists.

> Except for "in praxis" measurements (blood pressure etc) which would be 
> taken during an encounter, the other ("out of praxis") measurements would 
> be imported.
Well, but if someone manually imports them from, say, a file
on disk they should surely be part of that already-existing
encounter and not some artificial secondary encounter. After
all that is the truth. That same encounter can very well
also contain document imports or whatever else.

> Measurements are able to be associated with an episode, however in the 
> EMR tree they only show up at the level of encounter detail, they do not 
> seem to be abstracted into the EMR tree episode that is in focus
> (despite that the contained documents are abstracted into the statistics).

There might potentially quite a few ...

> ---> might we desire measurements to be handled in like fashion to  
> documents?

I think we do.

> ---> might we want one line per measurement, to give useful info in the 
> way that the documents supplies the useful info of the document type and 
> name?

The test results summary under encounter shows two lines per
result: first the value and unit, then the review status
- should we reduce that to just the first line at the
episode level ?

> ---> the Health Issue summary includes # of episodes and # of  
> encounters; is there any thinking on we want also summarized/listed the 
> documents and measurements (this would be a pooling across what was 
> listed in the individual episodes)...

Done.

> Something weird happens inside the 0.5.rc2 client when (inside the  
> measurements editor) I assign the measurement to an episode that is  
> sitting among unattributed, because when I selected such an episode from 
> the drop-down menu, what is returned into the "Problem" field is
>
>       <name of my selected unattributed episode> /  <name of an episode  
> belonging to a health issue>
>
> or
>
>       <name of my selected unattributed episode> /  <name of health issue>
>
> although the unwanted fragment does not get saved... it is only  
> confusing in the widget.
> ---> is this reproducible by others, and is any log and launchpad report 
> needed?

I cannot reproduce it. Only for episodes belonging to a
health issues does it show the issue description after a
hyphen.

> In the measurement editor, there is only enough room to label one of the 
> fields "Problem" and not to label it (as with the Notelet editors):
>       Problem (episode) name
>
> However in the Attach documents plugin, we presently have
>       Associate to episode:
> ---> can this be made Associate to problem (episode)
>
> since this hints that a new problem (episode) can be created right in  
> this field, if none of the dropdown items match.

In fact, it should be the other way round: This field allows
selection of *episodes* not problems !

Episodes and problems are not the same thing which is why
there is a wiki page explaining the difference:

        
http://salaam.homeunix.com/bin/view/Gnumed/BasicEmrConcept#The_Problem_List

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