Re: [Gnumed-devel] may help

[catmat]

Karsten Hilbert wrote:

> > Karsten's  schema allows an encounter to be a container for an unordered 
> > list of clinical root items.  The clinical entry
> > is done by selecting  a health issue ( or default health issue),   
> >    
> Or no health issue at all which would amount to an unlinked
> episode. Which we now allow to account for minor non-recurring
> afflictions such as "minor cold" more conveniently.
>
>  
unfortunately, some of us need this quite a lot   :(

> > Once a new issue is started, no more clinical items can
> > be attached to the previous health issue.
> >    
> That strikes me as odd. It's certainly not intended that way.
> Health issues are (logically) independant of each other as
> regards entry of data.
>
>  
yes, it's not a backend problem : the web client does not create objects 
as needed on the backend,
but gets like an empty tree of objects that maps to repeating form 
complex elements,
and then passes it back  for processing, where empty or unused objects 
are discarded.
I had organised the blank tree to be  an encounter, with various 
clin_root_items attached ( narrative, vacc, medication),
with each of those having blank episode and health issue objects ; the 
processing just went through the list of clin_root_items,
which are instances of an entry sub-class,  and checked for the link or 
new issue boolean flags ; if it is a link, then the clin_root_item
changed it's episode reference to the previous clin_root_item's episode 
object.   Yes,  very  hacky  and  narrow usage and I know it.

it would have been better to have pass multiple episode objects, with 
blank health issue, and then the lists of each
type of clin_root_item. Then this allows adding on to the end of the 
clin_root_item lists  per episode entry  ,  changing from
one episode to another and back again at anytime.

 On the plus side, it's a matter of re-writing the ui to client 
organisation, but the schema remains the same,
and it does show that the schema can map to  flexible graphs to suit 
situations ( e.g  a web client trying to minimize communications
to a server).

> > In practice, this is a disadvantage, because one could forget to attach 
> > a P clinical item, and be unable to add medications
> > under a previous health issue.
> >    
> Precisely. The disadvantage does not exist in the backend.
>
>  

> > re-prescribing old  medications  has not been done;
> > the traditional way is just to have checkboxes or other select mechanism 
> > against the current medication list,  but
> > this would not link to episode/health issues in the encounter.
> >    
> It sure could, why not ?
>
>  
Or maybe it (the web client) can; if the ui manages to display from a 
old clin_medication object, then that object
should have a reference to  it's original episode and health issue. 
Struts stores state of form objects ( it has to, for re-edit of forms).

Maybe not, I remember I did a shortcut  to load unlinked historical 
root items such as medication using
QuickAndDirtySummary  sql statements. Just need to change the sql 
statements to include owning health issue info maybe,
or to dump the quickAndDirty and write it properly.

Again, not a backend problem.

> Karsten
>