Data standards for Western Australian government

Standards designed to improve data sharing and common reporting across the Western Australian government by ensuring consistency of collection and organisation of data and metadata structures.
Last updated:

Background

These standards provide a guide for collecting data in Western Australian Government. They enable a common approach to collecting data that is frequently used by agencies. This will promote consistency in the use of data which will support projects that improve client journeys and service development. 

Naming standards guidance

People use a variety of names, including legal names, married or maiden names, nicknames, assumed names and traditional names. Even small differences in recording, such as the difference between Thomas and Tom, can make data linkage difficult or impossible. 

To minimise discrepancies in the recording and reporting of name information, agencies should ask the person for their full (legal) given name(s) and family name.

An overview of the core and optional fields for naming standards

Use of family names
In some cultures, it is traditional to state the family name first. To overcome discrepancies in recording/reporting that may arise as a result, agencies should always ask the person to specify at least their first given name and their family name separately. 

These should then be recorded as 'Given name' and 'Family name' as appropriate, regardless of the order in which they may be traditionally given. 

A diagram of an example of a person's names according to the standard

Person with only a single name​
Some people do not have a family name and a given name, but have only a single name by which they are known. For such individuals their name should be recorded in the Family name field and the Given name field left should be blank.

Use of preferred names
A person’s given name(s) may be different from the name that the person prefers to use in personal dealings. This is the name that should be used in dealing with that person, for example in correspondence.
Where required, agencies should separately record the preferred name that the person wishes agency staff to use.​ If a person does not nominate a preferred name, their preferred name field should be left blank, and their first given name should be treated as their preferred name.

Name usage types
Certain names, including aliases and preferred names, may also be recorded with a ‘name usage type’ that indicates the purpose of reason for the person using the name. e.g. Previous name, Maiden name. 

Character limits on names
While these standards largely rely on the AIHW’s naming standards as references, there’s one small but important difference. The AIHW suggest a limit of 40 characters for names, but feedback from real-life use in government datasets is that 80 characters is a safer limit.

Given name(s)

A person's identifying name(s) within their family group or by which they are socially identified.

Format

Text - Maximum length 80

Permitted values

 

Guide for use

Given names are often assigned by parents or acquired by a person in accordance with a state or territory Act.  The given name should be written as indicated by the person or as shown on an identification card. ​

​All of the person's given names should be recorded as separate data items (e.g. given_name_1, given_name_2, …)​

Related data collection standards

AIHW METeOR 613340 - Person—given name, text X[X(39)], 2016 (external link)

More information
Refer to the AIHW standard for additional information, including how to:​

  • phrase questions asking a person for their given name(s),​

  • detailed guidance on handling special characters, and​

  • names not for continued use due to cultural reasons

Version

2022.03
First version published

Family name

The name a person has in common with some other members of their family.

Format

Text - Maximum length 80

Permitted values

There are no universal verification rules for a person's preferred name.

Guide for use

Family names are often handed down through generations in a family, and are distinguished from a person's given name(s). Examples include the hereditary or tribal surname of a person’s family.​

In some cultures it is traditional to state the family name first. To overcome discrepancies in recording/reporting that may arise as a result of this practice, agencies should always ask the person to specify at least their first given name and their family name separately. These should then be recorded as 'Given name' and 'Family name' as appropriate, regardless of the order in which they may be traditionally given.​

​Family name should be recorded in the format preferred by the person. ​The format should be the same as that written by the person on a (pre) registration form or in the same format as that printed on an identification card, such as a Medicare card, to ensure consistent collection of name data. ​​

​​​More information:
Refer to the AIHW standard below for information, including how to:​

  • ​how to store family names that contain more than one word, ​
  • handling people who only have one name, and​

  • detailed guidance on handling special characters

Data collection standards

AIHW METeOR 613331 - Person—family name, text X[X(39)], 2016

Version

2022.03
First version published

Preferred name

The name a person wishes to be addressed by in personal dealings.

Format

Text - Maximum length 80

Permitted values

There are no universal verification rules for a person's preferred name.

Guide for use

A person’s preferred name may be different from their given or legal name.  It is the name that the person prefers to use in personal dealings (e.g. in conversation and/or for the purposes of written communication).  If the preferred name does not differ from a person's given name, this field can be left blank. ​

​The preferred name should be written as indicated by the person. 

Related data collection standards

AIHW METeOR 613340 - Person—given name, text X[X(39)], 2016

Note: Preferred name is not a separate standard maintained by the AIHW. It is included as part of their ‘Given name’ standard. For the purpose of Western Australian Government data collection, it is a separate data field.

Version

2022.03
First version published

Alias(es)

An alias is any other name that that a person is known by – for example married/maiden names, cultural names, anglicised names, and any other names you are known by.

Format

Text - Maximum length 80

Permitted values

 

Guide for use

Aliases are any other name that a person is also known by, or has been known by in the past. This includes misspelled names or name variations that are to be retained as they have been used to identify this person. More than one alias name may be recorded for a person.​

​Where required by agencies, aliases may be recorded with a ‘name usage type’ that describes the nature of/reason for the alias. (e.g. Previous name, Stage name). Refer to the data collection standards below.​

​For example, when a person informs an agency of a change of family name (e.g. following marriage or divorce), the former name should be recorded as an alias name. A full history of names should be retained. e.g. 'Mary Georgina Smith' informs the hospital that she has been married and changed her family name to 'Jones'. Record 'Jones' as her Family Name and record 'Smith' as an alias name.​

​Where a person has more than one alias, each of them should be recorded as separate data items (e.g. alias_name_1, alias_name_2, …).

Related data collection standards

Note: Alias is not a separate standard maintained by the AIHW. It is included as part of their person naming standards. For the purpose of Western Australian Government data collection, we are treating it as a standalone standard and a separate data field.​

AIHW METeOR 286953 - Person (name)—family name, text X[X(39)], 2005

AIHW METeOR 521079 - Person—name usage type, code X, 2016

Version

2022.03
First version published

Pseudonym(s)

Pseudonyms permit a person to use a fictitious or partial name in lieu of their full or actual name to  protect their identity.

Format

Text - Maximum length 80

Permitted values

 

Guide for use

Pseudonyms may be required in order to mask the identity of an individual—for example, in the case of HIV testing—where the subject of care has the right of anonymity in many jurisdictions. In this case a pseudonym can be entered in lieu of the person’s actual name. It is recommended that the subject be asked to record both the pseudonym (other name) as well as a legal name.​

​Registering a pseudonym requires agency systems to be able to identify which name is to be used or displayed as the Preferred name. This might require a means to temporarily change the pseudonym name to preferred name, which is then changed back to the normal preferred name after the pseudonym use is over.​

​Where a person has more than one pseudonym, each of them should be recorded as separate data items (e.g. pseudonym_1, pseudonym_2, …).

Related data collection standards

AIHW METeOR 613331 - Person—family name, text X[X(39)], 2016

Note: Pseudonym is not a separate standard maintained by the AIHW. It is included as part of their person naming standards. For the purpose of Western Australian Government data collection, we are treating it as a standalone standard and a separate data field.​

Version

2022.03
First version published

Sex and gender guidance

The terms sex and gender are two distinct concepts.  However, they are interrelated and often used interchangeably:​

  • Sex refers to sex characteristics, such as chromosomes, hormones and reproductive organs.​

  • Gender refers to social and cultural expressions of identity and experience. ​

Collecting information on sex and gender​
A number of agencies collect sex and/or gender information for the purposes of contacting and referring to their clients. Data collections should be clear as to whether the field collects data on sex recorded at time of birth, sex recorded at time of data collection, or gender. This should be reflected clearly in both the name of the field and in the data dictionary.​

Sex at ‘point of collection’ and ‘sex at birth’​
A person’s sex can change over the course of their lifetime and may differ from the sex recorded when they were born. A collection may ask for a person's sex at that point in time or their sex as it was recorded at birth.​

Sex at birth is an important indicator for statistical analysis in births and deaths, health statistics, and for use in data linkage. However, collecting only sex at birth without an accompanying gender field does not provide an option for a person’s gender (which may not align with the sex assigned at birth) to be recognised in government records. ​

​Asking a person about sex and gender​
As the terms sex and gender are often incorrectly used interchangeably, a respondent might provide a gender response to a sex question.​

​The Australian Bureau of Statistics Standard for sex, gender, variations of sex characteristics and sexual orientation variables (ABS 2020) recommends that:​

  • ​where both sex and gender are collected, it is recommended that the sex question is asked first, with a clear indication that a gender question will also be asked.​
  • for collections requiring cis and trans outputs, sex recorded at birth should be used

A person's sex is based upon their sex characteristics.

Format

Integer (with coding map - preferred) – maximum length 1

Permitted values

Preferred code

Alternative code

Label

Definition

1

M

Male

Persons whose sex was recorded as male.

2

F

Female

Persons whose sex was recorded as female.

3

X

Another term

Persons whose sex was recorded as other than male or female.

9

NS

Not stated or inadequately described.

Used to code a non-response or inadequately described response for sex.

Guide for use

A person's sex is based upon their sex characteristics, such as their chromosomes, hormones and reproductive organs.  Data collections should be clear as to whether the field collects data on sex recorded at time of birth, sex recorded at time of data collection. ​

​The ‘Another term’ (please specify) option should provide a write-in field and be stored as a separate data field.

Related data collection standards

ABS 1200.0.55.012 - Standard for Sex, Gender, Variations of Sex Characteristics and Sexual Orientation Variables, 2020

More information
Refer to the ABS standard below for information, including how to:​

  • phrase questions asking a person to report their sex and​

  • guidance on how to collect both sex and gender

Version

2022.03
First version published

Gender is a social and cultural concept. It is about social and cultural differences in identity, expression and experience as a man, woman or non-binary person. Non-binary is an umbrella term describing gender identities that are not exclusively male or female.

Format

Integer (with coding map) – maximum length 1

Permitted values

Preferred code

Alternative code

Label

Definition

1

M

Man or male

Persons who described their gender as man or male.

2

F

Woman or female

Persons who described their gender as woman or female.

3

X

Non-binary

Persons who described their gender as non-binary.

4

T

Different term

Persons who described their gender as a term other than man/male, woman/female or non-binary.

5

Z

Prefer not to answer

Persons who preferred not to respond on how they describe their gender.

9

NS

Not stated or inadequately described.

Guide for use

A person's gender may differ from their sex and may also differ from what is indicated on their legal documents.  A person's gender may stay the same or can change over the course of their lifetime. ​

​Some people may not identify with a specific gender or with the concept of gender at all. The ‘Different term’ (please specify) option should provide a write-in field and be stored as a separate data field.​

​Responses to a gender question may reflect a combination of gender identity, expression and/or experience. In statistical collections, gender may be reported in terms of a person's felt or lived gender, as well as how that person is perceived by others, depending on whether information on gender is based on self-reported data or done by proxy.

Related data collection standards

ABS 1200.0.55.012 - Standard for Sex, Gender, Variations of Sex Characteristics and Sexual Orientation Variables, 2020

​More information
Refer to the ABS standard below for information, including how to:​

  • phrase questions asking a person to report their gender,​

  • guidance on the output categories to use when sharing data (e.g. ‘Different term’ responses may be coded as ‘Non-binary’)​

  • guidance on conceptual issues (e.g. the different concepts within gender - gender identity vs gender expression)

Version

2022.03
First version published

Country of birth

The country where a person was born.

Format

Number NNNN (with coding map)- Maximum length 4

Permitted values

Country of birth is built on the ABS’s Standard Australian Classification of Countries 2016 (SACC).​

​The SACC is a hierarchical structure specifying major groups, minor groups, and countries.​ This allows for easy aggregation of countries into common groupings.

​It uses a four-digit numbering scheme for countries. For example, Australia’s code is ‘1101’ and New Zealand’s is ‘1201’:​

​1 OCEANIA AND ANTARCTICA​

     11 Australia (includes External Territories)​

          1101 Australia​

          1102 Norfolk Island​

Visit our GitHub page for a full list of permitted values

Guide for use

The Country of Birth standard codifies the concept, definitions, and methods recommended by the Australian Bureau of Statistics for collecting, processing and presenting country of birth data. ​

​Country of Birth may be used with a range of other variables to understand the cultural and ethnic composition of the population. 

Related data collection standards

ABS 1200.0.55.004 - Country of Birth Standard, 2016

ABS 1269.0 - Standard Australian Classification of Countries (SACC), 2016

More information
Refer to the ABS standard for additional information, including how to:​

  • handling of countries that no longer exist (e.g. the USSR),​

  • phrase questions asking a person for their, or their parents, country of birth, and​

  • the order in which countries should be listed for form-based data collection (e.g. weighted by statistical frequency in Australia)

Version

2022.03
First version published

Aboriginal status

The standard enables the provision of consistent information about people who identify as being of Aboriginal and/or Torres Strait Islander origin.

Format

Integer (with coding map) – maximum length 1

Permitted values

Preferred code

Definition

1

Aboriginal but not Torres Strait Islander Origin 

2 Torres Strait Islander but not Aboriginal Origin 
3 Both Aboriginal and Torres Strait Islander Origin 

4

Neither Aboriginal nor Torres Strait Islander Origin

9

Not stated/Inadequately defined 

Guide for use

There are three components to the Commonwealth definition of Aboriginal or Torres Strait Islander: descent, self-identification, and community acceptance. In practice, it is not feasible to collect information on community acceptance in general purpose data collections. Therefore, standard questions on Aboriginal status relate to descent and self-identification only.​

Terminology​
The term Aboriginal people is used in preference to "Indigenous" or "Aboriginal and Torres Strait Islander" people, in recognition that Aboriginal peoples are the original inhabitants of Western Australia.​

​The accepted term for this variable is Aboriginal Status. Abbreviated forms of 'Aboriginal and Torres Strait Islander' and ‘Torres Strait Islander’ (e.g. ATSI) should not be used.

Related data collection standards

AIHW METeOR 291036 - Person - Indigenous status, code N, 2014

ABS 1200.0.55.008 - Indigenous Status Standard, 2014, Version 1.5

Version

2022.03
First version published

Language

 The language (including sign language) most preferred by a person for communication.

Format

Number NNNN (with coding map)- Maximum length 4

Permitted values

Language-based data fields should use the Australian Standard Classification of Languages (ASCL) 2016.

​The ASCL is a hierarchical structure of languages organised into broad groupings. This allows for easy aggregation of languages into commonly understood groupings. ​

​It uses a four-digit numbering scheme for languages. For example, the code for ‘Gaelic (Scotland)’ is ‘1101’​

​1 Northern European Languages​
     11 Celtic​
          1101 Gaelic (Scotland)

Visit our GitHub page for a full list of permitted values

Guide for use

Languages may be collected for a variety of reasons, including:​

  • Preferred language: To indicate the language most preferred by the person for communication for translation/interpretation.​
  • Main language other than English spoken at home: As one indicator of diversity

​All world languages are in scope of the classification and languages with significant numbers of speakers in Australia are separately identified within the classification structure.​

​Special attention has been given to separately identifying Australian Aboriginal languages. Languages which are not separately identified are included in the most appropriate residual category of the classification.

This standard is intended as a guide for collecting and sharing data on languages. In some cases, more detailed information not captured in the standard may need to be collected - for example, information about dialects for providing interpreters.

The ASCL standard has coding indexes available to help with linking dialects to the relevant language in the ASCL when sharing or reporting on more detailed data.

Related data collection standards

AIHW METeOR 659407 - Person—preferred language, code (ASCL 2016) N[NNN], 2018

ABS 1267.0 - Australian Standard Classification of Languages (ASCL), 2016

Version

2022.03
First version published

Ancestry

Ancestry describes the ethnic origin or cultural heritage to which a person identifies and/or to which that person's parents or grandparents identified with or belonged to.

Format

Number NNNN (with coding map)- Maximum length 4

Permitted values

Ancestry data should be collected according to the Australian Standard Classification of Cultural and Ethnic Groups (ASCCEG) has a three level hierarchical structure that consists of broad groups, narrow groups, and cultural and ethnic groups ​

​Example:​

​Broad group, 1 Oceanian
     Narrow group, 1 Australian Peoples ​
          Cultural and ethnic group, 1101 Australian 

Visit our GitHub page for a full list of permitted values

Guide for use

The ancestry variable can be used in conjunction with other key cultural and language-related variables to understand ethnicity or culture.  Ancestry in the Australian context is complex as there are many Australians with a heritage that does not, in practice, relate to their current ethnic identity.​

​Ancestry data alone, therefore, is not considered a good measure of service needs or advantage or disadvantage. When ancestry data is used alone, it should only be done to represent a broad measure of cultural diversity.

The ASCL standard linked below has coding indexes available to help with mapping responses not included in the standard.

Related data collection standards

ABS 1200.0.55.009 - Ancestry Standard, 2014, Version 2.1

ABS 1249.0 - Australian Standard Classification of Cultural and Ethnic Groups (ASCCEG), 2019

More information
Refer to the ABS standard for additional information, including how to:​

  • a list of other key cultural and language-related variables to use alongside ancestry data and​

  • discussion of conceptual issues.

Version

2022.03
First version published

Address and high-level location standards guidance

The address standards are a collection of address components describing a specific physical location, usually a residential, postal, or business address.​

​The high-level location standards include broad location data elements, such as suburbs, postcodes, and local government areas.​

The common reporting boundaries will see agencies reporting and sharing data using the same geographic basis in addition to their own boundaries.

There are 15 standards covering addressing and location. Click the button below for the standards and more detailed guidance on this topic.

A diagram explaining the phased approach for improving addressing and location data. Moving from treating addresses as text, to addresses as data, and to common reporting boundaries in the last phase

​Phase 1
The first phase of implementation will see agencies moving from the practice of storing and sharing addresses as pieces of text to treating addresses as pieces of data.

Addresses and locations should be validated and geocoded as close as possible to the point of collection. The resulting validated information should be stored as separate data elements alongside the text version of the address.

Phase 2
The second phase will see agencies sharing and reporting data at the three common reporting boundaries. ​Agencies should begin preparing their address-level datasets now to be able to report and share them at the boundaries.

More information about address and location standards

Estimating dates and dates of birth guidance

Not all data collected with dates is accurate. However, it may sometimes be more helpful to have inaccurate information rather than no information at all. To assist in separating accurate data from estimate data, an estimated date flag is often used.​

​Dates can be stored using a special form of notation to indicate the amount of inaccuracy they contain.​

​However, the way to do this differs depending on whether the date is a date of birth or not. ​

​Alignment to standards​
There are a variety of approaches to recording uncertainty in dates already in use in agencies, and international standards are still relatively new and not implemented widely. In recognition of this, alignment to this part of the standards is on a 'best effort' basis.​

A 'Date estimate flag' is only required when it is possible for the data field to contain either estimated or inaccurate dates. For example, when data is collected on something that may naturally have some uncertainty about it (e.g. dates of birth) or where the means of collection can result in inaccuracies (e.g. data entered from a paper form or PDF).

The flag is not required for fields that will always contain accurate data - for example, system-generated dates and timestamps.

A diagram explaining how to structure data fields to capture estimated date information
A diagram explaining two scenarios for captured an estimated data and an estimated date of birth

Estimated dates​
Where the date recorded for an event may contain uncertainty or inaccuracy, an additional text data field for the inaccurate dates should be created. The ISO-8601 standard (2019 extensions) can then be used to encode  the ‘amount’ of uncertainty using special characters.​

How to be uncertain with dates [External link: datafix.com.au] provides a summary of the draft ISO standard.​

Estimated dates of birth 
Dates of birth have their own particular rules for expressing uncertainty.​

​Estimated age should usually be in years for adults, and to the nearest three months (or less) for children aged less than two years.​

​If date of birth is not known or cannot be obtained, provision should be made to collect or estimate age. To provide information on the accuracy of the date, a flag should be reported alongside all estimated dates of birth.​

Recording the reason for uncertainty​
It is recommended that written commentary about the nature of the inaccuracy is recorded alongside the flag. (e.g. "Applicant does not know their exact date of birth, believes it was 1984").

Event date and time

​The date, or date and time, of a generic event.

Format

Date YYYY-MM-DD​
Dates should be stored using the native ‘date’ data type of the data store.​

Date and time with time zone
Dates with times should be stored using the native ‘datetime’ data type of the data store. Time zone information should always be included.​

If a field is capturing uncertain dates and times​
A text data field should be used to store estimated date and/or time. Further guidance regarding the standards for storing dates with uncertainty can be found in the Estimating dates and dates of birth guidance section.

Permitted values

Format

Value ranges

Year 

YYYY, four-digit, may be abbreviated to two-digit

Month

MM, 01 to 12

Day 

D, day of the week, 1 to 7

Hour 

hh, 00 to 23, 24:00:00 as the end time

Minute 

mm, 00 to 59

Second 

ss, 00 to 59

Decimal fraction  Fractions of seconds, any degree of accuracy

Time zone

Represented as the hours and minutes offset from UTC/GMT (-24:00 to 24:00)

Guide for use

Dates and times may be recorded for a wide range of events. For example, someone staying in hospital would have an event date and time recorded both for when they are admitted to hospital, and when they are discharged.​

This standard focuses on ensuring there is consistent storage of date and time data. How they are represented by systems using the data depends on the business requirements of individual systems. e.g. A system may need to only display a date as“13 January, 2022 3:00PM” based on a date stored using the ISO standard.

​For guidance on recording the uncertainty or accuracy of dates, refer to the Estimating dates and dates of birth Guidance (above).

Related data collection standards

ISO 8601 – Effectively Communicate Dates and Times Internationally

Version

2022.03
First version published

Date of birth

The date a person was born.

Format

Date e.g. DDMMYYYY

Permitted values

Dates should be stored using the native ‘Date’ data type of databases.​

​If a field is collecting estimated dates of birth
A text data field with a maximum length of 8 should be used to store estimated date. In this case, dates should be stored as text in the format ‘DDMMYYYY’. 

Guide for use

The date of birth should be used rather than age because the date of birth allows a more precise calculation of age.

Related data collection standards

AIHW METeOR 287007 - Person—date of birth, DDMMYYYY, 2005

More information
Refer to the AIHW standard for additional information, including how to:​

  • phrase questions asking people for their date of birth,​

  • handle collection of estimated dates of birth, and​

  • the collection and coding of data for children under 2 years​

Version

2022.03
First version published

Date estimate flag

An indicator of whether any component of a reported date was estimated.

Format

Integer (with coding map) – maximum length 1

Permitted values

Preferred code

Label

1

Estimated

2

Not estimated

9

Not stated/inadequately described

Guide for use

This data element may be reported in conjunction with a date when any component of the date represents an estimate rather than the actual or known date.​

​For example​

  • Estimated dates of birth may only be accurate to a given year.​

  • The date an event or incident occurred may only be accurate to a period covering several days.​

Related data collection standards

AIHW METeOR 742390 - Date—estimate indicator, code N, 2021

Version

2022.03
First version published

Telephone number

The primary contact telephone number for a person or organisation

Format

Text - Maximum length 16

Permitted values

Australian telephone numbers are usually 6 to 10 digits in length.​

​The format and length of a telephone number is dependent on the attribute(s) of the device and how the device connects to the telephone network.

Guide for use

Telephone numbers should be stored as text, but rules can be set up to display the number in a different format, e.g. 0400 000 000​

​For simplicity the standard has not separately recorded the fact that an attribute of a device may imply that it needs to use a mobile phone network, landline or other type of telephone network.​

Use of country codes
When a telephone number is used in conjunction with a country code the leading 0 at the start of the telephone is to be removed e.g. 0453176731 becomes 61 453176731 or 08 999 66 999 becomes 61 8 999 66 999.

Use of alphabetical characters in place of numbers
The standard allows for letters of the alphabet to replace numbers (e.g. ABC = 2, DEF = 3). Where systems need to accommodate this form, systems should translate the letters to numbers at the time of input.​

Related Data Collection Standards

AIHW METeOR 452682 - Address—telephone number, text X[X(15)], 2012

Version

2022.03
First version published

Telephone number type

The type of telephone number recorded for a person or organisation.

Format

Text - Maximum length 1

Permitted values

Preferred code

Label

B

Business or work

H Home
M Personal mobile 

N

Contact number (not own)

O Business or work mobile

T

Temporary

Guide for use

Where more than one telephone number has been recorded, each telephone number should have a telephone number type code recorded alongside it.​

Related Data Collection Standards

AIHW METeOR 270299 - Person (telephone)—telephone number type, code A

Version

2022.03
First version published

Person identifier

An identifying code or number for a person within an agency that is unique to that person.

Format

String – maximum length 20

Permitted values

 

Guide for use

Individual agencies may use their own alphabetic, numeric or alphanumeric coding systems to create unique identifiers,​

​Person identifiers should follow these guiding principles:​

  • ​unique to that person (for example – once assigned, they cannot be retired and re-used for another person or entity)​
  • remain stable over time (for example – a person id assigned as a child remains with that person over their lifetime regardless of changes to their names, gender, relationship status, etc.)​

  • used consistently to identify the person throughout an agency’s data assets​

​This is not a technical standard and does not cover the complexities necessary for implementation of identifiers. Further guidance should be sought on a case-by-case basis.

Related data collection standards

AIHW METeOR 290046 - Person—person identifier, XXXXXX[X(14)], 2005

Version

2022.03
First version published

Was this page useful?