[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] External id type attributes, data consistency and val
From: |
Jim Busser |
Subject: |
Re: [Gnumed-devel] External id type attributes, data consistency and validation |
Date: |
Sat, 24 Sep 2011 09:43:22 -0700 |
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
- [Gnumed-devel] External id type attributes, data consistency and validation, Jim Busser, 2011/09/24
- Re: [Gnumed-devel] External id type attributes, data consistency and validation, Karsten Hilbert, 2011/09/24
- Re: [Gnumed-devel] External id type attributes, data consistency and validation,
Jim Busser <=
- Re: [Gnumed-devel] External id type attributes, data consistency and validation, Karsten Hilbert, 2011/09/25
- Re: [Gnumed-devel] External id type attributes, data consistency and validation, Jim Busser, 2011/09/25
- Re: [Gnumed-devel] External id type attributes, data consistency and validation, Karsten Hilbert, 2011/09/25
- Re: [Gnumed-devel] External id type attributes, data consistency and validation, Jim Busser, 2011/09/25
- Re: [Gnumed-devel] External id type attributes, data consistency and validation, Karsten Hilbert, 2011/09/26