gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Re: Schema question re labs


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Re: Schema question re labs
Date: Fri, 08 Feb 2008 10:42:12 +0100

> >> A candidate reference number that may be good to send would be the pk
> >> which is automatically generated in the table ... any reason it would
> >> be any bad idea to use this?
> > Absolutely. The PK is a) an implementation detail which shouldn't  
> > leave
> > the innards of even the local client, b) is illegal to use outside  
> > the praxis in some jurisdictions, c) is not intended to carry business
> > meaning, d) is not guaranteed to not change during lab request/results
> > retrieval (though this is unlikely and best avoided).
> 
> In Germany, there is no default value for request_id which must be  
> scanned in from the label or manually entered. Are you using GNUmed  
> presently to record lab_requests
No we don't. Remember this is the first time we'll have working lab
handling in GNUmed.

> In Canada and other places where the request_id could be free to be  
> decided by the requesting praxis, there is presently no mechanism to  
> be able to manage what should go in here.
It needs to be added or rather, on the appropriate Wiki page, that's
what I meant by "reuse demographics widget to enter lab request ID".
I would suggest defining an external ID type for that purpose which
is then taught to the importer to use.

> One option would be to  
> autocopy (pk + a constant) into the request_id which should get  
> around the legal issue if it would have applied.
A constant isn't really a good technical protection (although likely
it would fulfill legalities) as I could just go to the practice obtain
my own PK, have blood taken and obtain my request ID thereby learning
the constant. A classical known-plaintext attack :^)

> Something like that  
> would best be applied as a trigger but I don't imagine triggers are  
> easily configurable as a site preference so how best to implement a  
> counter or serial function for some installations of GNUmed but not  
> others?
Well, the request ID is an arbitrary business entity opaque to the
persistence mechanism. Thus it would be generated in the business
layer, IOW the requests manager logic or right in the importer. At that
level it would be made configurable just like any other options we
have in GNUmed.

Karsten

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer




reply via email to

[Prev in Thread] Current Thread [Next in Thread]