6. Implementation: Analysis

You are viewing an ARCHIVED version of this document. Please see the latest version here.

This section discusses how the self-reported identity-related data elements in this Standard map to the CIQ v3.0 Specifications. Readers should appreciate the continually evolving nature of specifications and subsequent prescriptions of the specifications contained in this Standard. While the implementation analysis of CIQ v3.0 prescribed in this Standard (together with the XPath Statements, associated example XML files and IVS requirements) are valid at the time of writing, these core specifications may change over time. Exchanging parties implementing this Standard should refer to the latest specifications available and agree on any adjustment in their implementation as and when necessary.

6.1 Definition of identity-related data elements

Table 2 contains definitions and data types for the identity-related data elements in this Standard.

Table 2 - Definition of identity-related data elements as reported by the person

Name

The full name, separated into logical atomic components: First Name, Middle Name/s and Last Name.

Text or Character

Gender

The current sex of the person. Current sex aligns with the Department of Internal Affairs' identity processes.

While not strictly accurate, the use of the term 'Gender' to describe current sex in face-to-face self-reported contexts is regarded as more socially and culturally acceptable by some sector agencies. Therefore a sex value is used to populate CIQ v3.0 Gender element.

The sex code will be chosen from a code list: F, M, U (see Appendix A).

Text or Character

Mother's Name

The full name of the person's mother at the time of the mother's birth is a string.

This structure is used to reflect the possibility that the person reporting their mother's name at the time of the mother's birth may not be able to separate it into logical atomic components.

Text or Character

Date of Birth

The date of birth for the person, separated into logical atomic components: Birth Year, Birth Month, Birth Day and Birth Time.

The Birth Time structure is less rigid than the BirthDateTime structure in CIQ v3.0 to accommodate the likely variety of recording devices available 'in situ'.

Numeric

Place of Birth

The name of the Locality and Country where the person was born. Locality is a string and the Country code will be chosen from a code list (see Appendix B).

The Locality structure allows the optional use of enumeration or controlled value lists and implementation-related application logic.

Text or Character

NOTE -

1. Data for each of the data elements defined in Table 2 is as reported by the person(self-reported) in relation to their own identity. That is, the data need not be verified against source documentation. This is why some data elements are not separated into logical atomic components. The person reporting this data to an agency may have insufficient detailed knowledge of the elements, beyond their own name.
2. Where agencies wish to exchange multiple instances of Name of Person, they should use multiple instances in the exchange record.
3. Where agencies wish to exchange data that requires a time-qualifier, they should use business processes to do this.

6.2 Identity-related data elements and their atomic (or granular) values

Figure 3 provides a schematic representation of the atomic or granular components of the five identity-related data elements defined in Table 2.

Figure 3 - Identity-related data elements and their atomic (or granular) values

6.3 Diagrammatic model of CIQ v3.0

Figures 4 to 6 have been derived using Altova's XML editing tool, XMLSpy. A guide to the symbols used in the figures is set out in Appendix C.

Figure 4 shows the highest-level view of the CIQ v3.0 Specifications. The <Party> element contains all of the customer information data elements. This element may be used to represent an individual or an organisation, or a combination of both. There is specific syntax to describe the relationship between members of a party if there is more than one.

The <Party> element contains the <PartyName> and <PersonInfo> containers. Each of the identity-related data elements maps to one of these two CIQ v3.0 containers. The details of this mapping are reviewed in 6.4.

Figure 4 - Party container (from CIQ v3.0 schema)

6.4 Mapping the CIQ v3.0 Specifications to the five self-reported identity-related data elements

6.4.1 PersonName sub-container

The <PartyName> container includes the <PersonName> sub-container, which has the elements <NameElement> and <KnownAs> (see Figure 5). The <NameElement> element contains the atomic parts of a person's name, distinguished by the enumeration list values, LastName, FirstName, MiddleName, MiddleName. The <KnownAs> element allows for aliases to exist in the customer record.

Figure 5 - <PersonName> sub-container with <NameElement> element

6.4.2 Name

The <NameElement> element has an enumeration list that provides flexibility in the metadata tags and, therefore, the context of the data contained in the element. As there is no mechanism to explicitly constrain the content of the <NameElement> element, the CIQ v3.0 requirement for a specific order must be satisfied with programmatic support and explicit business rules. The elements in the <PersonName> sub-container shall appear in the order shown in the following extract from the sample validated exchange file:

Surname prefixes such as de, von, le etc are included within the last name with a space between the prefix and the surname:

<n:NameElement n:ElementType="LastName">de Jong</n:NameElement>

6.4.3 PersonInfo container

The <PersonInfo> container can be used to represent the remaining identity-related data elements: gender, mother's name, date of birth, and place of birth. The related nodes for the <PersonInfo> container are shown in Figure 6.

Figure 6 - PersonInfo container showing related nodes, including BirthInfo sub-container

6.4.3.1 Gender

In order to accommodate the person's current sex the <PersonInfo> container in CIQ v3.0 has an element called gender that contains a string. The schema does not inherently support a validation or enumeration list for this element. Therefore, this Standard uses the code list values F, M or U from the code list HISO 10006, 2.4.1 in Appendix A. The gender element, as it appears in the sample validated exchange file, is shown as:

< n1:PersonInfo n1:Gender="">

6.4.3.2 Mother's name

In order to accommodate the birth name of the person's mother in a CIQ v3.0 element, the enumeration list for the <BirthInfoElement> element has to be changed to include the attribute value "MothersName". The attribute value "MothersName", as it appears in the sample validated exchange file, is shown in the following extract.

<n1:BirthInfoElement n1:ElementType="MothersName"></n1:BirthInfoElement>

6.4.3.3 Date of birth

In order to accommodate a granular date of birth, the enumeration list for the <BirthInfoElement> element has to be changed to include the following attribute values: "BirthYear", "BirthMonth", "BirthDay", and "BirthTime". These attribute values, as they appear in the validated exchange file, are shown as:

<n1:BirthInfoElement n1:ElementType="BirthYear"></n1:BirthInfoElement>
<n1:BirthInfoElement n1:ElementType="BirthMonth"></n1:BirthInfoElement>
<n1:BirthInfoElement n1:ElementType="BirthDay"></n1:BirthInfoElement>
<n1:BirthInfoElement n1:ElementType="BirthTime"/>

As there is no mechanism to explicitly constrain the content of the <BirthInfoElement> element, the requirement for a numeric data type must be satisfied with programmatic support and explicit business rules. The <BirthInfoElement> element's attribute values are numeric, with specific value ranges as appropriate to the meaning of the element:

• BirthYear will have a format of YYYY. Values must be equal to or greater than 1890 and less than or equal to today's date
  
• BirthMonth will have a format of MM. Values must be greater than 00 and less than 13
• BirthDay will have a format of DD. Values must be greater than 00 and less than 32
• BirthTime is likely to be left blank, but will have a format of HH:MM:SS. Values must be greater or equal to 00 and less than or equal to 60.

NOTE - The BirthDateTime attribute from CIQ v3.0 has not been specified in this Standard. In the view of the working group the highly constrained numeric value specified in BirthDateTime may inhibit wide adoption of this attribute. However, exchanging parties MAY agree to use BirthDateTime in their data exchange agreements if it is practical to do so.

6.4.3.4 Place of birth

Birth Place should be described by Country name and Locality name.

Country name can either be abbreviated, using ISO 3166 two letter codes, or entered as a complete word. If the exchanging parties are prescribing abbreviations, it MUST be indicated in the Country Name node (abbreviation values are "true" or "false").

Locality name is described with two nodes, one for the type of locality, e.g. city, suburb, town, village, and one for its actual name.

A sample file format sample for BirthPlace nodes, including Country and Locality is as follows:

<n1:BirthPlace>
<a:Country>
<a:Name a:Abbreviation="true"> </a:Name>
</a:Country>
<a:Locality>
<a:Name a:NameType="Type"> </a:Name>
<a:Name a:NameType="Name"> </a:Name>
</a:Locality>
</n1:BirthPlace>

NOTE -

(1) If a controlled value list for type of locality is desired, it must be agreed between the parties in the data-exchange agreement. Specific values should not be added to the schema to enforce rules of conformity for the locality types.

(2) Due to the changing nature of the ISO 3166 Code Lists in response to new nation names emerging and others ceasing use, a person may self-report a country that does not appear in the list. For example, Yugoslavia no longer appears on the latest ISO 3166 code list. The treatment for this is to allow a string value as the following sample file extract shows:

<a:Country>
<a:Name :Abbreviation="false">Yugoslavia</a:Name>
</a:Country>