Re: [Gnumed-devel] External id type attributes, data consistency and validation

[Jim Busser]

On 2011-09-24, at 4:55 AM, Karsten Hilbert wrote:

>       Be strict in what you emit. Be liberal in what you accept.
> 
> Particularly the latter.
> 
>> - do we provide 4 additional columns
>> 
>>      .force_upper boolean default null
>>      .remove_all_spaces boolean default null
>>      .zero_fill_to_length default null
>>      .modulus numeric default null
> 
> The database is most definitely the wrong place to enforce
> such things.

I don't (fully) accept this.

I mean… I accept the principle, but only to the extent that it makes sense to 
be liberal.

Other EMRs accept in what they call a "date of birth" field the value 00 00 
0000. Why not allow, for gender / sex

        m
        M
        male
        Male
        Man

One reason, I know, is because we can have general agreement, across praxes, 
that certain fields (columns) should be constrained in what it will accept.

Other columns cannot be enforced across praxes, particularly when (for example) 
the quantity in Postal / Zip requires, in the US, 5 digits (with or without 
'plus four') and the Canadian postal 6 characters of the form ANA NAN. So maybe 
this was a bad example *

But where an external code is locally defined, I see nothing wrong with 
assisting a praxis to make a choice of whether or not to trigger improvements 
that assist local consistency. I see nothing wrong with allowing my praxis to 
determine that for the identifier type

        PHN Personal Health Number (issued by BC_CA.MSP)

it needs to be 10 digits, beginning with a 9. I see nothing wrong in principle 
with allowing a locally definable data value

        MRN Medical Record Number (issued by BC_CA.VCHA)

when it was entered as 12345 to be auto-assisted to be 00012345 *if and only 
if* a praxis has determined that this is reasonable.

I can totally understand whether you do not see sufficient value in it to be 
interest to code the change. However this is orthogonal to whether there is 
anything flawed in the proposal, justifying to deny its support.

Having said that re postal / zip codes, there is really no reason we could not 
define a trigger to be able to look up whether, for any given 
country-of-address, a matching constraint exists in a table and, only if that 
is the case, to apply it.     Constraints could even ignore whitespace on input 
and normalise the data to a canonical format for storage. That way, people can 
enter postal codes with or without spaces, and it won't matter. We could format 
them for output purposes, if needed.

I could even start to develop some lists of expressions.

-- Jim