Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 34

[Karsten Hilbert]

> actually, I'm having a hard time trying to work out how to access the 
> gmclinical tables.
One of the problems may be that one needs to understand the
domain at least partially to see how this is supposed to
work. Have you read the writeup on the EMR structure ?

Another tangent here is that it may help to read the code in
client/business/ for one approach to how to link to the
clinical data backend.

> The views and update triggers in gmIdentityViews are 
> fairly straight forward,
They aren't particularly refined, IMHO, and useful for some
means and not for others. What is in gmclinical* is a bit
further along (conceptually), I think.

> and after trying to do the handler skeletons, I
> realize SQL triggers are probably the clearest way of doing things.
AFAIK, it is considered good practice to access database
columns via functions unless speed issues prevent that.

> But after  I stared at the gmclinical tables for a few hours, trying to
> write my first SQL trigger, I whimpered back to my java IDE toy.
What exactly were you trying to do ? Unfortunately, not even
the best IDE can do away with the need for understanding the
underlying principles and concepts. It can merely help in
making drudgery less, well, boresome.

> What about starting with a dead simple mapping,
Download OSCAR if you want that. Or most of the other MFOSS
apps for that matter. If you don't want any mapping except for
what you make up on the spot in a whim then download the OIO.

> then later normalizing
> it by making the simple tables views with triggers?
What is causing the problems with the schema in gmclinical* ?
I admit it is non-trivial. I'm happy to explain more than I
already did in the writeup. Maybe something's skewed somewhere,
too.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346