[Gnumed-devel] Re: Call for help: relinking an encounter to another episode

[Syan Tan]

On Fri Jun 17  6:07 , Carlos Moro <address@hidden> sent:

>Hello Syan,
>
>Karsten Hilbert wrote:
>
>>If you should need help in traversing the database look at Syans 
>>schemascan.py.
He's good
>>at doing algorithmic things programmatically ...
>>  
>>
>When beginning with 0.1 last todo: 'relinking an encounter to another
>episode'. The problem is: relinking an encounter to another episode
>implies updating the fk_episode of related tables to the id of the
>target one. Your code in schemascan is really impressive so, what do you
>think about working in this task together? I could take care of the GUI
>stuff, would you like to take care of the relinking algorithm? Of course
>I would collaborate and work with you in everything you tell me, but hey
>you're the master!  ;)
>I imagine a lot of the logic in schemascan.py can be reused in any way
>for this kind of problem...
>
>What do you think?
>
>Best regards,
>carlos
>
>
>-- 
>GPG key ID FA50E162 @ random.sks.keyserver.penguin.de
>ECBD 59FE 1A50 630E DF7A  4AF2 E410 83FB FA50 E162
>
>
Can you explain the problem a bit ? Without looking at the schema
it should be just a switch of one pointer , one foreign key value,
but the current schema is doubly linked , right ? 
i.e. for one encounter, their may be multiple episodes of different
health issues. So can't you do something like 

create episode ...

update clin_root_item set fk_episode = currval('pk_episode_seq') 
 where ci.fk_episode in ( 
 select fk_episode
 from clin_root_item ci2 
 where ci2.fk_encounter = x and ci2.fk_episode = y )

x is the source encounter
y is the old episode id of an wrongly linked health issue 
(is that the problem ? trying to switch health issue
of a group of clin_root_items )
  
this would switch the fk_episode to the newly created episode
on another health issue.

schemascan was originally trying to get a mapping of the current
schema for a automatic UI ( which was too complicated to do, due
to having to add automatic validating as well, and not being able
to construct a good looking ui this way )

It then was also for fetching all the data pertaining to one
record, and used in Karsten's idea, which was to make 
this data exportable as sql statements, the main hitch to solve
being relinking the data with new ids in another schema instance.
My personal "need"/itch to do this ( as per the "Bazaar" theory of programmer
behaviour),  was that if I was to use gnumed to enter "road warrior" nursing
home visit entries, I'd like to be able to import it back to 
the main set of records on returning to the practice.
  The other way to do this, was to have the nursing home's have web access,
and enter it via gnumed's web interface ( which formerly existed briefly ,
before entropy killed it).
 Life is a big joke, aint it?