|Subject:||Re: [Gnumed-devel] demographics gnumed to oscar|
|Date:||Tue, 04 Jul 2006 19:59:36 +0800|
On Tue, Jul 04, 2006 at 07:18:56PM +0800, Syan Tan wrote:
> it's a little bit fussy; so the search list produces demographic_numbers that
> are actually gnumed pk_identity numbers.
Who is searching against what ?
GNUmed against the gnumed schema ?
OSCAR against the gnumed schema ?
OSCAR against the oscar schema ?
We need to know exactly what we are talking about.
I'll assume the first case for now.
> When the user selects the demographic by clicking the number,
> the idea is to see if an oscar number doesn't exist for that pk_identity
> in an lnk_2external_id entry in gnumed.
> If it doesn't exist, then an insert is made into the oscar
> demographic key without a provider_number,
> and hopefully there is a mysql sequencer that will generate the
> oscar number. the last generated oscar number then needs to be retrieved,
> and inserted into the gnumed lnk_2_external_id as the oscar number against the
> pk_identity number
> which is the old demographic_no.
> Then the demographic_no is swapped with the
> oscar_number and display processing continues.
I don't understand the last part. This swapping is needed
because OSCAR of course needs to continue processing with
the number it knows and not the number GNUmed knows, right ?
> later , when linking to to the encounter button is done, the demographic number
> looks up the
> lnk_2external_id for oscar number types, for the gnumed pk_identity, and this
> is used by xmlrpc to activate that identity.
Ah, yeah, need to go backwards then, from the oscar number
via lnk_ext_id2identity to the gnumed pk.
> Is that the agreed method ?
Sounds reasonable to me.
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Gnumed-devel mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|