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, Sounds reasonable. > 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 Yes. > 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. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
