Re: [Gnumed-devel] jl-gui - access to log tables

[Busser, Jim]

On 2013-08-23, at 2:01 PM, Karsten Hilbert <address@hidden> wrote:

> On Fri, Aug 23, 2013 at 03:32:43PM +0000, Jim Busser wrote:
> 
>>> Doing so, yes. It is also easy to burn your house. Dealing
>>> with the consequences is not. And no, I am NOT going to
>>> think through the consequences now, as I have said several
>>> times.
>> 
>> Are these consequences technical or clinical?
> 
> I expect technical consequences.

I now have a question …

Let us assume that clin_when was originally declared

                NON NULL

in the belief that it was sane to always require a value to be entered, even 
when the value has dubious reliability or known unreliability of serious 
magnitude.

Let us then agree that at least some parts of GNUmed have been coded in a way 
that may break if clin_when is permitted to be NULL.

The typical case would be a validation trigger, or a calculation, that did not 
make allowances for clin_when to be NULL, for example an interval calculation 
for

        - time elapsed since medication was started
        - time elapsed since a health issue occurred

and so the breakage is prevented by avoiding to allow clin_when to be NULL.

Suppose now that a new custom data type will make it possible to input a date 
"part" of variable precision, for example if I would be prepared to input

        2013-05

for the case when a patient is confident that their previous doctor approved a 
medication (and the patient began to take the medication) in May.

This will still break those parts of GNUmed which depend on a non NULL value 
for clin_when because it remains impossible to calculate the interval when the 
"date part" has been insufficiently specified.

Similarly the same parts of GNUmed will break if it has been allowed to enter a 
NULL as the value for this "custom date part".

In order for the parts of GNUmed that depend on a full date not to break, it 
will be necessary for those parts to avoid to enforce a trigger and to avoid to 
calculate an interval when the value in this custom data column is either NULL 
or cannot be evaluated to a full date.

Which is the same work as would have to be done if clin_when was simply allowed 
to be NULL.

Therefore it does not seem to me that a custom data type will address the 
problem of the GNUmed requirement for clin_when to be a properly evaluable 
date. Perhaps it will be suggested that in the application of triggers and 
calculations,

        1974

will be treated as 1974-01-01 and

        2013-05

will be treated as 2013-05-01 and perhaps a NULL value will be treated as

        dob (if specified)

because the oldest that an event can be would be in the case where it actually 
happened at birth.

Maybe the trigger and calculation will therefore have to evaluate not the value 
stored in clin_when (in case it is not directly evaluable as a date) but to 
instead evaluate the result of a function or transformation that has been 
written to re-express the clin_when as a pseudo-date whose reliability will 
depend on the level to which a value has been inputted into clin_when.

Maybe it is being suggested that if someone goes to the trouble of providing 
the specifications for this kind of solution, this gives enough value to a 
redefining of clin_when to be willing to fix the things that need to be brought 
in line to support it.

-- JIm