PASI Overall supports the management of Student information within Alberta Education and is considered the source of truth for Student information within Alberta Education. The Student information is managed via PASI, and is shared with other downstream applications as necessary.

SHR (Stakeholder Registry) is used within Advanced Education (AE) as a place to store information about people and is divided into a number of Privacy Domains. Privacy Domain 10 is used to store information about students. The Ministry Client is tasked with ensuring that the student information within PASI, is ‘in-sync’ with the student information contained within SHR.

As PASI is the ‘source-of-truth’ for student information within the education system, the synchronization processes performed by the Ministry Client primarily ensures that the SHR data is kept in sync with changes made in PASI (and not the other way around).

Only students with a Synchronization Status of Enabled or On are exposed by PASI to the Ministry Client for syncrhonization because the Ministry Client has been assigned the High School Student Sync User role¹⁾. As the ASNs the Ministry Client can access are limited, the Minsitry Client will treat ASNs in PASI that it cannot access as 'Not in PASI'.

The following diagram provides a high level overview of the Ministry Client synchronization processes:

When an ASN is created in the PASI Core, the information is loaded from the PASI Core and subsequently written into SHR.

When an ASN is updated in PASI, the data is loaded from the PASI Core and from SHR. The data is compared and any differences are resolved by updating SHR to match the data in PASI.

When an ASN is created in SHR, the information is loaded from SHR into Ministry Client however, the ASN is not automatically written to PASI Core. To have the ASN added to PASI Core, the PASIprep Import ASN function must be used.

When an ASN is updated in SHR, the data is loaded from the PASI Core and from SHR. The data is compared and any differences are resolved by updating SHR to match the data in PASI.

The updates applied to SHR can be considered a ‘reversing transaction’ as the state of the data in SHR returns to an ‘in-sync’ state with PASI and the update made in SHR is ‘lost’. For example,

1. A student’s name in SHR and PASI is ‘John Smith’. At this point in time the information is ‘in-sync’.
2. The name is updated in SHR (not in PASI) to ‘Jonathan Smith’. At this point in time the information is ‘out-of-sync’.
3. The Ministry Client detects the update and compares the data to the data in PASI. As the data is different, the Ministry Client updates the name in SHR to ‘John Smith’, returning the data to an ‘in-sync’ state.

In this scenario, SHR would have the following records:

• A record for John Smith (corresponding to step 1) that has been ended.
• A record for Jonathan Smith (corresponding to step 2) that has been ended.
• A record for John Smith (corresponding to Step 3) that has an end date of 2999-12-31.

Note: Specific checks have been put into Ministry Client to determine “ownership” for a Student record. When PASI “owns” the Student record, Ministry Client will update the SHR Student record to bring it back in sync with PASI’s Student record. When SHR “owns” the Student record, the Ministry Client will not update SHR leaving the PASI and SHR Student records out-of-sync.

When Ministry Client processes a record, it tracks the results of that process in a Student Synchronization log. This log is part of the PASIMC database.

• The Alberta Student Number of the student that was processed.
• The SHR Domain 10 PID of the student that was processed.
• Information about the ‘instance’ of Ministry Client that did the comparison including the server name, the process ID of the Ministry Client on the server, and the time when Ministry Client started up.
• The results of the comparison by Ministry Client. See the table below for more information
• When the comparison was performed by the Ministry Client.
• When the student was last updated in PASI, in SHR, and by a PSI in SHR
• The PASI and SHR version number used to perform the comparison.
• If PASI was updated, the updated PASI version number after the update.
• If SHR was updated, the updated SHR version number after the update.
• In the event of an error when performing a create or update, error information.
• Information outlining what information was different for more information²⁾:
  • Legal Name was different
  • AKA Name was different
  • Current Address was different
  • Permanent Address was different
  • Home Telephone was different
  • Retired Status was different
  • Birth Date was different
  • Gender was different
  • Citizenship was different

Every time the student is processed, the synchronization information is updated. As a result, this information only contains information about the last time the student was synchronized by the Ministry Client.

The result of the comparison can be one of the following values:

As the Ministry Client can be configured to execute all the different types of synchronizations, the following comparison results may also be seen:

For technical reasons, the processing of a student may not occur as expected. In this case, one of the following comparison results may be seen:

The remainder of this page outlines the rules used by the Ministry Client for the processes. These processes are divided into 3 main topics:

• The rules used to load data from SHR and PASI into the Ministry Client
• The rules used to compare the PASI and SHR data within the Ministry Client
• The rules used to update SHR and PASI will the data contained within the Ministry Client

Collectively, these rules are used to define the 4 flows of information between the components described above.

The various sets of transformation and cleansing rules to be applied when loading data into Ministry Client from PASI and SHR are outlined below.

Once data is loaded into Ministry Client, the data structure resembles the following diagram:

For students that exist in both SHR and PASI, the Ministry Client will have two Student records with this structure, one containing SHR data, and another containing PASI data.

When SHR Data is loaded into Ministry Client, a series of SQL queries are used to load each table in SHR into Ministry Client. The structure of the data in SHR resembles the following diagram:

Only individuals meeting the following criteria are loaded into the Ministry Client:

• A PID Role record with a codetype_id value of Learner (code 2201), and
• A PID Role Privacy Domain record with a privacydomain_id value of 10

The data loaded is based on the PID Role record and the current PID Role Status and the current Retired PID Role record.

• The current PID Role Status record is defined as most recently updated record (based on lst_mod_dt) with an eff_end_dt of the End of Time.
• The current Retired PID Role record is defined as the most recent record (based on eff_start_dt) with:
  • a pidrole_source_id that is the same as the pidrole_id on the PID Role record, or
  • a pidrole_source_id that is null, and a pidrole_target_id that is the same as the pidrole_id on the PID Role record.

This attribute is loaded with the value of pub_id from the PID Role record.

A value of Primary is loaded when:

• The current PID Role Status record has a Type of Active.

A value of Secondary is loaded when:

• The current PID Role Status record has a Type of Retired,
• The current Retired PID Role record has a Status of Retired,
• The current Retired PID Role record has a target PID Role record identified (i.e. pidrole_target_id is not null).

A value of Deactivated is loaded when:

• The current PID Role Status record has a Type of Retired,
• The current Retired PID Role record does not meet the criteria (above) to classify as a Secondary ASN

When the ASN Status is:

• Primary, this value is loaded with the value of pub_id from the PID Role record.
• Secondary, the value is loaded with the value of pub_id from the target PID Role record.
• Deactivated, this value is loaded with a null value.

This attribute is loaded with the value of gender_cd from the PID record.

This attribute is loaded with the value of birth_dt from the PID record.

This attribute is loaded with the value of death_dt from the PID record.

This attribute is loaded based on the current PID Status record. The most recently updated record (based on lst_mod_dt) with an eff_end_dt of the End of Time is used.

• If the value of codetype_id is Active (code value 2001) then Is Deceased is populated as False.
• If the value of codetype_id is Deceased (code value 2003) then Is Deceased is populated as True.

Only the most recently updated Citizenship record (based on lst_mod_dt) with an eff_end_dt of the End of Time is used.

This attribute is loaded with the value of codetype_id from the Citizenship record.

When Citizenship Type is Temporary Resident on a Student Permit (code value 2605), this attribute is loaded with the value of auth_end_dt from the Citizenship record. Otherwise this attribute is not loaded.

The Legal Name is loaded based on most recently updated Name record (based on lst_mod_dt) with:

• codetype_id of Legal Name (code 1301)
• eff_end_dt equal to the End of Time

This field is populated based on the value of the given_nm attribute from the Name record. If the student does not have a given_nm, then the student’s middle name is used. If the student does not have a given_nm or a middle_nm, then surnm is used. If the student does not have any name, the student is not created in PASI and the issue is logged.

The value is modified to align with the PASI standards by:

• Removing non-valid characters. Valid characters include:
  • a-z and A-Z
  • áàäãâåéèëêíìïîóòöõôúùüûýÿñç and ÁÀÄÃÂÅÉÈËÊÍÌÏÎÓÒÖÕÔÚÙÜÛÝÑÇ
  • periods, hyphens, and apostrophes

• If a period is not followed by a space or a hyphen, a space is added after the period.
• Removing spaces beside any hyphens
• Removing leading/trailing spaces
• Replacing multiple spaces with a single space

This field is populated with a modified version of the middle_nm attribute from the Name record. The value is modified to align with the PASI Standards using the same rules as the First Name field.

If the middle_nm was used as the First Name (see above) then no value is provided.

This field is populated with a modified version of the surnm attribute from the Name record. The value is modified to align with the PASI Standards using the same rules as the First Name field.

If the surnm was used as the First Name (see above), or the student does not have a surnm then LNU is used.

This field is populated with a value of True if the First Name, Middle Name, and Last Name were loaded without modification. If any of the name components where modified, this field is populated with a value of False.

The AKA Name is loaded based on most recently updated Name record (based on lst_mod_dt) with:

• codetype_id of AKA Name (code 1302)
• eff_end_dt equal to the End of Time

The data loaded into Ministry Client uses the same rules used as for Legal Name. If there is no AKA Name in SHR then load the AKA Name into the Ministry Client based on the Legal Name.

• The AKA First Name should be populated with the Legal First Name
• The AKA Middle Name should not be populated (i.e. is an empty string)
• The AKA Last Name should be populated with the Legal Last Name
• The AKA Is Name Exact is populated with the Legal Is Name Exact

A Current Mailing Address is loaded using the most recently updated Address record (based on lst_mod_dt) with:

• an codetype_id of Current (code 1701).
• an eff_end_dt of the End of Time
• a Contact record with a codetype_id of Home (code 1401)

If no Address records exist matching this criteria, a Current Mailing Address is not loaded into the Ministry Client.

This attribute is loaded with the value of the first line of address information from the Address record. If address_1_txt is populated, it is used to populate this attribute. If address_1_txt is not populated, then if populated address_2_txt is used (and so on). Therefore, this attribute may be populated with information from address_1_txt, address_2_txt, address_3_txt, or address_4_txt. This ensures that the address data loaded into the Ministry Client is ‘top filled’ (i.e. that blank lines will only appear after all populated lines).

The address line loaded is modified to align with PASI standards by:

• Remove #, °, n°, and/or N° if present.
• Removing leading and trailing spaces.
• Replacing any multiple spaces with a single space.

This attribute is loaded with the value of the second line of address information (from address_2_txt, address_3_txt, or address_4_txt) the Address record to ensure that the address data is ‘top filled’ and modified in the same fashion as Address Line 1.

This attribute is loaded with the value of the third line of address information from the Address record (from address_3_txt or address_4_txt) to ensure that the address data is ‘top filled’ and modified in the same fashion as Address Line 1.

This attribute is loaded with the value of the fourth line of address information (from address_4_txt) from the Address record to ensure that the address data is ‘top filled’ and modified in the same fashion as Address Line 1.

This attribute is loaded with the value of city_nm from the Address record and modified in the same fashion as Address Line 1.

This attribute is loaded with the value of province_cd from the Address record and is modified in the same fashion as Address Line 1.

This attribute is loaded based on the value of country_cd from the Address record. The value of country_cd is used to map to the full country name as per the mapping table in Appendix A. If the value of country_cd cannot be mapped, Country is populated with a value of Unknown.

This attribute is loaded with the value of postal_cd from the Address record and is modified in the same fashion as Address Line 1.

If the Country is Canada (code 124):

• The postal code is converted to all upper-case
• A space is added (if not present) between the 3rd and 4th characters of a postal code if the postal code matches the format “LNLNLN”
• The postal code is truncated to 7 characters

If the Country is the United States (code 840):

• A hyphen is added (if not present) between the 5th and 6th characters of a postal code if the postal code matches the format “#########”
• The postal code is truncated to 10 characters

This attribute is loaded with the value of eff_start_dt from the Address record.

The Permanent Mailing Address is loaded with the most recently updated Address record (based on lst_mod_dt) with:

• an codetype_id of Permanent (code 1702).
• an eff_end_dt of the End of Time
• a Contact record with a codetype_id of Home (code 1401)

If no Address records exist matching this criteria, a Permanent Mailing Address is not loaded into the Ministry Client. This record will be created by using the same rules as used for the Current Mailing Address.

The Telephone is loaded with the most recently updated Telephone record (based on lst_mod_dt) with:

• a codetype_id of Phone (code 1601).
• a eff_end_dt that is the End of Time
• a Contact record with a codetype_id of Home (code 1401).

If no Telephone records exist matching this criteria, a Telephone record is not loaded into the Ministry Client.

This field is populated based on the telephone_intl_no, telephone_area_no, and telephone_no. The value provided by this field is dependent on whether or not the telephone number is considered an North American Numbering Plan (NANP) phone number. A NANP phone number is identified as a telephone record where:

• telephone_intl_no is null or 1
• telephone_area_no is 3 digits long and does not start with a 0 or 1
• telephone_no is 7 digits long and does not start with a 0 or 1

When the telephone number is a NANP telephone number, then this field is populated with the concatenation of telephone_area_no and telephone_no.

When the telephone number is not a NANP telephone number, then this field is populated with the concatenation of:

• +
• telephone_intl_no without any leading 0 or 1
• telephone_area_no without any leading 0 or 1
• telephone_no without any leading 0 or 1

This attribute is loaded with the value of telephone_extn_no from the Telephone record as-is.

This attribute is loaded with the value of eff_start_dt from the Telephone record.

As of R6.01, Protection/Disclosure Restrictions information is no longer synchronized with SHR.

The Provider Relationship table is populated with the value of eff_start_dt from the ProviderRel record with the greatest eff_start_dt meeting the following criteria:

• codetype_id indicates the record is for a Student (3001), and
• grade_id indicates that the record is for a grade of Post Secondary (3902) or Apprenticeship (3903)

To load PASI Core Data into the Ministry Client, the Ministry Client makes a call PASI Core's Is Data Available service. This service returns a list of students that the Ministry Client should synchronize with SHR.

For each student returned in the list, the Ministry Client calls the Get Student (2019 Endpoint) service to load the PASI Core data into the Ministry Client.

ASN Status is populated based on the ASN information returned in the base Student Information entity.

The Alberta Student Number is populated with the value of the State Province ID attribute.

The data loaded is based on the value Primary State Province ID and the value of Is Deactivated, returned on the base Student record.

• A value of Primary is loaded when the value of Primary State Province ID is null and the value of Is Deactivated is False.
• A value of Deactivated is loaded when the value of Is Deactivated is True.
• A value of Secondary is loaded when the value of Primary State Province ID is not null.

Primary ASN is populated based on the Status of the ASN.

• When the status is Primary, this field is loaded with the value of State Province ID.
• When the status is Secondary , this field is loaded with the value of Primary State Province ID.
• When the status is Deactivated, this field is loaded with a null value.

This attribute is loaded with the value of Gender from the Base Student Entity.

This attribute is loaded with the value of Birth Date from the Identification Record.

This attribute is loaded with the value of Date Of Death from the base Student record.

This attribute is loaded with the value of Is Deceased from the base Student record.

The Citizenship information is loaded based on the most recent Citizenship Status Info record returned by the PASI Core.

This attribute is populated based on the value of Citizenship Status on the Citizenship Status Info record. The corresponding SHR Code is used after mapping the PASI Core to the SHR Code using the following code mapping:

When Citizenship Status = Temporary Resident on a Student Permit (PASI Code 5), this attribute is populated with the value of Study Permit Expiry Date from the Citizenship Status Info record. Otherwise this attribute is not loaded.

The Legal Name will be loaded based on the information in the Name Entity. Note:It is the Name record with a RefId that matches the RefId returned in the Student Identification Information entity.

This attribute will be populated based on the first 35 characters of the First Name field on the Name Entity.

This attribute will be populated based on the first 35 characters of the Middle Name field on the Name Entity..

This attribute will be populated based on the Last Name and Suffix field on the Name Entity. The Last Name and Suffix (if populated) are concatenated (separated by a space) and the result is truncated to 35 characters.

This attribute will be populated with the value of the Is Name Exact field on the Name Entity.

The AKA Name will be provided based on the Preferred Name provided by PASI. If the Preferred Name is the same name as the Legal Name (i.e. Preferred Name Ref ID is the same as the Ref ID in Student Identification Information) then the AKA Name is loaded using the same rules used for Legal Name, except that the Middle Name is not populated (i.e. is an empty string).

The Current Mailing Address will be loaded based on the country of the student’s Preferred Mailing Address. If the country of the student's Preferred Mailing Address is 'Canada' or 'United States', then this address should be loaded as the Current Mailing Address. If the country associated to the Preferred Mailing Address is anything else (or PASI does not have a Preferred Mailing Address) then a Current Mailing Address record is not loaded into the Ministry Client.

This attribute will be populated based on the value of the Street field of the selected address record. The value loaded will consist of the text up to (but not including) the first carriage return and line feed (or the end of the field if a carriage return and line feed does not exist). This extracted text will be truncated to 35 characters.

This attribute will be populated based on the value of the Street field of the selected address record. The value loaded will consist of the text starting after the first carriage return and line feed, up to (but not including) the second carriage return and line feed (or the end of the field if a second carriage return and line feed does not exist). This extracted text will be truncated to 35 characters.

If the PreferredMailingAddress.Street does contain at least one carriage return and line feed, then no value is loaded for this attribute.

This attribute will be populated based on the value of the Street field of the selected address record. The value loaded will consist of the text starting after the second carriage return and line feed, up to (but not including) the third carriage return and line feed (or the end of the field if a third carriage return and line feed does not exist). This extracted text will be truncated to 35 characters.

If the PreferredMailingAddress.Street does contain at least two carriage return and line feeds, then no value is loaded for this attribute.

This attribute will be populated based on the value of the Street field of the selected address record. The value loaded will consist of the text starting after the third carriage return and line feed, up to (but not including) the forth carriage return and line feed (or the end of the field if a third carriage return and line feed does not exist). This extracted text will be truncated to 35 characters.

If the PreferredMailingAddress.Street does contain at least 3 carriage return and line feeds, then no value is loaded for this attribute.

This attribute will be populated based on the value of City of the selected address record and truncated to 35 characters.

This attribute will be populated based on the value of the State Province field of the selected address record and truncated to 3 characters.

This attribute will be populated based on the value of the Country field of the selected address record.

This attribute will be populated based on the value of the Postal Code field of the selected address record.

This attribute will be populated based on the value of the Effective Date field of the selected address record.

The Permanent Mailing Address will be loaded based on the country of the student’s Preferred Mailing Address. If the country of the student's Preferred Mailing Address is not 'Canada' or the 'United States', then this address should be loaded as the Permanent Mailing Address.

If the country on the Preferred Mailing Address is 'Canada' or 'United States' then the Ministry Client will use an address returned in the list of Other Addresses (if any) to populate the Permanent Mailing Address. The Other Address with the greatest Effective Date and without an Expiry Date is used as the Permanent Mailing Address.

This data will be loaded by using the same rules as for the Current Mailing Address.

The Telephone number will be loaded based on the following criteria:

• A Phone Type of ‘Home’
• An expiry date in the future (or without an expiry date)
• The most recent Effective Date

In the event that more than one phone number has the same Effective Date, the one with the most recent version should be used.

The Phone Number is loaded with the value of Number from the Home Phone Number record, as-is.

The Extension is loaded with the value of Extension from the Home Phone Number record, as-is.

This attribute will be populated based on the value of the Effective Date field on the Home Phone Number record.

As of R6.01, Protection/Disclosure Restrictions information is no longer synchronized with SHR.

This attribute is not populated when loaded information from PASI.

There are 3 sets of rules used based on whether or not the student record is in SHR and/or PASI.

The state is identified by the Ministry Client when an ASN that has been loaded from SHR and a corresponding ASN has not been loaded from PASI.

In this situation, the Ministry Client will ignore the ASN.

The state is identified by the Ministry Client when an ASN that has been loaded from PASI and a corresponding ASN has not been loaded from SHR.

In this situation, the Ministry Client will check and confirm that the ASN belongs to the set of ASNs that PASI is authorized to create (known as the PASI ASN Pool). If the ASN is considered a PASI ASN, the Ministry Client creates a new Student record in SHR, using the information loaded from PASI (including ASN Status).

If the ASN is not with the PASI ASN Pool, the record is not created in SHR and is logged.

This state is identified by the Ministry Client when the same ASN has been loaded from both PASI and SHR. Whenever data is updated in PASI or SHR, the Ministry Client does a comparison of the data and if necessary, the appropriate data is updated in SHR. This comparison occurs based on the individual record types within SHR (not as a whole student). If an individual record type is not in-sync, that specific record is updated in SHR to match the data in PASI.

Unless otherwise stated, the general flow of this process is:

1. Identify that an update has occurred in PASI or in SHR.
2. Load the current data from PASI and SHR into the Ministry Client.
3. Compare and synchronize the ASN Status of the record loaded into the Ministry Client from PASI and SHR (see ASN Status below).
4. If the ASN Status of the record in PASI is not ‘Primary’, then no further information is synchronized.
5. If student is considered a ‘Post Secondary Student’ (see Post Secondary Students below) then no further information is synchronized.
6. Compare and synchronize the remaining data loaded into the Ministry Client from PASI and SHR data for each record type.
7. If the data for the specific record type is not the same:
   1. End the current record within SHR, and
   2. Create a new record in SHR based on the data loaded from PASI data.

When performing comparisons, all text comparisons are case sensitive and accent insensitive. In other words:

• McDuff is not considered the same as Mcduff
• Fernández is considered the same as Fernandez

The ASN Status information loaded into Ministry Client from SHR and PASI are compared.

If the ASN Status from PASI is Primary then:

• If the ASN Status from SHR is Primary then no changes are applied.
• If the ASN Status from SHR is Secondary or Deactivated then new PID Role Status and Retired PID Role records are created in SHR to match PASI.

If the ASN Status from PASI is Secondary then:

• If the ASN Status from SHR is Primary then new PID Role Status and Retired PID Role records are created in SHR to match PASI.
• If the ASN Status from SHR is Secondary then the Primary ASNs are compared. If the Primary ASNs are the same, then no changes are applied. If the Primary ASNs are different, then a new Retired PID Role record is created in SHR to match PASI.
• If the ASN Status from SHR is Deactivated then a new Retired PID Role record is created in SHR to match PASI.

If the ASN Status from PASI is Deactivated then:

• If the ASN Status from SHR is Primary then new PID Role Status and Retired PID Role records are created in SHR to match PASI.
• If the ASN Status from SHR is Secondary then a new Retired PID Role record is created in SHR to match PASI.
• If the ASN Status from SHR is Deactivated then no changes are applied.

See PID Role Status below for information about updating the PID Role Status record, and Retired PID Role below for information about updating the Retired PID Role record.

As of R6.01, Protection/Disclosure Restrictions information is no longer synchronized with SHR.

The most recent Provider Relationship record (based on the Effective Start Date) matching the following criteria is loaded from SHR:

• Provider Relationship Type of Student (code value 3001)
• Grade Type of Post-Secondary (code value 3902) or Apprenticeship (code value 3903)

To determine if the record has been modified by a PSI, the Provider Relationship Effective Start Date is compared against the PASI Created On and Last Updated On date using the following rules:

• If the student has never been updated in PASI (i.e. the Last Updated On is the same as the Created On) and the student has a Provider Relationship record, then the student is considered a Post-Secondary student. In this scenario, the Effective Start Date of the Provider Relationship record is irrelevant.
• If the student has been updated in PASI (i.e. the Last Updated On is greater than the Created On) and the Effective Start Date is after the Last Updated On date, then the student is considered a Post-Secondary student.
• In all other scenarios, the student is considered a K-12 student. This includes:
  • The student does not have a Provider Relationship record.
  • The student was last updated in PASI (i.e. the Last Updated On date is greater than the Provider Relationship Effective Start Date).

When the student is considered a Post Secondary Student, PASI will ignore all differences between PASI and SHR except:

• ASN Status

The Gender loaded from SHR and PASI are compared. If the Gender is the same, no updates are applied. If the Gender is different, then the PID record in SHR is updated to match PASI (see Gender below).

The Birth Date loaded from SHR and PASI are compared. If the Birth Date is the same, no updates are applied. If the Birth Date is different, then the PID record in SHR is updated to match PASI (see PID below).

If the value of the Is Deceased attribute loaded from PASI is True, then the Death Date loaded from SHR and PASI are compared. If the Death Date is the same, no updates are applied. If the Death Date is different, then the PID record in SHR is updated to match PASI (see PID below).

If the value of the Is Deceased attribute loaded from PASI is False, then the PID record is updated with a Death Date value of null.

The Is Deceased attribute loaded from SHR and PASI are compared. If Is Deceased attribute is the same, no updates are applied. If the Is Deceased attribute is different, then the PID Status record in SHR is updated to match PASI (see PID Status below).

The Citizenship information loaded into Ministry Client from SHR is compared against the Citizenship information loaded into Ministry Client from PASI.

As Citizenship information is optional in both systems, there are three scenarios that need to be considered when comparing this information:

1. If PASI has Citizenship information but SHR does not, the Ministry Client will create Citizenship information in SHR based on the data in PASI (see Citizenship below for the data population rules).
2. If SHR has Citizenship information but PASI does not, the SHR active Citizenship record will be end dated.
3. If PASI and SHR both have Citizenship information, the Ministry Client will compare the two sets of information and determine if they are equivalent. The Citizenship information in PASI and SHR will be considered equivalent if the following information is the same:

• Citizenship Status
• Authorization End Date

If the records are not equivalent, the Ministry Client will:

• End the existing Citizenship information in SHR, and
• Create new Citizenship information based on the data in PASI (see Citizenship below for the data population rules).

The Legal Name loaded into Ministry Client from SHR is compared against the Legal Name loaded into Ministry Client from PASI. The Legal Name in SHR and PASI will be considered equivalent if the following information is the same:

• First Name
• Middle Name
• Last Name

If the names are not equivalent, the Ministry Client will:

• End the Current Legal Name record in SHR, and
• Create a new Current Legal Name based on the data in PASI (see Legal Name below for the data population rules).

The AKA Name loaded into Ministry Client from SHR is compared against the AKA Name loaded into Ministry Client from PASI. The Current AKA Name in PASI and SHR will be considered equivalent if the following information is the same:

• First Name
• Middle Name
• Last Name

If the names are equivalent then no changes are applied to SHR. If the names are not equivalent, and SHR has a current AKA Name record then:

• End the Current AKA Name record in SHR, and
• Create a new Current AKA Name based on the AKA Name loaded from PASI (see AKA Name below for the data population rules)

If the names are not equivalent, and SHR does not have a current AKA Name record then the AKA Name loaded from PASI is compared against the Legal Name loaded from PASI. The AKA Name and the Legal Name will be considered consistent if:

• The AKA First Name is the same as the Legal First Name,
• The AKA Middle Name (if provided) is the same as the Legal Middle Name, and
• The AKA Last Name is the same as the Legal Last Name.

If the AKA Name and the Legal names are consistent, then no changes are applied to SHR. If the AKA Name and the Legal Names are not consistent, then an AKA Name record is created in SHR based on the AKA Name loaded from PASI (see AKA Name below for the data population rules).

The Current Mailing Address loaded into Ministry Client from SHR is compared against the Current Mailing Address loaded into Ministry Client from PASI.

As a Current Mailing Address is optional in both systems, there are three scenarios that need to be considered when comparing this information:

1. If PASI has a Current Mailing Address but SHR does not, the Ministry Client will create a Current Mailing Address in SHR based on the data in PASI (see Current Mailing Address below for the data population rules).
2. If SHR has Current Mailing Address but PASI does not, the SHR active Current Mailing Address record will be end dated.
3. If PASI and SHR both have a Current Mailing Address, the Ministry Client will compare the two addresses and determine if they are equivalent. The Current Mailing Addresses in PASI and SHR will be considered equivalent if the following information is the same:

• Address Line 1
• Address Line 2
• Address Line 3
• Address Line 4
• City
• Province
• Country
• Postal Code

If the records are not equivalent, the Ministry Client will:

• End the Current Mailing Address in SHR, and
• Create a new Current Mailing Address based on the data in PASI (see Current Mailing Address below for the data population rules).

The Permanent Mailing Address loaded into Ministry Client from SHR is compared against the Permanent Mailing Address loaded into Ministry Client from PASI.

As a Permanent Mailing Address is optional in both systems, there are three scenarios that need to be considered when comparing this information:

1. If PASI has a Permanent Mailing Address but SHR does not, the Ministry Client will create a Permanent Mailing Address in SHR based on the data in PASI (see Permanent Mailing Address for the data population rules).
2. If SHR has Permanent Mailing Address but PASI does not, the SHR active Permanent Mailing Address record will be end dated.
3. If PASI and SHR both have a Permanent Mailing Address, the Ministry Client will compare the two addresses and determine if they are equivalent. The Permanent Mailing Addresses in PASI and SHR will be considered equivalent if the following information is the same:

• Address Line 1
• Address Line 2
• Address Line 3
• Address Line 4
• City
• Province
• Country
• Postal Code

If the records are not equivalent, the Ministry Client will:

• End the Permanent Mailing Address in SHR, and
• Create a new Permanent Mailing Address based on the data in PASI (see Permanent Mailing Address for the data population rules).

The Telephone record loaded into Ministry Client from SHR is compared against the Telephone record loaded into Ministry Client from PASI.

As a Telephone record is optional in both systems, there are three scenarios that need to be considered when comparing this information:

1. If PASI has a Telephone record but SHR does not, the Ministry Client will create a Telephone record in SHR based on the data in PASI (see Telephone below for the data population rules).
2. If SHR has a Telephone record but PASI does not, the SHR active Telephone record will be end dated.
3. If PASI and SHR both have a Telephone record, the Ministry Client will compare the two records and determine if they are equivalent. The Telephone records in PASI and SHR will be considered equivalent if the following information is the same:

• Phone Number
• Extension

If the records are not equivalent, the Ministry Client will:

• End the Telephone record in SHR, and
• Create a new Telephone record based on the data in PASI (see Telephone below for the data population rules).

The various sets of transformation and cleansing rules to be applied when writing data from the Ministry Client into PASI or SHR are outlined below.

To write the Ministry Client data into SHR, the Ministry Client data must be transformed to the SHR structures. The following rules are used when the Ministry Client needs to create new information in SHR.

Unless otherwise stated, the following attributes are populated in the same fashion on all the individual records.

This attribute is populated with the current date and time on SHR.

This attribute is populated with a value of PASI.

This attribute is populated with a value consistent with the Identity of the Ministry Client. This will differ depending in the testing and development environments.

This attribute is always populated with the current date and time on SHR.

When creating a record, Effective End Date is always set to 2999-12-31 23:59:59.000. When ending a record, Effective End Date is set to be one second prior to the Effective Start Date of the new record.

When a new PID Role record needs to be created in SHR, the record will be created based on the PID Role record loaded into the Ministry Client from PASI. The following rules are used to populate the information.

This attribute is populated with the value for Learner (code 2201).

This attribute is populated with the Alberta Student Number loaded into Ministry Client from PASI.

When a new PID Role Status record needs to be created in SHR, the record will be created based on the ASN Status information record loaded into the Ministry Client from PASI. The following rules are used to populate the information. When recording PID Role Status, the existing record is ended by updating the eff_end_dt field with a value of the current date/time (less 1 second), and a new record is created.

When the Status Type loaded into Ministry Client from PASI is Primary, the PID Role Status Type is populated with a value of Active (4001).

When the Status Type is not Primary, the PID Role Status Type is populated with a value of Retired (4002).

When a new Retired PID Role needs to be created in SHR, the data will be provided based on the ASN Status information loaded into the Ministry Client from PASI. As the Retired PID Role record does not contain an eff_date_dt field, the existing Retired PID Role does not need to be updated when creating a new record.

When the Status Type is Primary, this attribute is populated with the value of Restored (code value 3102). When the Status Type is Secondary or Deactivated, this attribute is populated with the value of Retired (code value 3101).

When the Status Type is Primary, this attribute is populated with a null value. When the Status Type is Secondary or Deactivated, this attribute is populated with the pidrole_id of the source PID Role record (identified as the PID Role record with a pub_id matching the value of the Alberta Student Number loaded into the Ministry Client from PASI).

When the Status Type is Deactivated, this attribute is populated with a null value. When the Status Type is Primary or Secondary, this attribute is populated with the pidrole_id of the target PID Role record (identified as the PID Role record with a pub_id matching the value of the Primary ASN loaded into the Ministry Client from PASI).

When the Status Type is Secondary or Deactivated, this attribute is populated with the value of Created In Error (code value 3307). When the Status Type is Primary, this attribute is populated with the value of Retired In Error (code value 3401).

This attribute is populated with the value of LRDE (code value 3204).

This attribute is populated with the Current Date and Time.

When a PID record needs to be created in SHR, the record will be created based on Gender, Birth Date, and Death Date loaded into the Ministry Client from PASI. The following rules are used to populate the information.

This attribute is populated with the value of Gender loaded into the Ministry Client from PASI.

This attribute is populated with the value of Birth Date loaded into the Ministry Client from PASI.

This attribute is populated with the value of Death Date loaded into the Ministry Client from PASI.

When a new PID Status record needs to be created in SHR, the record will be created based on the Is Deceased attribute loaded into the Ministry Client from PASI. The following rules are used to populate the information. When recording PID Status, the existing record is ended by updating the eff_end_dt field with a value of the current date/time (less 1 second), and a new record is created.

If Is Deceased is False, PID Status Type is populated with the value a value of Active (code value 2001). If Is Deceased is True, PID Status Type is populated with the value a value of Deceased (code value 2003).

The PID Role Privacy Domain record is used to link the Learner (defined by the PID Role record) to the Person record (defined by the PID record) within K-12 Privacy Domain (code 10). Other than this mapping, no business data is populated.

When a new Citizenship record needs to be created in SHR, the record will be created based on the Citizenship record loaded into the Ministry Client from PASI. The following rules are used to populate the information. When recording Citizenship, the existing record (if present) is ended by updating the eff_end_dt field with a value of the current date/time (less 1 second), and a new record is created.

This attribute is populated with the value of Citizenship Status loaded into the Ministry Client from PASI.

This attribute is populated with the value of Authorization End Date loaded into the Ministry Client from PASI.

When a new Legal Name record needs to be created in SHR, the record will be created based on the Legal Name record loaded into the Ministry Client from PASI. The following rules are used to populate the information. When recording Legal Name, the existing record is ended by updating the eff_end_dt field with a value of the current date/time (less 1 second), and a new record is created.

This attribute will be populated with a value of Legal (code 1301).

This attribute is populated based on the value of First Name loaded into the Ministry Client from PASI however all diacritics and accents will be removed:

• áàäãâå becomes a, and ÁÀÄÃÂÅ becomes A
• éèëê becomes e, and ÉÈËÊ becomes E
• íìïî becomes i, and ÍÌÏÎ becomes I
• óòöõô becomes o, and ÓÒÖÕÔ becomes O
• úùüû becomes u, and ÚÙÜÛ becomes U
• ýÿ becomes y, and Ý becomes Y
• ñ becomes n, and Ñ becomes N
• ç and becomes c, and Ç becomes C

This attribute is populated based on the value of Middle Name loaded into the Ministry Client from PASI however all diacritics and accents will be removed in a similar fashion as for Given Name.

This attribute is populated based on the value of Last Name loaded into the Ministry Client from PASI however all diacritics and accents will be removed in a similar fashion as for Given Name.

This attribute is always populated with a value of None (code value 2809) as PASI does not collect or maintain a title.

When a new AKA Name record needs to be created in SHR, the data will be provided based on the AKA Name loaded into the Ministry Client from PASI. The name is transformed in a similar fashion as the Legal Name except for the Name Type which is populated with a value of AKA (code 1302).

A Contact record is used to group related contact information. As PASI captures Home contact information (mailing address and telephone number) a Home Contact record is created (i.e. Contact Type of Home - code 1401).

When a new Current Mailing Address record needs to be created in SHR, the record will be created based on the Current Mailing Address record loaded into the Ministry Client from PASI. The following rules are used to populate the information. When recording Current Mailing Address, the existing record (if present) is ended by updating the eff_end_dt field with a value of the current date/time (less 1 second), and a new record is created.

This attribute will be populated with a value of Current (code 1701).

This attribute is populated based on the value of Address Line 1 loaded into the Ministry Client from PASI however all diacritics and accents will be removed:

• áàäãâå becomes a, and ÁÀÄÃÂÅ becomes A
• éèëê becomes e, and ÉÈËÊ becomes E
• íìïî becomes i, and ÍÌÏÎ becomes I
• óòöõô becomes o, and ÓÒÖÕÔ becomes O
• úùüû becomes u, and ÚÙÜÛ becomes U
• ýÿ becomes y, and Ý becomes Y
• ñ becomes n, and Ñ becomes N
• ç and becomes c, and Ç becomes C

This attribute is populated based on the value of Address Line 2 loaded into the Ministry Client from PASI however all diacritics and accents will be removed in a similar fashion as for Address Line 1. If no Address Line 2 was loaded into the Ministry Client, this field is populated with an empty string.

This attribute is populated based on the value of Address Line 3 loaded into the Ministry Client from PASI however all diacritics and accents will be removed in a similar fashion as for Address Line 1. If no Address Line 3 was loaded into the Ministry Client, this field is populated with an empty string.

This attribute is populated based on the value of Address Line 4 loaded into the Ministry Client from PASI however all diacritics and accents will be removed in a similar fashion as for Address Line 1. If no Address Line 4 was loaded into the Ministry Client, this field is populated with an empty string.

This attribute is populated based on the value of City loaded into the Ministry Client from PASI however all diacritics and accents will be removed in a similar fashion as for Address Line 1.

This attribute is populated based on the value of Province loaded into the Ministry Client from PASI however all diacritics and accents will be removed in a similar fashion as for Address Line 1.

This attribute is populated based on the value of Country loaded into the Ministry Client from PASI. SHR uses the 3 digit ISO Country Code as opposed to the full Country Name used within PASI. Therefore, the value of Country loaded into the Ministry Client from PASI is mapped based on the mapping table in Appendix A.

If the Country cannot be mapped, a value of 999 will be used as the Country Code.

This attribute is populated based on the value of Postal Code loaded into the Ministry Client from PASI however all diacritics and accents will be removed in a similar fashion as for Address Line 1.

For Canadian Addresses, if the 4th character is a space, it will be removed before writing the information to SHR.

When a new Permanent Mailing Address record needs to be created in SHR, the data will be provided based on the Permanent Mailing Address loaded into the Ministry Client from PASI. The address is transformed in a similar fashion as the Current Mailing Address except for the Address Type which is populated with a value of Permanent (code 1702).

When a new Telephone record needs to be created in SHR, the record will be created based on the Telephone record loaded into the Ministry Client from PASI. When recording Telephone, the existing record (if present) is ended by updating the eff_end_dt field with a value of the current date/time (less 1 second), and a new record is created.

The transformation of PASI’s Preferred Phone Number depends on whether or not the Telephone record loaded into Ministry Client is considered a North American Numbering Plan (NANP) phone number. If Phone Number starts with a number, then it is considered a NANP. If the Phone Number starts with a +, then it is not considered a NANP phone number.

This attribute is always populated with a value of Phone (code 1601).

For NANP phone numbers, this attribute is populated with the value 1. For non-NANP phone numbers, this attribute is populated with the first digit (after the +) from Phone Number loaded into the Ministry Client from PASI.

For NANP phone numbers, this attribute is populated with the first 3 digits from the Phone Number loaded into the Ministry Client from PASI. For non-NANP phone numbers, this attribute is populated with an empty string.

For NANP phone numbers, this attribute is populated with the last 7 digits from the Phone Number loaded into the Ministry Client from PASI. For non-NANP phone numbers, this attribute is populated with the remaining digits (starting with the 2nd digit after the +) from the Phone Number loaded into the Ministry Client from PASI.

This attribute is populated based on the value of Extension loaded into the Ministry Client from PASI. If no Extension was loaded into the Ministry Client, this field is populated with an empty string.

As of R6.01, Protection/Disclosure Restrictions information is no longer synchronized with SHR.

The Ministry Client does not write any information into PASI. Updates to PASI must be made manually via PASIprep. To add a new ASN to PASI, the Import ASN functionality may be used.