[Gnumed-devel] restrictions vs. conventions (uncertain date-time)

[Jerzy Luszawski]

On 24-08-2013 05:54 "Busser, Jim" <address@hidden> 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

If you allow me to put my two cents in:

Jim - you elaborated a lot of detailed descriptions of required changes
- it seems to me that you could just implement these changes by yourself :)

But the main thought I would like to share is, that besides hard-coded
requirements required to maintain the sanity of database, you may
develop your own *conventions of use*. For example I use the field
reason_for_encounter to hold the diagnosis before surgical operation,
and assessment_of_encounter to hold the type of operation performed.
Then I can develop screen plugin and printable reports with proper
headings, pulling required data from DB, without redesigning the
database. Somebody else can do different things with the same fields, I
don't care. I simply stick to my *convention* throughout the whole
database.

To the point of date-time data with uncertainty:
I currently do not use medications plugin. But if I had to, I would
probably develop such a "convention":
1. if the date is less than DOB - the date is totally unknown (=DOB is
not a good idea, as it could be exact date)
2. if the date has day or day and month as 01 or Jan-01 respectively,
this part of date is unknown, unless non-zero hours are entered (the
hours part is ignored in any case, but entering non-zero value means
that Jan-01 date is exact)

This is just a proposal, but for me it would be useful. On any reports
which you create (THAT MEANS AT THE CLIENT SIDE, NOT IN THE DATABASE)
you can easily check such conditions and display/print a note "exact
date unknown" when necessary. Duplicating a plugin and adding few lines
of code is much easier than changing so important detail in database,
and is totally independent from other users.

My point is that sometimes it is much easier to adopt a convention (by
you and your co-workers) than to design a program which will satisfy
all present and future needs including all possible exceptions.

-- 
Regards,
Jerzy Luszawski