On Tue, Jul 04, 2006 at 03:17:13AM -0700, Jim Busser wrote: > >I was thinking that as long oscar was initialized with a high > >enough primary key start number, Down that road peril lies. Attaching meaning to a supposed-to-be-meaningless number.
> >it could coexist with the gnumed demographics, so there's no > >messing around with oscar side > >external id tables or columns for pk_identity. Not sure where this would be needed. If GNUmed piggybacks on OSCAR it better (I think) not make OSCAR remember GNUmed state. I think you might be referring to the case where GNUmed is the "master demographics provider". I would then still do it this way: - have demographics be input into GNUmed - make GNUmed drive OSCAR and auto-add GNUmed demographics into OSCAR tables (may be needed to use billing) - take the OSCAR generated patient ID and attach it to the demographics stored in GNUmed IOW, a little going back and forth. > I am missing something... if you were wanting to drive demographics > from GNUmed then why could GNUmed not write its dem.identity.pk into > the Oscar demographic table? It might be that OSCAR makes certain assumptions about the ID. It shouldn't but perhaps it does. > Or were you taking the view that someone > may have already been running Oscar A reasonable assumption IMO. But perhaps not feasible ? 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
