Voyager SSN to IID
SSN to IID
Concerned about patron privacy, many institutions that previously had used social security numbers (SSN) as identification numbers for students or faculty have recently begun to use institution identification numbers (IID) instead. Many libraries are also abandoning the practice of using sensitive personal data like social security numbers as identifiers in library registration. There are several good discussion threads about making this transition in the Voyager-L listserv archives. Try searching for threads labeled “SSN vs IID from a Policy perspective” and “Removing SSN“. Also you should carefully review and understand the Patron SIF chapter in the Technical User’s Guide. (See also a related article Converting from ID Barcode to Magstripe)
Example of Procedure from Colorado School of Mines
In November 2003 the campus eliminated the use of Social Security Numbers in all databases.
For the Library’s Voyager database, we had to remove all SSN data, which had been used as the unique identifier in our Voyager patron records, and add an IID field, which would become the new unique identifier.
In addition, we had to replace the function within the patron update process of the SSN data as the unique identifier (it was used as the match point for updating records) with the use of our new eight-digit “Campus-Wide ID” (CWID) match point.
1) Change the data
2) Change the way you match update records
To accomplish this our I.S. department created two special patron load files for us to run via the patron update program (Pptrnupdt). The two files are described below.
Of course every step along the way was carefully tested. Initial loads were done on small subsets of records.
1) The first step was to load a patron update file in SIF format that included an IID number. This file as always was matched on and included the SSN (thus using the -i parameter set to “S” in Pptrnupdt). But, the file also included the new patron IID number (on our campus called the ‘CWID’) in the appropriate location in the record (see the Patron SIF in the Voyager Technical User’s Guide — at the writing of this document the IID Field is item #23, offset 239, a string variable 30 characters in length and left-justified). After loading this file we confirmed that the data were visible in the circulation client in the “Insitution ID” field.
2) The second step was to load a second update file that matched using the new IID (thus using the -i parameter set to “I” in Pptrnupdt. This is the way the matching will be done from this time forward). In this file we replaced the data in the SSN Field (at this writing item #24, offset 269, a string variable 11 characters in length and left-justified) with something other than the patron SSN (in our case we chose to use the patron’s 8-digit IID number followed by a 0 (thus it was the requisite nine digits for a SSN; note the field is actually a total 11 characters in length to allow for dashes, but if you don’t use dashes the data are left justified)).
We found that simply blank filling or zero filling the SSN (which is a string variable) caused problems (remember this was in 2003, we were probably running a pre-Unicode version of Voyager). The records loaded but they could not be edited. When an edit was attempted the following error occurred:
“Blocked SSN or Institution ID already assigned to another patron”
Therfore, we assumed SSN, even though no longer used, still needed to be unique. This proved to be the case at the time. As of this writing (05/2006) it appears that this problem has been fixed in more recent versions of Voyager and that you can replace the SSN with blanks (hex 20), but we have not tested this. It is suggested you review posts on Voy-L and the manuals to determine if this issue is still valid and if not how you should treat the SSN data in your records.
Thus, ultimiately, our SIF file record columns 239 to 279 (the IID and SSN fields) for our patron records looked like this (note both are left justified, IID starting in field 239 and SSN starting in field 269):
After loading this second SIF file we again closely scrutinized many records in the circulation client. We confirmed that the matching was done correctly and that the proper data were displayed in the “Instituion ID” and “SSN” fields in the client.
Colorado School of Mines