6. Implementation: Analysis

[ Table of Contents ]

This section discusses how the self-reported identity-related data elements in this Standard map to the CIQ Specifications v3.0. 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 publication, 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 B).

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 C).

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.
4. Where agencies wish to incorporate a pseudonymous identifier in an exchange file, they should use the "PartyID" and "PartyIDType" attributes for the <Party> container (see Appendix E).

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 F. Note that not all CIQ v3.0 components are able to be represented in these figures.

The <Party> container from the CIQ xPIL Specification v3.0 contains all of the party information data elements. This container can 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> container includes the <PartyName>, <PersonInfo>, and <BirthInfo> containers. Each of the five identity-related data elements specified in this Standard maps to one of these three containers. The details of this mapping are reviewed in 6.4. Figure 4 shows the relationship of these three containers to the <Party> container.

Figure 4 - <Party> container showing <PartyName>, <PersonInfo>, and <BirthInfo> containers (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> container

The <PartyName> container includes the <PersonName> container from the OASIS CIQ xNL Specification v3.0. The <PersonName> container has an element <NameElement> that defines person name (see Figure 5). The <NameElement> element contains the atomic parts of a person's name which are distinguished by the default enumeration list values provided by the Specification.

Figure 5 - <PersonName> 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> 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>

NOTE - If it is necessary to differentiate between surname and surname prefixes, then the enumeration "LastNamePrefix" can be added to the enumeration list for <NameElement> by modifying an XML schema definition file (xPIL-types.xsd) by inserting the XML code:

<xs:enumeration value="LastNamePrefix"/>

The corresponding <NameElement> element will appear in the exchange file as:

<n:NameElement n:ElementType="LastNamePrefix"></n:NameElement>

6.4.3 PersonInfo container

The <PersonInfo> container can be used to represent gender.

6.4.3.1 Gender

In order to accommodate the person's current sex, the <PersonInfo> container has an element called gender that is an empty enumeration list. The enumeration list MUST be populated with code list values F, M, or U from the code list HISO 10006 (see Appendix B).

6.4.4 <BirthInfo> container

The <BirthInfo> container includes the <BirthInfoElement> element and <BirthPlaceDetails> container. This element and container can be used to represent the three remaining identity-related data elements: mother's name, date of birth, and place of birth (see Figure 6).

Figure 6 - <BirthInfo> container with <BirthInfoElement> element and <BirthPlaceDetails> container

6.4.4.1 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.

<p:BirthInfoElement p:Type="MothersName"></p:BirthInfoElement>

6.4.4.2 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:

<p:BirthInfoElement p:Type="BirthYear"></p:BirthInfoElement>
<p:BirthInfoElement p:Type="BirthMonth"></p:BirthInfoElement>
<p:BirthInfoElement p:Type="BirthDay"></p:BirthInfoElement>
<p:BirthInfoElement p:Type="BirthTime"></p:BirthInfoElement>

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 for "HH" must be greater or equal to 00 and less than or equal to 24. Values for "MM" and "SS" 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.4.3 Place of birth

The <BirthPlaceDetails> container includes the <Country> and <Locality> containers from the OASIS CIQ xAL v3.0 Specification. The <Country> and <Locality> containers can be used to represent the place of birth in a CIQ v3.0 element.

The 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").

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

An extract from the sample validated exchange file for place of birth is as follows:

<a:Country>
  <a:NameElement ct:Abbreviation="true"
  a:NameType="Name"></a:NameElement>
</a:Country>
<a:Locality>
  <a:NameElement a:NameType="Type"> </a:NameElement>
  <a:NameElement a:NameType="Name"> </a:NameElement>
</a:Locality>


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:NameElement ct:Abbreviation="false"
 a:NameType="Name">Yugoslavia</a:NameElement>
</a:Country>