Funny (not ha, ha) how this DOPA business and all the news about the stolen laptop that held all this VA data, makes us (me) face some of our technical limitations, some of our past decisions, some of our core values and some of our new endeavors...
Interesting how we can be expected to apply all kind of regulations on as varied a population as we serve.
It's clear for us that we do not have enough data to ever dream of implementing AGE based policies. Our ILS does not currently have a useable BIRTHDATE field. It has had a BIRTHYEAR field forever but it never even was either required or verified so we have some users with no entry there, some with 2 digit entries there and some with 4 digit entries. Of course, the full, useable BIRTHDATE field will be available to us very soon, but to have the field does not solve the problem, you need to POPULATE this field with accurate data before you can use it....
I LIKE THIS QUOTE:
"The technical infrastructure that makes something possible is only the first step of a long process to make something usable." from Roy Tennant, TechEssence.info
...
Now, if we decide (are made) to gather birthdate info, we will have and hold 2 of the 3 essential parts required for ID theft.
I was thinking maybe we can devise a sensible workaround and gather month and year in separate (verified) fields, without having to know or keep the DAY part. Of course this would require substantial manipulation of the db on a regular basis, but that part can be automated...
Why not seek YEAR XXXX+ MONTH XX and use this to populate a separate Majority: Y/N field? That Majority field can be used to "enforce" certain policies and/or laws.
That way, should (--warding evil eye sign--) our data get compromized, we have exposed our users to much less risk than if we had had a full birhtdate in our records...
Hummmm...
More to come on this.
technorati tags:library2.0,library 2.0, libraries, policies, customers
No comments:
Post a Comment