Data standards for 91短视频n government

Standards designed to improve data sharing and common reporting across the 91短视频n 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 91短视频n 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. 

Facts and FAQs icon

Implementation guidance

Answers to common questions from agencies about implementation of these standards.
Icon of person with a business presentation in the background

A repository for the detailed specifications and permitted values of individual standards

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鈥檚 given name(s) may be different from the name that the person prefers鈥痶o 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鈥痶he 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 鈥榥ame 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鈥檚 naming standards as references, there鈥檚 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鈥痜amily鈥痝roup 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. 鈥

鈥婣ll 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

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鈥痭ame a person鈥痟as in common with some other鈥痬embers 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鈥檚 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.鈥

鈥婩amily name should be recorded in the format preferred by the person. 鈥婽丑别&苍产蝉辫;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:鈥

  • 鈥媓ow 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

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鈥檚 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. 鈥

鈥婽丑别&苍产蝉辫;preferred name should be written as indicated by the person. 

Related data collection standards

鈥嬧

Note: Preferred name is not a separate standard maintained by the AIHW. It is included as part of their 鈥楪iven 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.鈥

鈥媁here required by agencies, aliases may be recorded with a 鈥榥ame usage type鈥 that describes the nature of/reason for the alias. (e.g. Previous name, Stage name). Refer to the data collection standards below.鈥

鈥婩or 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.鈥

鈥媁here 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 91短视频n Government data collection, we are treating it as a standalone standard and a separate data field.鈥

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鈥攆or example, in the case of HIV testing鈥攚here 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鈥檚 actual name. It is recommended that the subject be asked to record both the pseudonym (other name) as well as a legal name.鈥

鈥婻egistering 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.鈥

鈥媁here 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

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 鈥榩oint of collection鈥 and 鈥榮ex at birth鈥欌
A person鈥檚 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鈥檚 gender (which may not align with the sex assigned at birth) to be recognised in government records. 鈥

鈥婣sking 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.鈥

鈥婽he Australian Bureau of Statistics鈥(ABS 2020) recommends that:鈥

  • 鈥媤here 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. 鈥

鈥婽he 鈥楢nother term鈥 (please specify) option should provide a write-in field and be stored as a separate data field.

Related data collection standards

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鈥痮r 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. 鈥疉 person's gender may stay the same or can change over the course of their lifetime. 鈥

鈥婼ome people may not identify with a specific gender or with the concept of gender at all. The 鈥楧ifferent term鈥 (please specify) option should provide a write-in field and be stored as a separate data field.鈥

鈥婻esponses 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

鈥婱ore 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. 鈥楧ifferent term鈥 responses may be coded as 鈥楴on-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鈥檚 .鈥

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

鈥婭t uses a four-digit numbering scheme for countries. For example, Australia鈥檚 code is 鈥1101鈥 and New Zealand鈥檚 is 鈥1201鈥:鈥

鈥1 OCEANIA AND ANTARCTICA鈥

     11 Australia (includes External Territories)鈥

          1101 Australia鈥

          1102 Norfolk Island鈥

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

鈥婥ountry 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

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

罢别谤尘颈苍辞濒辞驳测鈥
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 91短视频.鈥

鈥婽he accepted term for this variable is Aboriginal Status. Abbreviated forms of 'Aboriginal and Torres Strait Islander' and 鈥楾orres Strait Islander鈥 (e.g. ATSI) should not be used.

Related data collection standards

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 .

鈥婽丑别&苍产蝉辫;ASCL is a hierarchical structure of languages organised into broad groupings. This allows for easy aggregation of languages into commonly understood groupings. 鈥

鈥婭t uses a four-digit numbering scheme for languages. For example, the code for 鈥楪aelic (Scotland)鈥 is 鈥1101鈥欌

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

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

鈥婣ll world languages are in scope of the classification and languages with significant numbers of speakers in Australia are separately identified within the classification structure.鈥

鈥婼pecial 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

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  has a three level hierarchical鈥痵tructure that consists of broad groups, narrow groups, and cultural and ethnic groups 鈥

鈥婨虫补尘辫濒别:鈥

鈥婤road group, 1 Oceanian
     Narrow group, 1 Australian Peoples 鈥
          Cultural and ethnic group, 1101 Australian 

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

鈥婣ncestry 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

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

鈥婽丑别&苍产蝉辫;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

鈥婸hase 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. 鈥婣gencies 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.鈥

鈥婦ates can be stored using a special form of notation to indicate the amount of inaccuracy they contain.鈥

鈥婬owever, the way to do this differs depending on whether the date is a date of birth or not. 鈥

鈥婣lignment 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 鈥榓mount鈥 of uncertainty using special characters.鈥

鈥 provides a summary of the draft ISO standard.鈥

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

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

鈥婭f 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

鈥婽he date, or date and time, of a generic event.

Format

Date YYYY-MM-DD鈥
Dates should be stored using the native 鈥榙ate鈥 data type of the data store.鈥

Date and time with time zone
Dates with times should be stored using the native 鈥榙atetime鈥 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.

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

Related data collection standards

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 鈥楧ate鈥 data type of databases.鈥

鈥婭f 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 鈥楧DMMYYYY鈥. 

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

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

鈥婩or 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

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

鈥婽he 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鈥

鈥婩or 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

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

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,鈥

鈥婸erson identifiers should follow these guiding principles:鈥

  • 鈥媢nique 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鈥檚 data assets鈥

鈥婽his 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

Version

2022.03
First version published

Have a question or want to report a problem?

Fill in the form to get assistance or tell us about a problem with this information or service.

Send feedback