METeOR business rules for online data
standard development
Version 6.0
Australian Institute of Health and Welfare
Canberra
The Australian Institute of Health and Welfare is a major national agency
which provides reliable, regular and relevant information and statistics
on Australia’s health and welfare. The Institute’s mission is
authoritative information and statistics to promote better health and wellbeing.
© Australian Institute of Health and Welfare 2013
This product, excluding the AIHW logo, Commonwealth Coat of Arms and any material owned by a
third party or protected by a trademark, has been released under a Creative Commons BY 3.0
(CC-BY 3.0) licence. Excluded material owned by third parties may include, for example, design and
layout, images obtained under licence from third parties and signatures. We have made all reasonable
efforts to identify and label material owned by third parties.
You may distribute, remix and build upon this work. However, you must attribute the AIHW as the
copyright holder of the work in compliance with our attribution policy available at
<www.aihw.gov.au/copyright/>. The full terms and conditions of this licence are available at
<http://creativecommons.org/licenses/by/3.0/au/>.
Enquiries relating to copyright should be addressed to the Head of the Communications, Media and
Marketing Unit, Australian Institute of Health and Welfare, GPO Box 570, Canberra ACT 2601.
Australian Institute of Health and Welfare
Board Chair
Dr Andrew Refshauge
Director
David Kalisch
Any enquiries about or comments on this publication should be directed to:
Communications, Media and Marketing Unit
Australian Institute of Health and Welfare
GPO Box 570
Canberra ACT 2601
Tel: (02) 6244 1032
Email: [email protected]
Published by the Australian Institute of Health and Welfare
Please note that there is the potential for minor revisions of data in this report.
Please check the online version at <www.aihw.gov.au> for any amendments.
Contents
Abbreviations ..................................................................................................................................... vii
1
Introduction....................................................................................................................................1
1.1 Purpose of this document ......................................................................................................1
1.2 Structure of this document ....................................................................................................1
1.3 Terminology.............................................................................................................................1
1.4 Introduction to METeOR structures .....................................................................................2
1.5 How to obtain assistance or provide feedback on these business rules ..........................3
2
General conventions .....................................................................................................................4
2.1 Formatting................................................................................................................................4
2.2 Sector-specific information ....................................................................................................8
2.3 Versioning within METeOR ..................................................................................................8
3
Common metadata attributes ......................................................................................................9
3.1 Identifying and definitional attributes .................................................................................9
3.2 Collection and usage attributes ...........................................................................................25
3.3 Source and reference attributes ...........................................................................................26
3.4 Related metadata...................................................................................................................28
3.5 Registry management attributes .........................................................................................29
4
Attributes specific to object classes .........................................................................................32
4.1 Specialisation of.....................................................................................................................32
4.2 Data element concepts implementing this object class ....................................................32
5
Attributes specific to properties ...............................................................................................33
5.1 Property group ......................................................................................................................33
5.2 Data element concepts implementing this property ........................................................33
6
Attributes specific to data element concepts..........................................................................34
6.1 Object class .............................................................................................................................34
6.2 Property ..................................................................................................................................35
6.3 Data elements including this data element concept.........................................................36
7
Attributes specific to data elements ........................................................................................37
7.1 Short name .............................................................................................................................37
7.2 Data element concept ...........................................................................................................37
7.3 Value domain ........................................................................................................................37
7.4 Implementation in data set specifications .........................................................................38
iii
7.5 Non dictionary data element ...............................................................................................38
8
Attributes specific to value domains .......................................................................................39
8.1 Classification scheme............................................................................................................39
8.2 Representation class..............................................................................................................39
8.3 Data type ................................................................................................................................40
8.4 Format .....................................................................................................................................41
8.5 Maximum character length..................................................................................................42
8.6 Permissible values.................................................................................................................42
8.7 Supplementary values ..........................................................................................................43
8.8 Unit of measure .....................................................................................................................43
8.9 Proposed unit of measure ....................................................................................................45
9
Attributes specific to classification schemes .........................................................................47
9.1 Classification structure .........................................................................................................47
9.2 Revision status .......................................................................................................................47
9.3 Value domains based on this classification scheme .........................................................47
10 Attributes specific to data set specifications ..........................................................................48
10.1 Data set specification type ..................................................................................................48
10.2 Scope ......................................................................................................................................48
10.3 Metadata items in this data set specification ...................................................................49
10.4 Sequence number .................................................................................................................49
10.5 Obligation..............................................................................................................................49
10.6 Maximum occurrences ........................................................................................................50
10.7 Conditional obligation.........................................................................................................50
10.8 Information specific to this data set...................................................................................50
10.9 Statistical unit .......................................................................................................................51
10.10 Implementation start date .................................................................................................51
10.11 Implementation end date ..................................................................................................52
11 Attributes specific to indicator sets .........................................................................................53
11.1 Indicator set type ..................................................................................................................53
11.2 Outcome areas linked to this indicator set .......................................................................54
11.3 Indicators linked to this indicator set ................................................................................55
12 Attributes specific to outcome areas ........................................................................................56
12.1 Indicator sets linked to this outcome area ........................................................................56
12.2 Indicators linked to this outcome area ..............................................................................56
iv
13 Attributes specific to indicators ...............................................................................................57
13.1 Indicator Type.......................................................................................................................57
13.2 Common name .....................................................................................................................57
13.3 Description ............................................................................................................................57
13.4 Rationale ................................................................................................................................58
13.5 Indicator set ...........................................................................................................................58
13.6 Outcome area ........................................................................................................................58
13.7 Population group age from .................................................................................................58
13.8 Population group age to ......................................................................................................58
13.9 Computation description ....................................................................................................59
13.10 Computation .......................................................................................................................59
13.11 Numerator ...........................................................................................................................59
13.12 Numerator data items........................................................................................................59
13.13 Denominator .......................................................................................................................59
13.14 Denominator items.............................................................................................................60
13.15 Disaggregation ....................................................................................................................60
13.16 Disaggregation items .........................................................................................................60
13.17 Data element/Data set.......................................................................................................60
13.18 Data source ..........................................................................................................................61
13.19 NMDS/DSS .........................................................................................................................61
13.20 Collection Methods/Guide for use ..................................................................................61
13.21 Performance framework and dimensions ......................................................................61
13.22 Methodology .......................................................................................................................61
13.23 Formulae ..............................................................................................................................62
13.24 Reporting requirements ....................................................................................................62
13.25 Organisation responsible for providing data .................................................................62
13.26 Accountability.....................................................................................................................62
13.27 Benchmark...........................................................................................................................62
13.28 International comparisons ................................................................................................63
13.29 Further data development/collection required .............................................................63
13.30 Other issues caveats ...........................................................................................................63
13.31 Release date .........................................................................................................................63
14 Attributes specific to frameworks ............................................................................................64
14.1 Dimension of Framework (whether broad level or sub-dimension). ...........................64
v
14.2 Indicators in this framework ..............................................................................................64
15 Attributes specific to quality statements ................................................................................65
15.1 Quality statement summary ...............................................................................................65
15.2 Institutional environment ...................................................................................................65
15.3 Timeliness ..............................................................................................................................65
15.4 Accessibility ..........................................................................................................................65
15.5 Interpretability ......................................................................................................................66
15.6 Relevance ...............................................................................................................................66
15.7 Accuracy ................................................................................................................................66
15.8 Coherence ..............................................................................................................................66
16 Attributes specific to data sources ...........................................................................................67
16.1 Link to data source ...............................................................................................................67
16.2 Frequency ..............................................................................................................................67
16.3 Data custodian ......................................................................................................................67
16.4 Data custodian contact details ............................................................................................67
17 Notes ..............................................................................................................................................68
17.1 Notes ......................................................................................................................................68
18 Attributes specific to object class specialisations .................................................................69
18.1 Name of object class specialisation ....................................................................................69
18.2 Description of object class specialisation ..........................................................................69
18.3 Parent .....................................................................................................................................69
18.4 Children .................................................................................................................................70
19 Attributes specific to property groups ....................................................................................71
19.1 Name of property group .....................................................................................................71
19.2 Description of property group ...........................................................................................71
19.3 List of properties ..................................................................................................................71
20 Referencing guidelines ..............................................................................................................72
20.1 In-text references ..................................................................................................................72
20.2 Reference list .........................................................................................................................72
Appendix 1: Format examples ..........................................................................................................75
21 Appendix 2....................................................................................................................................77
References ............................................................................................................................................80
List of tables ........................................................................................................................................81
vi
Abbreviations
ABS
Australian Bureau of Statistics
AIHW
Australian Institute of Health and Welfare
FaHCSIA
Department of Families, Housing, Community Services and Indigenous
Affairs
METeOR
Metadata electronic online registry
ISO/IEC 11179
International Standardization Organisation 11179
ICD-10-AM 6th
edn
International Statistical Classification of Diseases and Related Health
Problems, Tenth Revision, Australian Modification 6th edition
NPDC
National Perinatal Data Collection
SDAC
Survey of Disability and Carers
DVA
Department of Veteran Affairs
WHO
World Health Organization
WYSIWYG
What You See Is What You Get
NCCS V. 20
National Classification of Community Services Version 2.0
NANDA
North American Diagnosis Association
DSS
Data Set Specification
vii
1
Introduction
1.1 Purpose of this document
METeOR Business Rules for Metadata Development, Version 5.0 specifies the rules with which
metadata developers should comply when creating metadata within the Metadata Online
Registry (METeOR).
This document has evolved over time as the business rules are refined to meet the
increasingly sophisticated requirements of users and the Registration authorities. For this
reason, readers are encouraged to refer to <http://meteor.aihw.gov.au> for the latest
version of this publication.
This document also forms the basis of the online help provided within METeOR. This help
can be accessed by clicking on the information icons ( ) located throughout the site or via the
Help tab on the top navigation bar.
1.2 Structure of this document

Chapter 1 provides a brief overview of this document, including its purpose,
structure and introduces the basic metadata structures.

Chapter 2 outlines the conventions for attributes which are common across most
types of metadata.

Chapters 3 to 16 outline the conventions which apply for attributes which are specific
to particular types of metadata.

Chapter 17 presents information on the conventions used when adding reviewer
notes to a metadata item.

Chapters 18 to 19 detail specific conventions which apply when creating or editing
the two navigational structures managed by the Registrar.

Chapter 20 specifies the referencing guidelines which apply when referencing within
a metadata item.

Appendix 1 includes examples of correct ways of completing the format attribute for
value domains.

Appendix 2 includes a description of data element clusters and examples of how they
have been used in METeOR.
1.3 Terminology
A distinction is made in this document between metadata and data standards. The term
metadata is used to refer to any content within a METeOR metadata structure (e.g. object
class, data element, classification scheme etc) that has been used to describe some aspect of
data. The term data standard is applied to any metadata that has undergone the national
endorsement process.
METeOR business rules for online data standard development Version 6.0
1
1.4 Introduction to METeOR structures
1.4.1 ISO 11179 structures
The metadata structures used within METeOR are based on the international standard for
metadata registries ISO/IEC 11179. METeOR implements the ISO/IEC 11179 model of object
classes, properties, data element concepts, data elements and value domains.
Within METeOR the metadata structures are used for the following purposes:
A. Object class: The person, place, event or thing that is being described.
B. Property: The characteristic of the object that is of interest.
C. Data element concept: A concept that can be represented in the form of a data
element, described independently of any particular representation. In METeOR this is
achieved by the union of an object class and a property
D. Data element: A unit of data for which the definition, identification, representation
and permissible values are specified by means of a set of attributes. In METeOR this
is achieved by the union of a data element concept (definition and identification) and
a value domain (representation and permissible values).
E. Value domain: An implied and/or explicit set of values used to represent
something/someone.
F. Classification scheme: A system for classifying data which is recognised and
endorsed by a national or international body.
G. Glossary item: A term with a defined meaning that applies across all instances within
a specified context.
H. Data set specification: A grouping of data elements and/or data set specifications,
and the conditions under which the grouping should be collected or reported.
The above structures are supplemented by two navigational structures which are managed
by the Registrar:
A.
Object class specialisation: These allow the building of a hierarchy of object
classes based on sub-typing (e.g. Adult is a sub-type of Person).
B.
Property group: A system for grouping properties with similar
characteristics.
2
METeOR business rules for online data standard development Version 5.0
1.4.2 Non 11179 structures
The following structures support metadata for indicators and link to metadata structures
developed in METeOR that implement the ISO/IEC 11179 model.
A.
Indicator set: A single or multi-word designation assigned to a set of
performance indicators. This appears in the heading for each performance
indicator.
B.
Outcome area: A statement that specifically defines the target, standard or the
ideal result of the performance indicator, against which performance is to be
assessed. Outcomes should be strategic, high level and observable, expressed in
clear, measurable and achievable terms. Several outcome areas may be identified
for each objective.
C.
Indicator: A statistical measure used to describe the progress or performance of a
system. The measure may be that of a population or the output of provision of
goods and services.
D.
Framework: The name of the conceptual framework to which a performance
indicator can be reported against. This may include tiers and dimensions and
sub-dimensions. A conceptual framework provides a structure to guide the
understanding and evaluation of the system (health/welfare) being investigated.
E.
Quality statement: A statement of multiple quality dimensions for the purpose of
assessing the quality of the data for reporting against the performance indicator.
F.
Data source: A specific data set, database and reference from where data are
sourced.
1.5 How to obtain assistance or provide feedback
on these business rules
The business rules were designed to support developers in the creation of quality metadata
items and data standards. Should you require additional assistance or have feedback on how
the rules could be improved, please contact the AIHW’s Metadata Infrastructure Services
Unit on (02) 6244 1222 or [email protected].
METeOR business rules for online data standard development Version 6.0
3
2
General conventions
There are conventions which apply across all the METeOR metadata item types and
attributes of these items (e.g. name and definition).
2.1 Formatting
METeOR allows the selection of multiple metadata items for downloading into a single
custom-made document. This means metadata created in METeOR must be formatted
consistently to ensure a coherent presentation. The formatting rules presented in this section
are based on the AIHW publication style guides that are used to format the hard-copy
national data dictionaries.
Text in metadata items is created in either one of two ways; typing directly into a plain text
field or using a What you see is what you get (WYSIWYG) editor. While the formatting
options for plain text fields are tightly constrained, the WYSIWYG editor provides many
style and formatting options as well as buttons similar to those available in Word. For this
reason, most of the formatting rules documented below relate to options available in
WYSIWYG editors.
2.1.1 Language and spelling
2.1.1.1 Language
A.
Use Australian English unless referring to an organisation which applies another
language in its formal title or when referring to a ‘foetus’. In these cases, state the
formal organisation title e.g. World Health Organization, and use the US spelling
‘fetus’.
2.1.1.2 Abbreviation
A.
Express the first occurrence of an abbreviation within each metadata item by spelling
out the word or phrase in full and enclosing the abbreviation within parentheses
immediately to the right of this word. For example, The International Statistical
Classification of Diseases and Related Health Problems, Tenth Revision, Australian
Modification, 6th edition (ICD-10-AM 6th edn). This rule does not apply to the
abbreviated classification scheme name included in value domain and data element
names.
2.1.1.3 Capitalisation
A.
Use minimal capitalisation unless referring to a metadata item, publication or
organisation. For example, the term non-admitted patient service event should only
be capitalised when the object class Non-admitted Patient Service Event is being
referenced. A term may be italicised for emphasis.
B.
Capitalise the first letter of the first word of all words within the name of a
publication or organisation e.g. National Heart Foundation
2.1.1.4 Tense
A.
Nouns should be expressed in singular form unless the term itself is plural in nature.
4
METeOR business rules for online data standard development Version 5.0
2.1.2 Textual contrast
2.1.2.1 Style
A.
Use the normal style for the body of metadata items, except for addresses (in this
case, use the address style).
B.
The address style is to be used for the addresses of organisations, within the
Registrar-only viewable attributes submitting organisation contact details and
steward organisation contact details only.
C.
Heading styles are not recommended within the body of a metadata item.
2.1.2.2 Font type and size
A.
Selecting a font or font size other than the default for a given style is not
recommended within the body of a metadata item.
2.1.2.3 Bold text
A.
Bold text is not recommended within the body of a metadata item except for within a
table or caption.
2.1.2.4 Italic text
A.
Italicise the titles of: publications, legislation, legal cases, and terms to which
emphasis is being applied. For example, the Style Manual recommends that the
Western Australian Young Offenders Act 1994 is italicised. This rule does not apply
to the attributes Reference documents and Origin: format references within these
attributes in plain text.
2.1.2.5 Underline text
A.
Underline text is not recommended within the body of a metadata item except for
within a hyperlink where it is applied by default when the hyperlink reference is
created.
2.1.2.6 Strike through text
A.
Strike through text is not recommended within the body of a metadata item.
2.1.2.7 Heading
A.
Format headings within metadata items using the normal style and ending in a colon
e.g. Health care services:
B.
A heading must not end in a full stop.
C.
Press the Enter button on your keyboard after a heading.
2.1.2.8 List
A.
Two types of lists are permitted: numbered lists and bulleted lists. Numbered lists
should only be used when it is necessary to indicate priority, the chronological flow
of the series, or where individual items may be required to be identified for later
reference.
METeOR business rules for online data standard development Version 6.0
5
B.
Introduce each series of dot points with a full sentence or sentence fragment. For
example: ‘To ensure the validity of test findings:’
C.
To begin a list, press the Enter button on your keyboard after the introductory
sentence, then press the numbered or bulleted list button within METeOR.
D.
Capitalise the first item within a list if each item is a full sentence.
E.
Use a full stop only at the end of list items which are full sentences, and at the end of
the last item within the series.
2.1.3 Numbers and special characters
2.1.3.1 Numbers
A.
Express a number with a value of less than one and a precision of at least one decimal
place by placing a zero to the left of the decimal point e.g. 0.5.
2.1.3.2 Formulae, symbols and other special characters
A.
Insert symbols using the ‘Insert symbol’ button.
B.
Use the symbol ≤ to denote less than or equal to e.g. A≤B.
C.
Use the symbol ≥ to denote greater than or equal to e.g. A≥B.
D.
Underline the top row of an equation. On the next line, type in the dominator e.g.
A
B
E.
Separate units of measure within a ratio and the components of a fraction or date
with a slash e.g. 60 miles/hour, 4 1/2 centimetres, 26/12/2004.
F.
Express alternatives and compound terms using a slash where required e.g.
January/February (not January and/or February), 2008/2009 (not 2008 to 2009).
G.
Immediately precede and follow a slash with the word, phrase or number being
referred to e.g. state/territory.
2.1.4 Paragraph and alignment
2.1.4.1 Paragraph
A.
Press the Enter button on your keyboard to begin a new paragraph.
B.
Do not indent the first line of a paragraph.
2.1.4.2 Alignment
A.
Right or centre text alignment is not recommended within the body of a metadata
item.
2.1.4.3 Horizontal rule
A.
A horizontal rule is not recommended within the body of a metadata item.
6
METeOR business rules for online data standard development Version 5.0
2.1.5 Copying and pasting text from another application
2.1.5.1 Into the WYSIWYG editor
A.
When pasting any text into METeOR’s WYSIWYG editor, use the ‘Paste without
formatting’ button or a <Ctrl> V keyboard command. Text will be inserted without
any style formatting. This will need to be applied after text insertion in accordance
with METeOR style rules.
B.
When pasting a table into METeOR’s WYSIWYG editor, copy the table from its
original source and insert using the <Ctrl> V keyboard command. The inserted table
will be stripped of all style formatting. This formatting will need to be applied after
the table insertion in accordance with METeOR style rules.
2.1.5.2 Into other fields
A.
Use <Ctrl> V to paste into plain text fields.
2.1.6 Tables and figures
A.
Insert a table using the ‘Insert Table’ button.
B.
Insert a figure using the ‘Insert Image’ button.
C.
Place a caption below each figure.
D.
Place a caption above each table.
E.
Format captions using Normal style, font size 2, bold.
F.
Capitalise the first word within a caption and proper nouns only.
G.
A table of contents is not recommended within the body of a metadata item.
2.1.7 Reference
A.
Format all references to METeOR metadata items (i.e. object classes, properties, data
element concepts, data elements, value domains, classification schemes, data set
specifications, indicator sets, outcome areas, indicators, frameworks, data sources and
quality statements) using the ‘Insert hyperlink to content’ button, formatted with
italics and with an initial capital letter (this will result in blue text) e.g. Person—date
of birth. Note: the content browser used to create this link is not optimised for
browsing for metadata items and can take a while to build a relevant item list. Best
results are achieved by selecting the metadata item type required from drop-down
list and then using the search facility to find the item.
B.
Format all references to METeOR glossary items using the ‘Insert reference to a
glossary item’ button.
C.
Format references to Web pages outside of METeOR using the ‘Insert hyperlink’
button.
D.
To remove or update one of these references (to another metadata item, to a glossary
item or to an external webpage), you will need to first remove the existing link. This
is done by highlighting the relevant text and using the ‘Remove formatting’ button.
METeOR business rules for online data standard development Version 6.0
7
E.
In-text references to other material should only be used when deemed necessary to
attribute one or more statements to its source and where such statements support,
rather than constitute, metadata content. For example, justification for assessment
criteria. Format such statements as outlined in Chapter 14 of this document. In all
other instances, provide a full reference to source/support material in either the
Origin or Reference documents attribute.
F.
Enclose quotations within single, rather than double, quotation marks.
2.2 Sector-specific information
A.
Where items are approved by more than one registration authority and contain
information specific to one or more sector, this information should appear under a
heading stating the sector(s) to which the information is specific. For example,
Health-specific:, Community services-specific:, or Housing assistance-specific:.
2.3 Versioning within METeOR
A.
The METeOR identifier, Metadata item name and Registration status attributes are
used to identify a metadata item and its status within the registration process.
Version numbers are not permitted within metadata items.
B.
A Metadata item name should be unique within METeOR for a given Registration
status value. For example there should not be two object classes called Client with a
registration status of Standard. However, there may be two object classes called
Client, one with a registration status of Standard, and another of Proposed (which
may eventually supersede the first).
C.
Once a metadata item reaches a registration status of Standardisation pending it
cannot be edited by a Developer. A new metadata item must be created if the item is
to be changed after this point. Once a metadata item (which is intended to supersede
another) reaches a registration status of Standard, it will be assigned a Supersedes
relationship to any item which it is approved to have replaced.
D.
Where a metadata item has reached a registration status of Standardisation pending
for one registration authority and is Proposed to a second registration authority, the
metadata item may only undergo minor edits which are acceptable to the first
registration authority.
2.3.1 Registrar-specific guidance
A.
A metadata item with a registration status of Standardisation pending, Standard,
Retired and Superseded may be edited to fix grammar and spelling mistakes within
all attributes or to change the wording of all attributes other than Name, Definition,
Permissible values, or Supplementary values.
8
METeOR business rules for online data standard development Version 5.0
3
Common metadata attributes
The following business rules apply to all METeOR metadata item types: object classes,
properties, data element concepts, value domains, data elements, classification schemes,
glossary items, data set specifications, indicator sets, outcome areas, indicators, quality
statements, frameworks and data sources unless stated otherwise.
For each attribute, a definition, obligation for completion, and the type of user which may
complete and view the attribute are specified. The Obligation for completion is an indication
of whether: a value for the attribute must be completed (mandatory), is mandatory under
specific conditions only (conditional) or which may or may not be completed (optional).
3.1 Identifying and definitional attributes
These attributes provide information that identifies the metadata items and specifies its
definitional characteristics.
3.1.1 Metadata item name
Definition:
A single or multi-word designation assigned to a metadata item.
Obligation:
Mandatory completion.
Creator:
Developer. METeOR can suggest names for data elements and data element
concepts.
Visibility:
All users.
3.1.1.1 Rules common to all metadata items
The business rules applicable to the name attribute for all metadata item types are presented
below. These business rules are organised into three categories; lexical, syntactic, and
semantic. Lexical rules determine the individual components which may comprise a name.
Syntactic rules determine the arrangement of name components. Semantic rules determine
the meaning of the name.
3.1.1.1.1
Lexical rules determining individual name components
A.
Quotation marks are not permitted.
B.
Colons (:) are only permitted to be used in indicator names.
C.
Slashes (/) are permitted.
3.1.1.1.2
Syntactic rules determining the arrangement of name components
A.
Hyphens (-) should only be used when two or more words are turned into a single
compound word. Do not leave any spaces before or after the hyphen. For example,
‘on-call’, ‘waist-to-hip ratio’.
3.1.1.1.3
Semantic rules determining the meaning of name components
A.
The name should be indicative of the content of that metadata item.
B.
Where possible, the name should be concise.
METeOR business rules for online data standard development Version 6.0
9
3.1.1.2 Rules specific to object classes
3.1.1.2.1
Lexical rules determining individual name components
A.
Capital letters should only be used for the first letter of the first word and proper
nouns.
B.
The term ‘event’ should only be used within event-based metadata item names which
require clarification that the metadata item refers to an event, rather than a physical
entity. For example, the name ‘Injury event’ signifies that the object class refers to the
event in which an injury occurred, not the injury itself.
C.
Commas are not permitted.
D.
Full stops are not permitted.
E.
Parentheses are not permitted.
F.
Square brackets are not permitted.
G.
Qualifier terms are not permitted.
3.1.1.2.2
Syntactic rules determining the arrangement of name components
No rules defined.
3.1.1.2.3
Semantic rules determining the meaning of name components
No rules defined.
3.1.1.3 Rules specific to properties
3.1.1.3.1
Lexical rules determining individual name components
A.
Capital letters should only be used in the first letter of the first word and proper
nouns.
B.
Commas are not permitted.
C.
Full stops are not permitted.
D.
Parentheses are not permitted.
E.
Square brackets are not permitted.
F.
Qualifier terms are not permitted.
3.1.1.3.2
Syntactic rules determining the arrangement of name components
No rules defined.
3.1.1.3.3
A.
Semantic rules determining the meaning of name components
There are circumstances where a property name is required to reflect the categorical
nature of the characteristic under study. In these cases, it is recommended that
metadata developers represent the:
i.
method by which a process is completed with the terms mode or method;
ii.
current state of an object with the term status;
iii.
general characteristic of an object with the terms type or category.
10
METeOR business rules for online data standard development Version 5.0
B.
For properties which are not specific to one object class, do not embed the name of the
object class within the property name e.g. Episode start date can be used for many
types of episodes.
3.1.1.4 Rules specific to data element concepts
3.1.1.4.1
Lexical rules determining individual name components
A.
A data element concept name is composed of the following:
Object class
name
+ Em
dash
+
Property
name
For example, the concatenation of the object class Person and the property Body
height is: Person—body height.
B.
The object class and property name components of the data element concept name are
to be written exactly and in full (i.e. repetitive text should not be removed).
C.
The first word of the property name component of the data element concept name
should be written in lower case unless it is a proper noun.
D.
Capital letters should only be used for the first letter of the first word and proper
nouns.
E.
Full stops are not permitted.
F.
Square brackets are not permitted.
3.1.1.4.2
Syntactic rules determining the arrangement of name components
A.
The object class name shall occupy the leftmost position.
B.
The property name shall follow the object class name.
C.
Separate the object class name component of the data element concept name with an
Em dash (—). Do not leave any spaces before or after the Em dash e.g. Person—body
height.
3.1.1.5 Rules specific to data elements
3.1.1.5.1
Lexical rules determining individual name components
A.
A data element name is composed of the following:
Data element
concept name
+comma
+space+
Value domain
name
For example, the concatenation of the data element concept Person—body height and
the value domain Total centimetres NN[N].N is: Person—body height, total
centimetres NN[N].N.
B.
Capital letters should only be used for the first letter of the object class name, proper
nouns and within the value domain name component.
METeOR business rules for online data standard development Version 6.0
11
C.
Commas should only be used to separate the data element concept name from the
value domain name.
D.
Full stops should only be used within the format term component of the value
domain name.
E.
Parentheses should only be used to enclose the format term and classification scheme
components of the value domain name.
F.
Square and curly brackets (braces) should only be used within the format term
component of the value domain name.
3.1.1.5.2
Syntactic rules determining the arrangement of name components
A.
The data element concept name, shall occupy the leftmost position.
B.
The value domain name shall follow the data element concept name.
C.
If any word in the union of the data element concept name and value domain name is
made redundant either explicitly through the duplication of a word, or implicitly
through another word or phrase, delete the redundant part within the value domain
name component. For example, the union of the data element concept Person—sex
and value domain Sex code N is Person—sex, code N. For data elements of all
representation classes other than date and time, the representation class term
component of the value domain name must not be deleted.
3.1.1.6 Rules specific to value domains
3.1.1.6.1
Lexical rules determining individual name components
A.
A value domain name is composed of the following:
For example, a value domain which implements the ICD-10-AM (6th edition) external
cause of injury chapter (a format of ANN{.N[N]}) may be named: External cause of
injury code (ICD-10-AM 6th edition) ANN{.N[N]}.
B.
Capital letters should only be used for the first letter of the first word of the value
domain name, proper nouns and within the classification scheme and format terms.
C.
Full stops should only be used within the format term.
D.
Parentheses should only be used to enclose the classification scheme term and within
the format term.
E.
Square and curly brackets (braces) should only be used within the format term.
3.1.1.6.2
Syntactic rules determining the arrangement of name components
A.
A value title shall occupy the leftmost position of a value domain name where it is
necessary to distinguish the value domain name from other metadata items.
B.
The representation class term shall follow the value title.
12
METeOR business rules for online data standard development Version 5.0
C.
The representation class term is qualified by the classification scheme term where the
value domain implements a classification scheme.
D.
The unit of measure term shall follow where the value domain is of representation
class average or total and this unit of measure is not implied by any other name
component.
E.
The format term shall occupy the rightmost position of a value domain name.
F.
If any term in the value domain name is made redundant either explicitly through the
duplication of a word, or implicitly through another word or phrase, delete one
occurrence.
3.1.1.6.3
Semantic rules determining the meaning of name components
A.
Express the value title component in a concise manner.
B.
The representational class term must reflect the value stored in the representational
class attribute.
C.
The classification scheme term must reflect the classification scheme synonymous
name attribute.
D.
The unit of measure term must reflect the unit of measure attribute.
E.
The format term must reflect the value stored in the format attribute.
3.1.1.7 Rules specific to classification schemes
A.
State the full and formal name of the classification scheme e.g. International Statistical
Classification of Diseases and Related Health Problems, Tenth Revision, Australian
Modification.
B.
A classification scheme name should not begin with the word The e.g. Australian
Standard Drug of Concern 2000, not The Australian Standard Drug of Concern 2000.
C.
If the classification scheme has an edition or version number, insert the edition or
version number and the suffix edition or version. For example: International
Statistical Classification of Diseases and Related Health Problems, Tenth Revision,
Australian Modification 6th edition.
D.
If the classification scheme is not associated with an edition or version number, insert
the year of publication after the name e.g. Australian Standard Classification of
Education 2001.
3.1.1.8 Rules specific to glossary items
A.
There may be more than one glossary item with the same name within the glossary, if
required by contextual differences.
B.
When this occurs, ensure that the Context attribute in each identically named
Glossary item is different.
3.1.1.9 Rules specific to indicators
3.1.1.9.1
A.
Lexical rules determining individual name components
An indicator technical name is composed of the following:
METeOR business rules for online data standard development Version 6.0
13
For example an indicator may be named National Health Agreement: 2011, P1Proportion of low birth weight babies, 2010.
B.
Capital letter should only be used for each first letter of the Indicator set name, the ‘P’
or ‘O’ denoting the indicator number, and the first letter of the formal indicator name.
C.
Commas should only be used to separate the year the indicator set was last updated
from the Indicator reference number; and the Indicator name from the year the
indicator was last updated.
D.
A hyphen should only be used to separate the Indicator reference number and the
indicator name.
E.
A colon should only be used to separate Indicator set name and the year the indicator
set was last updated.
F.
Full stops are not permitted unless they are a part of the formal Indicator set name or
the formal indicator name as specified by the responsible auspice body.
G.
Emdashes are not permitted unless they are a part of the formal Indicator set name or
the formal indicator name as specified by the responsible auspice body.
H.
Parentheses are not permitted unless they are a part of the formal Indicator set name
or the formal indicator name as specified by the responsible auspice body.
I.
Square and curly brackets (braces) are not permitted unless they are a part of the
formal Indicator set name or the formal indicator name as specified by the
responsible auspice body.
3.1.1.9.2
Syntactic rules determining the arrangement of name components
A.
The indicator set shall occupy the leftmost position of an indicator name.
B.
The indicator set should be followed by a colon and then a space.
C.
The space shall be followed by the year the indicator set was last updated.
D.
The year the indicator set was last updated shall be followed by a comma and a
space.
E.
The space shall be followed by the indicator reference number.
F.
The indicator reference number shall be followed by an hyphen and the complete and
formal name of the Indicator as specified by the responsible auspice body.
G.
The indicator name shall be followed by a comma and a space.
H.
The year the Indicator was last updated shall occupy the rightmost position of the
Indicator technical name.
14
METeOR business rules for online data standard development Version 5.0
3.1.1.10
Rules specific to outcome areas
A.
An outcome area name is composed solely of the formal name specified by the
responsible auspice body. For example: Prevention; Prevention: Children are born
and remain healthy; Primary and community health; Sustainability; and Social
inclusion and Indigenous health.
B.
State the full and formal name of the outcome area, as specified by the auspice body
responsible for defining the indicators, for example ‘Prevention’, or ‘Primary and
community health’.
C.
A capital letter may be used for the first letter of the first word and proper nouns.
Wherein the name is separated by a colon such as in ‘Prevention: Children are born
and remain healthy’, the first word in the second portion may also start with a capital
letter.
D.
Commas are not permitted unless they are a part of the formal Outcome area name as
specified by the responsible auspice body.
E.
Emdashes are not permitted unless they are a part of the formal Outcome area name
as specified by the responsible auspice body.
F.
Colons are not permitted unless they are a part of the formal Outcome area name as
specified by the responsible auspice body.
G.
Full stops are not permitted unless they are a part of the formal Outcome area name
as specified by the responsible auspice body.
H.
Parentheses are not permitted unless they are a part of the formal Outcome area
name as specified by the responsible auspice body.
I.
Square and curly brackets (braces) are not permitted unless they are a part of the
formal Outcome area name as specified by the responsible auspice body.
3.1.1.11
Rules specific to indicator sets
Indicator set names, for example the ‘National Health Agreement’ are specified by the
auspice body responsible for defining the Indicators.
3.1.1.11.1 Lexical rules determining individual name components
A.
The indicator sets are composed of the following components:
For example: National Healthcare Agreement: 2010.
METeOR business rules for online data standard development Version 6.0
15
B.
State the full and formal name of the agreement, for example the ‘National Healthcare
Agreement’, as specified by the auspice body responsible for defining the Indicators.
C.
Capital letters may be used for the first letter of each word in the Indicator set name.
D.
The year the agreement was instituted should be included in the Indicator set name,
for example, National Healthcare Agreement: 2010.
3.1.1.11.2 Syntactic rules determining the arrangement of name components
A.
The name of the Indicator set shall occupy the leftmost component of the name, and
be followed by a colon and a space.
B.
The year the Indicator set was last updated shall occupy the rightmost component of
the name.
3.1.1.12
Rules specific to frameworks
A.
A concise statement that expresses the facet in which an indicator is grouped.
B.
A framework name is composed solely of the formal name specified by the
responsible auspice body. For example: ‘National Health Performance Framework’,
or ‘ISO Health Conceptual Indicators’.
C.
State the full and formal name of the Framework dimension, as specified by the
auspice body responsible for defining the Frameworks. The lowest level dimension
which is relevant to the Indicator should be selected – for example ‘National Health
Performance Framework is the broadest level dimension (grandparent), followed by
‘Domain 1 – Health status’ at the mid level dimension (parent), and ‘Wellbeing’ is the
lowest level dimension (child).
D.
A capital letter may be used for the first letter of the first word of each word for the
Framework name. A capital letter may be used for the first word and proper nouns
for the lower level dimensions. Wherein the name is separated by an emdash or
hyphen such as in ‘Domain 1 – Health status’, the first word in the second portion
may also start with a capital letter.
E.
Commas are not permitted unless they are a part of the formal Framework name as
specified by the responsible auspice body.
F.
Emdashes are not permitted unless they are a part of the formal Framework name as
specified by the responsible auspice body.
G.
Colons are not permitted unless they are a part of the formal Framework name as
specified by the responsible auspice body.
H.
Full stops are not permitted unless they are a part of the formal Framework name as
specified by the responsible auspice body.
I.
Parentheses are not permitted unless they are a part of the formal Framework name
as specified by the responsible auspice body.
J.
Square and curly brackets (braces) are not permitted unless they are a part of the
formal Framework name as specified by the responsible auspice body.
16
METeOR business rules for online data standard development Version 5.0
3.1.1.13
Rules specific to quality statement for indicators
A statement of multiple quality dimensions for the purpose of assessing the quality of the
data for reporting against an Indicator. For the purposes of the suite of Indicator templates,
there are two types of quality statements – i) quality statements linked to an Indicator, and ii)
quality statements linked to a data source.
3.1.1.13.1
Lexical rules determining individual name components
A.
The indicator sets are composed of the following components:
For example: National Healthcare Agreement: P1-Babies born with low birth weight,
2010; Quality statement.
B.
Capital letters should be used for each first letter of the first letter of the Indicator set
name, the ‘P’ or ‘O’ denoting the indicator reference number, the first letter of the
formal indicator name, and the word ‘Quality’ denoting the metadata item is a
quality statement.
C.
A colon should only be used to separate Indicator set name and indicator reference
number.
D.
Commas should only be used to separate the year the indicator was last updated.
E.
Semi-colons should only be used to separate the year the indicator was last updated
and the suffix phrase ‘Quality statement’.
F.
An hyphen should only be used to separate the Indicator reference number and the
indicator name.
G.
Emdashes are not permitted unless they are a part of the formal Framework indicator
name as specified by the responsible auspice body.
H.
Full stops are not permitted unless they are a part of the formal Indicator set name or
the formal indicator name as specified by the responsible auspice body.
I.
Parentheses are not permitted unless they are a part of the formal Indicator set name
or the formal indicator name as specified by the responsible auspice body.
J.
Square and curly brackets (braces) are not permitted unless they are a part of the
formal Indicator set name or the formal indicator name as specified by the
responsible auspice body.
METeOR business rules for online data standard development Version 6.0
17
3.1.1.13.2 Semantic rules determining the meaning of name components
A.
The name of the Agreement/Indicator set should occupy the leftmost component of
the technical name, followed by a colon and a space.
B.
The space shall be followed by the Indicator reference number.
C.
A hyphen should separate the Indicator reference number and the indicator name.
D.
The indicator name should be followed by a comma, a space and the year the
indicator was last updated.
E.
The year the indicator was last updated should be followed by a semi colon, and then
a space.
F.
The phrase ‘Quality statement’ should occupy the rightmost component of the name.
The suffix of Quality statement, as opposed to the prefix means that searching for
quality statements will place the most important information at the front of the name.
3.1.1.14
Rules specific to quality statements for data sources
3.1.1.14.1 Lexical rules determining individual name components
A.
The indicator sets are composed of the following components:
For example: Perinatal NMDS 2010-2011: National Perinatal Data Collection, 2010;
Quality Statement.
B.
Capital letters may be used for the first letter of each word in the collection name,
data source name, and the phrase ‘Quality Statement’.
C.
A colon should only be used to separate collection name and data source name.
D.
Commas should only be used to separate the data source name, from the year the
data source was last updated.
E.
Semi-colons should only be used to separate the year the data source was last
updated and the suffix phrase ‘Quality statement’.
F.
An emdash not permitted unless they are a part of the formal Collection or data
source name.
G.
Full stops are not permitted unless they are a part of the formal Collection or data
source name.
H.
Parentheses are not permitted unless they are a part of the formal formal Collection
or data source name.
18
METeOR business rules for online data standard development Version 5.0
I.
Square and curly brackets (braces) are not permitted unless they are a part of the
formal Collection or data source name.
3.1.1.14.2
Semantic rules determining the meaning of name components
A.
The name of the Collection/NMDS should occupy the leftmost component of the
technical name, followed by a colon and a space.
B.
The space shall be followed by the name of the data source, followed by a comma, a
space and the year the data source was last updated.
C.
The year the data source was last updated should be followed by a semi colon, and
then a space.
D.
The phrase ‘Quality statement’ should occupy the rightmost component of the name.
The suffix of Quality statement, as opposed to the prefix means that searching for
quality statements will place the most important information at the front of the name.
3.1.1.15
Rules specific to data source
A.
State the full and formal name of the data source, for example the ‘National Perinatal
Data Collection (NPDC)’ or ‘Survey of Disability and Carers (SDAC)’, as specified by
the auspice body responsible for defining the Indicators. Wherein, there is not a
specific collection name, the source of the data is an accepted reference such as
‘Medicare data’ or ‘DVA data’.
B.
Capital letters may be used for the first letter of each word in the data source.
3.1.2 Short names
Definition:
A short or common name or designation by which the data item is known and
might be identified.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users.
3.1.2.1 Rules specific to data elements
A.
Short name should be a single unique name by which a data element can be
identified. To ensure uniqueness, the name may be qualified to distinguish this data
element from other similar data elements.
B.
For example, the data element technically named Adult—body mass index
(measured), ratio NN[N].N[N] is commonly referred to simply as ‘Body mass index’.
This is not a sufficient short name however as there are 3 other data elements which
are also commonly known by the same name (Adult—body mass index (selfreported), ratio NN[N].N[N], Child—body mass index (measured), ratio NN[N].N[N]
METeOR business rules for online data standard development Version 6.0
19
and Child—body mass index (self-reported), ratio NN[N].N[N]). The short name for
this data element must distinguish this data element from the other 3 data elements
through qualification. E.g., Body mass index-adult (measured).
3.1.2.2 Rules specific to indicators
A.
The short name should be the formal name assigned to the indicator by the
responsible auspice body.
B.
The short name may not necessarily be unique, as indicators may be used across
agreements and inherit the same reference number. If this occurs the agreement
name and agreement reference year may be added to differentiate the items.
3.1.3 Metadata item type
Definition:
The type of metadata.
Obligation:
Mandatory completion.
Creator:
Automatically generated by METeOR.
Visibility:
All users.
No rules defined.
3.1.4 Synonymous names
Definition:
A synonym or list of synonyms for the name within the context of the
metadata item.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
3.1.4.1 Rules common to all metadata items
A.
List any synonyms for the metadata item name which may be used to identify the
metadata item.
B.
Express the first word of each synonymous name with a capital letter. Express all
other words in a synonymous name with a lower-case letter, unless referring to a
proper noun. For example synonymous names for the property Procedure may
include: Clinical intervention; Operation; Surgery.
C.
Separate each synonymous name with a semi-colon and space.
D.
Conclude the list of synonymous names without a full stop.
3.1.4.2 Rules specific to classification schemes
A.
State the abbreviated title of the classification scheme, including the version/edition
number (if any) e.g. International Statistical Classification of Diseases and Related
Health Problems, Tenth Revision, Australian Modification 6th edition would read
ICD-10-AM 6th edn.
B.
If the classification scheme has an edition or version number, abbreviate the term
edition with edn, and version with v. e.g. ICD-10-AM 6th edn; NCCS v. 2.0.
20
METeOR business rules for online data standard development Version 5.0
C.
If there is no version/edition number associated with the classification scheme, insert
the year of publication after the name of the classification scheme e.g. North
American Nursing Diagnosis Association (NANDA) Taxonomy 1997-1998 would
read NANDA 1997-1998.
3.1.5 Metadata item identifier
Definition:
A unique identifier within METeOR.
Obligation:
Mandatory completion.
Creator:
Automatically generated by METeOR
Visibility:
All users.
No rules defined.
3.1.6 Registration status
Definition:
A status value for a metadata item indicating its stage in the registration
process.
Obligation:
Mandatory.
Creator:
Automatically generated by METeOR as a consequence of developer and
registrar actions.
Visibility:
All users.
3.1.6.1 Rules common to all metadata items
The registration status value is automatically set by METeOR, for each registration
authority available within METeOR, as actions to change the registration status are
made (i.e. by clicking the action Change registration status or Undo last registration
change):
A.
The available registration status values are listed in Table 2 below.
B.
Each registration status is associated with a registration date.
C.
The registration date is decided by a relevant committee e.g. a registration authority
or its representatives.
D.
Each registration status is associated with a statement of authorisation.
E.
The authorisation states the authority and date upon which the decision for a
registration status change was made. For example: Endorsed by Community Services
Information Management Group and the date.
F.
A metadata item with a registration status of Superseded must also have a related
metadata relationship of Is superseded by.
METeOR business rules for online data standard development Version 6.0
21
Table 1: Registration status values, their associated meanings, valid administration status values
and the workflow action required to achieve this value
Status
Meaning
Administration status
Workflow action required
Proposed
A developer has proposed
this item for consideration by
the registrar and
subsequently by an RA.
Can be edited by developer
and registrar.
Submit to registrar
Recorded
The registrar has determined
that the item meets quality
criteria and can proceed for
consideration by a nominated
data committee. The item
has been accepted onto the
work program of a data
committee.
Can be edited by developer
and registrar.
Record for data committee
Candidate
The item is under
consideration by a data
committee.
Can be edited by developer
and registrar.
Accept on work program
Standardisation pending
A data committee has
recommended the item to an
RA for approval as a
standard.
Can be edited by the
Registrar only
Recommend to registration
authority
Standard
The item has been accepted
by an RA as a standard.
Can be edited by the
Registrar only
Approve as standard
Superseded
The item has been
nominated by an RA to be
replaced as a standard by
another item.
Can be edited by the
Registrar only
Supersede standard
Retired
The item has been
nominated by an RA to be
withdrawn as a standard.
Can be edited by the
Registrar only
Retire standard
3.1.7 Definition
Definition:
A concise statement that expresses the essential nature of the metadata item
and its differentiation from other metadata items.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users.
3.1.7.1 Rules common to all metadata items
A.
The definition should be expressed precisely and unambiguously so that the exact
meaning of the item is apparent from the definition.
B.
Describe the item concisely, without repeating the name of the metadata item at the
start of the definition, embedding definitions of related concepts, or embedding
supportive information.
C.
The definition should be expressed through terms and a structure which is consistent
with related definitions.
22
METeOR business rules for online data standard development Version 5.0
D.
The definition should be expressed as a complete, grammatically correct and
descriptive phrase, sentence or paragraph, not merely through the use of synonyms
or paraphrasing the name of the metadata item.
E.
A definition should not contain definitions of other metadata items or concepts.
Rather, it should provide an explanation of WHAT is being described. It should
generally not include information about the WHO, WHERE, WHEN, WHY and HOW
of data collection.
3.1.7.2 Rules specific to properties
A.
When a property name begins with the words Number of, begin the definition with
the words A count of.
METeOR business rules for online data standard development Version 6.0
23
3.1.7.3 Rules specific to value domains
A.
The definition attribute for value domains should be based on the definition
templates given in Table 3. Representation classes are defined in Section 8.2.
Table 2: Definition templates for value domains
Representation class
Value domain definition template
Average
The arithmetic mean of…
Code (not based on a classification scheme)
A code set representing …
Code (based on a classification scheme)
The (insert the short classification scheme name) code set
representing …
Date
A valid day of a particular month and year under the
Gregorian calendar.
Identifier
A combination of (insert numeric, alphabetic and/or
alphanumeric) characters that identify an entity.
Percentage
A proportion per hundred.
Ratio
A relative measure.
Text
A combination of (insert alphabetic and/or alphanumeric)
characters.
Time
An instance in time represented in a (insert either 24-hour or
12-hour) scale.
Total
Total number of (insert the unit of measure written in plural);
or
Total concentration in (insert the unit of measure written in
plural.
3.1.7.4 Rules specific to classification schemes
A.
Express the definition using the following format: ‘The (insert the formal name of the
organisation) classification for the (insert the topic of the classification scheme).’
3.1.8 Context
Definition:
A designation and/or description of the application environment or discipline
in which the metadata item has meaning.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
3.1.8.1 Rules common to all metadata items
A.
State or describe the circumstances or events that form the environment in which the
metadata item has meaning e.g. Palliative care.
B.
The context should be expressed as a complete, grammatically correct and descriptive
phrase, sentence or paragraph.
24
METeOR business rules for online data standard development Version 5.0
3.2 Collection and usage attributes
3.2.1 Guide for use
Definition:
Comments, advice, or instructions for the interpretation or application of the
metadata item.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
3.2.1.1 Rules specific to object classes, properties and data element concepts
A.
Describe how the metadata item is intended to be interpreted or applied within the
specified context(s).
3.2.1.2 Rules specific to data elements
A.
Describe any restrictions to how the data element is intended to be interpreted or
applied which are specific to the union of the data element concept and the value
domain. For example, describe how other data elements should be used in
conjunction with the current data element, any formulae which guide calculations, or
coding guidelines.
3.2.1.3 Rules specific to value domains
A.
Describe any restrictions to how the value domain is to be interpreted or applied
which are applicable to the collection of all data elements which implement the value
domain. For example, instructions for rounding numeric values and coding
guidelines.
3.2.2 Collection methods
Definition:
Comments, advice, or instructions for the actual capture of data.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
3.2.2.1 Rules specific to object classes, properties and data element concepts
A.
Outline any collection guidelines for the metadata item e.g. recommended data
collection instruments.
3.2.2.2 Rules specific to data elements
A.
Outline any guidelines for the collection of the data element which are specific to the
union of the data element concept and the value domain. For example, data collection
formats, minimum data collection requirements, requirements for supporting
material or how missing data is to be treated.
METeOR business rules for online data standard development Version 6.0
25
3.2.2.3 Rules specific to value domains
A.
Outline any guidelines applicable to the collection of all potential data elements
which implement the value domain. This can include data collection formats,
minimum data collection requirements, requirements for supporting material and
how missing data is to be treated.
3.2.3 Comments
Definition:
Any additional information that adds to the understanding of the metadata
item.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
3.2.3.1 Rules common to all metadata items
A.
Describe any pertinent additional information which facilitates understanding of the
metadata item. For example, whether the metadata item is likely to be reviewed in the
near future, considerations for further development, potential terminology issues,
and justification for the inclusion or exclusion of content.
3.3 Source and reference attributes
3.3.1 Submitting organisation
Definition:
One or more organisations responsible for the submission of the metadata
item for national endorsement as a standard.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users.
3.3.1.1 Rules common to all metadata items
A.
State the complete and official organisation title at the time of submission, for each
organisation responsible for the submission of the metadata item.
B.
Abbreviations and symbols should only be used when they are part of the official
organisation title.
C.
Conclude and separate each organisation name with a new line (without a full stop).
3.3.2 Steward
Definition:
The name of the organisation that has accepted responsibility and been
approved by a registration authority to provide on-going maintenance and
management of a metadata item.
Obligation:
Optional completion: only completed if a steward has been endorsed and has
agreed to perform steward role.
26
METeOR business rules for online data standard development Version 5.0
Creator:
Registrar.
Visibility:
All users.
3.3.2.1 Rules common to all metadata items
A.
Each metadata item may be associated with only one steward.
B.
The steward has responsibility for ensuring that the metadata item is kept up-to-date
for all registration authorities to which it has been proposed.
C.
Leave this field blank until an organisation has agreed and has been approved by a
registration authority to provide on-going maintenance and management of the
metadata item.
D.
State the complete and official organisation title for the steward (including a
committee where necessary).
E.
Abbreviations and symbols should only be used when they are part of the official
organisation title.
3.3.3 Origin
Definition:
Any document(s) (including websites) from which any content of the
metadata item originates.
Obligation:
Conditional completion: complete for metadata items that are based on the
content of a document outside of METeOR.
Creator:
Developer.
Visibility:
All users.
3.3.3.1 Rules common to all metadata items
A.
List the full reference for all in-text references cited in the body of that metadata item.
B.
References should comply with the attached referencing guidelines (see Chapter 14).
C.
Conclude and separate each reference with a new line (without a full stop).
3.3.3.2 Rules specific to value domains
A.
List the full name of any classification scheme which is partially implemented by the
value domain (i.e. when a value domain does not implement all codes listed in a
chapter of a classification, or all codes within the classification).
3.3.4 Reference documents
Definition:
Significant documents that contributed to the development of the metadata
item which were not direct source for metadata content.
Obligation:
Conditional completion: complete for metadata items that were developed in
consultation with a document outside of METeOR.
Creator:
Developer.
Visibility:
All users.
METeOR business rules for online data standard development Version 6.0
27
3.3.4.1 Rules common to all metadata items
A.
References should comply with the attached referencing guidelines (see Chapter 14).
B.
Conclude and separate each reference with a new line (without a full stop).
3.3.4.2 Rules specific to value domains
A.
List any support documents for a classification scheme partially implemented by the
value domain e.g. user guides.
3.4 Related metadata
3.4.1 Related metadata references
Definition:
An indicator of relationships between metadata items.
Obligation:
Optional completion.
Creator:
Developer (for forms and see also relationships) or Registrar (for supersedes
relationships).
Visibility:
All users.
3.4.1.1 Rules common to all metadata items
A.
Relationships may be created between any two metadata items: between items of the
same metadata type (e.g. between two data elements) or of a different metadata type
(e.g. a between a property and a value domain).
B.
Related metadata relationships should not duplicate information stored or available
elsewhere in METeOR. For example, that data element A is an implementation of
data element concept B should only be recorded in the data element concept name
attribute of the data element; that data element C is normally associated with data
element D should only be recorded in a DSS.
C.
Valid relationships within METeOR are listed in Table 4 below. METeOR will
automatically create the complementary relationship within the second metadata
item (listed in the second column of Table 4).
D.
The relationship See also may only be applied where it is critical for the reader to
know that the other item exists, other valid relationships (as listed in Table 4) are not
applicable, and when the relationship does not duplicate information stored
elsewhere.
E.
When creating a Superseded related metadata relationship, the registration status of
the superseded item must be set to Superseded.
28
METeOR business rules for online data standard development Version 5.0
Table 3: Related metadata values and their associated meaning
Relationship type
Complementary
relationship
Description
Valid metadata
Supersedes
Has been superseded by
An indicator of a superseded
item and the item that it was
superseded by.
All metadata item types.
Is formed using
Is used in the formation of
An indicator of an item that is
used in the calculation of, or
is a component of, another
item.
Data elements only.
See also
–
An indicator of an associated
item, irrespective of the
nature of the association.
All metadata item types.
Is re-engineered from
–
A link between a metadata
item re-engineered by AIHW
and the PDF file representing
the retired Knowledgebase
version.
Metadata created by AIHW
as part of the initial
population of METeOR from
Knowledgebase content.
3.5 Registry management attributes
3.5.1 Unresolved issues
Definition:
Comments which highlight unresolved issues for data committee or registrar
consideration.
Obligation:
Optional completion.
Creator:
Registrar.
Visibility:
Registrar only.
3.5.1.1 Rules common to all metadata items
A.
Specify pertinent development and maintenance information suitable for registrar
view only e.g. any recommended changes awaiting approval from a data committee.
B.
Number each unresolved issue and start with a capital letter e.g.
’23. Word is misspelt in the Definition section.’
C.
Separate each unresolved issues with a full-stop and a new line.
3.5.2 Submitting organisation contact details
Definition:
The details of at least one contact person for each listed submitting
organisation.
Obligation:
Optional completion.
Creator:
Registrar.
Visibility:
Registrar only.
METeOR business rules for online data standard development Version 6.0
29
3.5.2.1 Rules common to all metadata items
A.
List the name, position title, organisational sub-unit, telephone number and email
address of the person responsible for the submission.
B.
Approval from each submitting organisation contact must be received before any
contact information is stored within METeOR.
3.5.3 Steward organisation contact details
Definition:
The details of at least one contact person for the Steward organisation.
Obligation:
Optional completion.
Creator:
Registrar.
Visibility:
Registrar only.
3.5.3.1 Rules common to all metadata items
A.
List the name, position title, organisational sub-unit, telephone number and email
address of the contact person.
B.
Approval from each steward organisation contact must be received before any
contact information is stored within METeOR.
3.5.4 Created by
Definition:
The name of the original creator of this metadata item.
Obligation:
Mandatory completion.
Creator:
Automatic generation by METeOR.
Visibility:
Registrar and originating Developer only.
No rules defined.
3.5.5 Created date/time
Definition:
The date and time when the metadata item was first created.
Obligation:
Mandatory completion.
Creator:
Automatic generation by METeOR.
Visibility:
Registrar and originating Developer only.
No rules defined.
3.5.6 Last updated by
Definition:
The name of the person who last updated this metadata item.
Obligation:
Mandatory completion.
Creator:
Automatic generation by METeOR.
Visibility:
Registrar and originating Developer only.
No rules defined.
30
METeOR business rules for online data standard development Version 5.0
3.5.7 Last updated date/time
Definition:
The date and time when the metadata item was last saved.
Obligation:
Mandatory completion.
Creator:
Automatic generation by METeOR.
Visibility:
Registrar and originating Developer only
No rules defined.
METeOR business rules for online data standard development Version 6.0
31
4
Attributes specific to object classes
An object class represents the person, place, event or thing that needs to be described.
Specifically, an Object class is either:
i.
A service recipient or target group, eg. Admitted patient, Household, Discrete
Indigenous community;
ii.
A service/care episode e.g. Community services event, Episode of care;
iii.
A life event e.g. Injury event, Pregnancy;
iv.
A service provider e.g. Agency, Health professional, Volunteer; or
v.
An asset associated with a service provider/recipient e.g. Building.
Object classes have two attributes which are unique within METeOR: Specialisation of and
Data element concepts implementing this object class.
4.1 Specialisation of
Definition:
An instance of specialisation of an object class.
Obligation:
Conditional completion: this attribute is only completed for object classes that
are subtypes of another object class.
Creator:
Registrar only.
Visibility:
All users.
A.
When an object class reaches a registration status of Candidate, it should be assigned
an object class specialisation.
B.
An object class is assigned to an object class specialisation using the Parent and Child
attributes of an object class specialisation.
4.2 Data element concepts implementing this object
class
Definition:
A list of the data element concepts that implement this object class.
Obligation:
Conditional completion: only those data element concepts which implement
this object class are listed.
Creator:
Automatic generation by METeOR.
Visibility:
All users that have permission to view at least one data element concepts
which implement the object class
No rules defined.
32
METeOR business rules for online data standard development Version 5.0
5
Attributes specific to properties
A property represents the characteristic of the object that is of interest. Properties have two
attributes which are unique within METeOR: Property group and Data element concepts
implementing this property.
5.1 Property group
Definition:
The grouping of properties with similar characteristics.
Obligation:
Mandatory completion.
Creator:
Registrar only.
Visibility:
All users.
A.
When a property reaches a registration status of Candidate, it should be assigned to a
property group.
B.
A property should only be assigned to one property group.
5.2 Data element concepts implementing this
property
Definition:
A list of the data element concepts that implement this property.
Obligation:
Conditional completion: only those data element concepts which implement
this property are listed.
Creator:
Automatic generation by METeOR.
Visibility:
All users that have permission to view at least one data element concepts
which implement the property.
No rules defined.
METeOR business rules for online data standard development Version 6.0
33
6
Attributes specific to data element
concepts
A data element concept represents the union of an object class and a property. Data elements
concepts have three attributes which are unique within METeOR: Object class, Property, and
Data elements implementing this data element concept.
6.1 Object class
Definition:
The object class implemented in this data element concept.
Obligation:
Mandatory completion (before Proposed registration status).
Creator:
Developer.
Visibility:
All users that have permission to view the data elements concepts listed.
A.
Only one object class may be selected.
B.
An object class must be selected before a data element concept will be considered by a
Registrar.
6.1.1 Guidance for selecting/creating an object class
A.
Where a new object class is created, it must fit into one of the object class categories:
i.
A service recipient or target group, e.g. Admitted patient, Household, Discrete
Indigenous community;
ii.
A service/care episode e.g. Community services event, Episode of care;
iii.
A life event e.g. Injury event, Pregnancy;
iv.
A service provider e.g. Agency, Health professional, Volunteer; or
v.
An asset associated with a service provider/recipient e.g. Building, Dwelling.
B.
A data element concept must pertain specifically to the selected object class. For
example, the property Current pregnancy status applies only to females, and hence,
should be paired with the object class Female rather than Person. For properties
which apply to more than one object class e.g. Telephone number, create a separate
data element concept for each object class e.g. Person (address)—telephone number;
Organisation (address)—telephone number.
C.
For data element concepts that describe people or patients with a specific condition
e.g. acute coronary syndrome, cancer, or diabetes, the object class name should begin
with the term Person with e.g. Person with diabetes.
D.
If there is any doubt as to the most appropriate object class for a data element concept
e.g. Person or Patient, select the least specialised object class (in this case, Person).
E.
For data element concepts which describe interventions such as medication or
treatment undertaken, select the object class Person when that intervention occurred
outside of an event e.g. for medication regularly taken at home, and select an event
34
METeOR business rules for online data standard development Version 5.0
object class when that intervention occurred within an event e.g. for medication
prescribed by an ambulance officer within an acute coronary syndrome episode.
F.
The following table provides examples of properties which may be associated with
the parent object classes Person and Service event.
Table 4: Examples of properties and their association with object classes
Person
Service event
Person characteristics e.g. name, date of birth, sex, address,
country of birth, Indigenous status, hospital insurance status,
field of education, name, and income unit.
Categorisations of patients/clients which primarily describe a
service provider’s efficiency or effectiveness e.g. waiting time.
Assessments of a person’s health, needs or well-being, which
form part of their medical/client history e.g. blood pressure,
principal diagnosis, abuse and neglect type, cataract history,
medication taken, alcohol/tobacco consumption, disability
status, and hypertension treatment status.
Justification for the event or sub-events e.g. assistance
request reason, behaviour-related risk factor intervention
purpose.
Employment/income characteristics e.g. labour force status,
occupation, government funding identifier, assessable income.
The services or care sought or provided within the event,
including interventions undertaken e.g. available service
activity, care type, procedure, assistance received, and
anaesthesia administered.
Living arrangements e.g. accommodation type.
The urgency or importance of the event or sub-events e.g.
admission urgency status, assistance urgency, triage
category.
The time, date, or duration of the event or sub-events (actual
or intended) e.g. admission date, duration of residence,
intended length of hospital stay, procedure commencement
date.
Event funding characteristics e.g. expected principal source of
funding.
6.2 Property
Definition:
The property implemented in this data element concept.
Obligation:
Mandatory completion (before Proposed registration status).
Creator:
Developer.
Visibility:
All users.
A.
Only one property may be selected.
B.
A property must be selected before a data element concept will be considered by a
Registrar.
6.2.1 Guidance for selecting/creating a property
A.
Unambiguously describe the characteristic to be measured. The properties Treatment
cessation reason and Service cessation reason, for example, are preferred over a
single, more generic property named Cessation reason because of the need to define
‘what’ is being ceased. The broadly-defined property Abuse and neglect type
however, is sufficient, as the categorisation of abuse and neglect can be meaningfully
defined independently from the class of abused persons being described e.g. children,
disabled persons, elderly persons.
METeOR business rules for online data standard development Version 6.0
35
B.
A representation class name is not a valid property. Admission time and Person
identifier, for example, are preferred over the more generic properties Time and
Identifier because of the need to define ‘what’ the date, time, and identifier describe.
C.
Define the property independently of when and how it is to be collected, and how it
is to be represented. For example, Number of cigarettes smoked is preferred over
Number of cigarettes smoked per day. Such information may be stored within a data
element or value domain.
D.
Define the property in consideration of how measures of that property are to be
reported. For example, the broadly-defined properties Capital expenditure and
Recurrent expenditure are preferred over properties which are specific to individual
types of expenditure such as Repairs and maintenance expenditure or Depreciation
costs, when these items are reported under the broad headings capital/recurrent
expenditure. In the case of broad properties which are collected and cross-checked
with measures of their individual components, overlapping properties may be
defined. For example, the property Postal delivery point identifier (commonly termed
address) may be defined alongside its components e.g. State/territory identifier;
Postcode.
6.3 Data elements including this data element
concept
Definition:
A METeOR-generated list of the data elements that include this data element
concept.
Obligation:
Conditional completion: only those data element which implement this data
element concept are listed.
Creator:
Automatic generation by METeOR.
Visibility:
All users that have permission to view at least one data element which is
implemented in this data element.
36
METeOR business rules for online data standard development Version 5.0
7
Attributes specific to data elements
Data elements represent the union of a data element concept (concept) and a value domain
(representation). Data elements have four attributes which are unique within METeOR: Short
name, Data element concept, Value domain, and Implementation in data set specifications.
7.1 Short name
Definition:
A short or common name or designation by which the data element is known
and might be identified.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users.
A.
Short name should be a single unique name by which a data element can be
identified. To ensure uniqueness, the name may be qualified to distinguish
this data element from other similar data elements.
B.
For example, the data element technically named Adult—body mass index
(measured), ratio NN[N].N[N] is commonly referred to simply as ‘Body mass
index’. This is not a sufficient short name however as there are 3 other data
elements which are also commonly known by the same name (Adult—body
mass index (self-reported), ratio NN[N].N[N], Child—body mass index
(measured), ratio NN[N].N[N] and Child—body mass index (self-reported),
ratio NN[N].N[N]). The short name for this data element must distinguish this
data element from the other 3 data elements through qualification. E.g., Body
mass index-adult (measured).
7.2 Data element concept
Definition:
The data element concept implemented in this data element.
Obligation:
Mandatory completion (before Proposed registration status).
Creator:
Developer.
Visibility:
All users.
A.
Only one data element concept may be selected.
B.
A data element concept must be selected before a data element will be
accepted by the Registrar.
7.3 Value domain
Definition:
The value domain implemented in this data element.
Obligation:
Mandatory completion (before Proposed registration status).
Creator:
Developer.
Visibility:
All users.
METeOR business rules for online data standard development Version 6.0
37
A.
Only one value domain may be selected.
B.
A value domain must be selected before a data element will be accepted by
the Registrar.
7.4 Implementation in data set specifications
Definition:
A list of the data set specifications that include this data element.
Obligation:
Conditional completion: only those data set specifications which implement
this data element are listed.
Creator:
Automatic generation by METeOR.
Visibility:
All users that have permission to view at least one data set specification which
implements the data element.
7.5 Non dictionary data element
Definition:
A data element that has been excluded from a data dictionary.
Obligation:
Conditional completion: only applicable to community services data elements
that have been selected as being specific to a data set specification. This
includes data elements mappable to a national standard data element that is
included in a national data dictionary, where a common data element concept
is used.
Creator:
Registrar.
Visibility:
All users.
38
METeOR business rules for online data standard development Version 5.0
8
Attributes specific to value domains
A value domain represents an implied and/or explicit set of values used to represent
something/someone. Value domains have eleven attributes which are unique within
METeOR: Classification scheme, Representation class, Data type, Format, Maximum
character length, Permissible values, Supplementary values, Unit of measure, Proposed unit
of measure, Unit of measure precision, and Data elements implementing this value domain.
8.1 Classification scheme
Definition:
The name of the classification scheme which is implemented in this value
domain.
Obligation:
Conditional completion: complete for all value domains which are of
representation class Code and implement a full chapter of, or entire
classification scheme.
Creator:
Developer.
Visibility:
All users.
A.
Only one classification scheme may be selected.
B.
If an incomplete set of values from a classification is implemented by a value
domain, or no classification is associated with the value domain, leave this
attribute blank.
8.2 Representation class
Definition:
The class of representation of a value domain e.g. Code or Total.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users.
A.
Select one valid representation class from Table 6.
B.
The representation class reflects the main structure of the value domain, not
supplementary code(s) such as 99 not stated/inadequately described. For
example, the representation class for a value domain permitting a measured
value (e.g. 5 centimetres) or a 99.9 for not able to be measured code, is Total,
not Code.
C.
A value domain that is of representation class Ratio consists of measures of at
least two distinct concepts, each of which may be collected in its own right e.g.
body mass index is calculated from measures of a person’s body weight and
body height. In contrast, a value domain that is of representation class Total is
either an absolute count of something, reported in one or more units (e.g.
Australian currency), or one measure, expressed as a proportionate quantity
(e.g. milligrams per litre).
METeOR business rules for online data standard development Version 6.0
39
Table 5: Representation class values and their associated meaning
Value
Meaning
Average
A numeric value representing an arithmetic mean.
Code
A system of valid symbols that substitute for longer values.
Date
A numeric value representing a calendar date (i.e. day, month and year) or recognised part of a
calendar date (i.e. day, month, and/or year).
Identifier
A value which establishes identity.
Percentage
Parts per hundred.
Ratio
An expression of the quantity of one substance or entity in relation to that of another (Dorlands, 2003:
1586).
Text
An unformatted, descriptive value.
Time
A numeric value representing a specific instance in time.
Total
A numeric value representing the sum of a set of values or an entire quantity (including monetary).
8.3 Data type
Definition:
A set of distinct values, characterised by properties of those values and by the
operations on those values e.g. Currency and Number.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users.
A.
Select one valid data type using Table 7.
B.
The data type reflects the main structure of the value domain, not
supplementary value(s) such as 99 not stated/inadequately described. For
example, the data type for a value domain holding yes/no values and a 99 not
stated/inadequately described code is Boolean, not Number.
C.
A value domain of representation class Average or Total must have a data
type of Currency or Number.
D.
A value domain of representation class Percentage and Ratio must have a data
type of Number.
E.
A value domain of representation class Boolean, Code or Identifier must have
a data type of Number or String.
F.
A value domain of representation class Date or Time must have a data type of
Date/time.
G.
A value domain of representation class Text must have a data type of String.
Table 6: Data type values and their associated meaning
Value
Meaning
Boolean
A binary value expressed using a string e.g. true or false.
Currency
A numeric value expressed using a particular medium of exchange.
Date/Time
A specific instance of time expressed in numeric form.
Number
A sequence of numeric characters which may contain decimals, excluding codes with ‘leading’
characters e.g. ‘01’,’02’,’03’.
40
METeOR business rules for online data standard development Version 5.0
String
A sequence of alphabetic and/or numeric characters, including ‘leading’ characters e.g. ‘01’,‘02’,‘03’.
Image
A depiction recorded electronically to allow viewing or transmission on a computer. e.g ‘jpg’, ‘png’, ‘gif’
Geospatial
A value relating to the position of things on the earth's surface.
8.4 Format
Definition:
A template for the presentation of values, including specification and layout
of permitted characters, the maximum and minimum size, and precision. It is
not a template for electronic data transmission or storage.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users.
8.4.1 Valid characters
A.
The values that can be used in the format attribute are listed in Table 8.
Formatting characters such as decimal points, full stops, commas and hyphens
are specified using symbolic representation. For example, a number with a
precision of one is to be represented by the format: N.N
B.
Characters which are not enclosed in brackets signify a value which must be
represented.
C.
If a character is repeated more than 6 times in succession, round brackets and
a number are to be used to indicate the number of repeats e.g. X(7) not
XXXXXXX.
Table 7: Format values and their associated meaning
Value
Valid character range
A
Alphabetic character set: contains the letters a-z and A-Z and may contain special character(a), but not numeric
characters.
N
Numeric character set: contains whole and decimal numbers and may contain special characters, but not
alphabetic characters.
X
Alphanumeric character set: contains alphabetic and numeric characters, and may contain blank characters.
D
A numeric character representing a number of days. (b)
M
A numeric character representing a number of months. (b)
Y
A numeric character representing a number of years. (b)
h
Any numeric character representing a number of hours. (b)
m
Any numeric character representing a number of minutes. (b)
s
Any numeric character representing number of seconds. (b)
{}
The string within the curly brackets (braces) is optional in its entirety (e.g. X{XX} indicates 1 or 3 alphanumeric
characters (i.e. X or XXX)).
[]
The string within the square brackets is optional in any ordered combination (e.g. [XXX] indicates 0, 1, 2 or 3
alphanumeric characters (i.e. blank, X, XX or XXX)).
()
The character preceding the round brackets (parentheses) is repeated the number of times specified (e.g. X(9)
indicates 9 alphanumeric characters).
(a) Valid in value domains of representation class Date or Time only. These format values indicate the valid unit(s) of measure to be presented.
For value domains of all other representation classes, only the characters A, N, X, { }, [ ], and ( ) may be used to denote the presence of a value.
METeOR business rules for online data standard development Version 6.0
41
(b) A special character is a character which has a visual representation and is neither a letter, number, ideogram, or blank. For example,
punctuation marks and mathematical symbols.
An ideogram is a character that represents an object or concept e.g. Chinese ideogram or Japanese Kanji.
A blank is a character that represents an empty position in an alphanumeric character field e.g. space. A blank is conceptually different from a null
value, which is defined as the absence of a stored value.
8.4.2 Protocol
A.
Position characters using a protocol reading from inner brackets (if any) to
outer brackets, and left to right. For example NNNNX[AA] represents four
numeric characters followed by one alphanumeric character, and up to two
alphabetic characters (i.e. NNNNX, NNNNXA or NNNNXAA).
B.
Express a sequence of characters of a given character type by ordering
characters which must be represented to the left of characters that may/not be
represented. For example, NN[N] not [N]NN.
8.5 Maximum character length
Development rules
For items that are of data type Number, the maximum character quantity represents a count
of all numeric characters only (excluding characters such as plus, minus and decimal points).
If the value domain contains a decimal point specify the number of decimal places permitted
through the unit of measure precision field.
For example the Number 3.142 contains a maximum of 4 characters.
Definition:
The maximum number of characters permitted to represent the values.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users.
A.
Indicate the maximum number of characters permitted to be stored. For items
that are of data type String, the maximum character quantity represents a
count of all alphabetic, numeric and other ASCII characters (including full
stops, forward slash, back slash and hyphens).
For example the String YYYY-YY contains a maximum of 7 characters.
B.
For items that are of data type Number, the maximum character quantity
represents a count of all numeric characters only (excluding characters such as
plus, minus and decimal points). If the value domain contains a decimal point
specify the number of decimal places permitted through the unit of measure
precision field.
For example the Number 3.142 contains a maximum of 4 characters.
8.6 Permissible values
Definition:
42
A list of values that is valid for the Value domain. Permissible values may be
enumerated or non-enumerated. When permissible values are enumerated,
the values may be coded or fully described.
METeOR business rules for online data standard development Version 5.0
Obligation:
Conditional completion: complete for value domains that has Code as its
representation class but no link or reference to a classification scheme.
Creator:
Developer.
Visibility:
All users.
A.
List each permissible value on a new line within the left-most column, without
the use of a semi-colon, comma or full stop.
B.
For each permissible value, provide a concise description in the corresponding
right-hand column.
C.
Expressly exclude or include a specific value from a permissible value by:
i.
Stating the name of that value in alphabetic characters within the
description column.
ii.
Enclosing this text within parentheses.
For example, Drowning, submersion - other than swimming pool (excludes
drowning associated with water craft).
8.7 Supplementary values
Definition:
A list of codes and code descriptions representing values produced in the data
cleaning process (i.e. were not specified on the data collection form).
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
A.
Supplementary values should not fall within the scope of the value domain
definition. For example, a value domain defined as ‘a code set representing
languages’ may include the permissible values: 1 English, 3 Sign language, 5
Other language, and the supplementary values: 8 Inadequately described, 9
Not stated. A Value domain defined as ‘a code set representing sign language’
may include the permissible values: 1 Auslan, 2 American Sign language, 3
Other language (non-spoken), and the supplementary value: 5 Other language
(spoken).
B.
List each supplementary value on a new line within the left-most column,
without the use of a semi-colon, comma or full stop.
C.
For each supplementary value, provide a concise description in the
corresponding right-hand column.
8.8 Unit of measure
Definition:
The actual units in which permissible values are measured.
Obligation:
Conditional completion: complete for value domains of representation class
Average or Total only.
Creator:
Developer (or by Registrar if desired unit of measure is not available).
METeOR business rules for online data standard development Version 6.0
43
Visibility:
All users.
A.
Where the value domain has a representation class of Average or Total, select
a unit of measure using the unit of measure table. If no appropriate category
exists, propose a new unit of measure in the proposed unit of measure
attribute. For value domains with a representation class of Date or Time, the
unit of measure is indicated within the format only.
B.
Only one unit of measure may be selected. For value domains which store a
proportional quantity (e.g. milligram per litre) or a combination of units (e.g.
hour and minute), state all units as the unit of measure (e.g. milligram per
litre; hour and minute).
C.
The values that can be selected for the unit of measure attribute are listed in
Table 9.
Table 8: Example units of measure classified by measure
Measurement
Unit of measure name
Unit of measure symbol
Concentration
Microgram per litre
µg/L
Microgram per minute
µg/min
Micromole per litre
µg/l
Millimetre of mercury
mmHg
Millimole per litre
mmol/L
Milligram per millimole
mg/mmol
Milligram per litre
mg/L
Milligram per 24-hour period
mg/24h
Nanogram per decilitre
ng/dl
Currency
Australian currency
AU$
Length
Centimetre
cm
Millimetre
mm
Temperature
Degree Celsius
Time
Second
s
Minute
min
Hour
h
Hour and minute
Day
D
Week
Weight
Other
Year
Y
Gram
g
Kilogram
Kg
Attendance
Bed
Bedroom
Cigarette
Full-time equivalent (FTE) staff
44
METeOR business rules for online data standard development Version 5.0
Group session
Occasion of service
Period
Person
Pregnancy
Separation
Service contact
Service contact date
Service event
Standard drink
8.9 Proposed unit of measure
Definition:
The proposed units in which permissible values are measured.
Obligation:
Conditional completion: complete for value domains of representation class
Average or Total only where an appropriate value is not available in the unit
of measure list.
Creator:
Developer.
Visibility:
All users.
A.
To be completed only if an appropriate unit of measure value is not available
in the unit of measure list.
B.
To propose a new unit of measure, within the propose a new unit of measure
text field, state the full name of the unit of measure in singular form, followed
by the unit of measure symbol (if one exists) enclosed in parentheses e.g.
Gram (g).
C.
Capitalise the first letter of the first word only, except when referring to
proper nouns e.g. Degree Celsius.
D.
A unit of measure symbol should be recognised by an International or
Australian standard e.g. ISO 1000, International Committee for Weights and
Measures (CIPM), and National Measurement Act 1960.
E.
A unit of measure symbol must not symbolise more than one unit of measure
within METeOR e.g. m refers to meter, not month or minute. This rule does
not apply to symbol prefixes (e.g. m also symbolises 0.001 of another unit) and
when combined with the unit meter (m), will result in the valid symbol mm.
F.
All unit of measure symbols within METeOR must be consistent e.g. m refers
to metre while mm symbolises millimetre.
8.10
Unit of measure precision
Definition:
The number of decimal places in which a unit of measure is measured.
Obligation:
Conditional completion: complete for value domains which hold a unit of
measure or proposed unit of measure.
Creator:
Developer.
METeOR business rules for online data standard development Version 6.0
45
Visibility:
All users.
A.
If the value domain is assigned a unit of measure or proposed unit of measure,
specify the number of decimal places permitted.
B.
Specify the unit of measure precision in numeric form e.g. 1.
8.11
Data elements implementing this value domain
Definition:
A list of the data elements that implement this value domain.
Obligation:
Conditional completion: only those data elements which implement this value
domain are listed.
Creator:
Automatically generated by METeOR.
Visibility:
All users that have permission to view at least one data element which
implements the value domain.
46
METeOR business rules for online data standard development Version 5.0
9
Attributes specific to classification
schemes
A classification scheme represents a system for classifying data which is recognised and
endorsed by a national or international body. Classification schemes have three attributes
which are unique within METeOR: Classification structure, Revision status, and Value
domains based on this classification scheme.
9.1 Classification structure
Definition:
The underlying structure of a classification scheme such as the number and
type of scales or axes within the classification.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
A.
Describe the structure of the classification scheme with particular reference to
domains, axes or scales corresponding to particular topics or subject areas.
9.2 Revision status
Definition:
The status of the classification scheme in terms of formal revisions.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
A.
Describe the edition or version of the classification referenced.
9.3 Value domains based on this classification
scheme
Definition:
A list of the value domains that implement this classification scheme.
Obligation:
Conditional completion: only those value domains which implement this
classification scheme are listed.
Creator:
Automatically generated by METeOR.
Visibility:
All users that have permission to view at least one value domain which
implements the classification scheme
No rules defined.
METeOR business rules for online data standard development Version 6.0
47
10 Attributes specific to data set
specifications
A data set specification represents a grouping of data elements and/or other data set
specifications, and the conditions under which the grouping should be collected or reported.
Data set specifications have eleven attributes which are unique in the METeOR system: Data
set specification type, Scope, Metadata items in this data set specification, Sequence number,
Obligation, Maximum occurrences, Conditional obligation and Information specific to this
data set, Statistical unit, Implementation start date and Implementation end date.
10.1 Data set specification type
Definition:
Information on whether a data set specification is a national minimum data set
or other data set specification.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users.
A.
There are currently three forms of data set specification:
B.
i.
National Minimum Data Set (NMDS), which reflects a national
agreement to collect a consistent data set for a specified purpose; and
ii.
Data set specification, is recommended as best practice if data are to be
collected but not mandated for collection; and
iii.
Data element cluster, is a group of data elements and describes how
selected data elements relate to each other for a specific purpose. It can
be included in a National minimum data set or a data set when there is
a need to better describe a group of data elements and how they
should be collected or reported. A data cluster must be collected in it
entirety. (see appendix 2)
A data set specification must be agreed by relevant stakeholders for
mandatory national reporting before it will be approved as a national
minimum data set.
10.2 Scope
Definition:
A description of the circumstances under which the collection of specified
data are required or recommended.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
48
METeOR business rules for online data standard development Version 5.0
C.
The scope should be expressed precisely and unambiguously so that the
specified data can be collected under the same circumstances by different data
collectors.
D.
The statement should clearly identify all boundaries between those
circumstances where collection is appropriate and those circumstances where
it is not. These boundaries may potentially include geography, sources of
funding, administering authorities, the type of services provided or the legal
or administrative status of the people receiving services.
E.
More than one boundary may be relevant to the scope of the collection.
Complex boundaries maybe explained with the use of an example.
10.3 Metadata items in this data set specification
Definition:
A list of the metadata items, either data elements or data set specifications,
which are included in this data set specification.
Obligation:
Mandatory completion: a data set specification must include at least two
metadata items.
Creator:
Developer.
Visibility:
All users that have permission to view at least one metadata item which is
included in the data set specification.
No rules defined.
10.4 Sequence number
Definition:
An indicator of the order of the data element or data set specification within
the data collection or transmission.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users that have permission to view the data element/DSS listed.
No rules defined.
10.5 Obligation
Definition:
An indicator of whether the data element or data set specification is
mandatory, optional or conditional for the data collection or transmission.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users that have permission to view the data element/DSS listed.
A.
Mandatory completion signifies that the data element/data set specification
must be included.
METeOR business rules for online data standard development Version 6.0
49
B.
Conditional completion signifies that under specific criteria, a data
element/data set specification must be included. The criterion by which a
value can be included can be specified within the Verification rules attribute.
C.
Optional completion signifies that a data element/data set specification may
or may not be collected.
10.6 Maximum occurrences
Definition:
The maximum number of occurrences of the data element or data set
specification within the data set (i.e. single use or repeating group).
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users that have permission to view the data element/ data set specification
listed.
A.
‘99’ represents an unlimited number.
10.7 Conditional obligation
Definition:
A description of any conditions that apply to collection of data for a specified
data element (or data set specification) within the context of a particular data
set specification.
Obligation:
Conditional completion: this attribute should be completed if the obligation
for collecting a data element (or data set specification) within a data set
specification has been set to conditional.
Creator:
Developer.
Visibility:
All users.
A.
Conditional obligation should clearly express the particular conditions
relating to when a data element (or data set specification) is to be collected as
part of a data set specification.
B.
An example of conditional obligation is where one data element is only
collected if another data element within the same data set specification has a
particular value (e.g. only collect pregnancy status when a person’s sex is
‘female’).
10.8 Information specific to this data set
Definition:
Any additional information relevant to the collection of a data item within the
context of a particular data set specification.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users that have permission to view the data element/data set specification
listed.
50
METeOR business rules for online data standard development Version 5.0
C.
This attribute is the appropriate place to document any specific information
that characterises the inclusion of a data item within a data set specification
not covered by the sequence, obligation, maximum occurrences or conditional
obligation attributes.
D.
This information should simply and clearly document what other information
is relevant to this data set. It may include the rules for subsequent data
verification or justification for the collection of a particular data item within
the data set specification.
10.9 Statistical unit
Definition:
Statistical units are the basic counting unit for a collection, meaning that a
record is created within the collection for each new occurrence of the statistical
unit.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
A.
Statistical units should reflect the actual underlying methodology of the
collection (i.e. a record is created within a data collection for each new
occurrence of the statistical unit).
B.
The field should be used to clearly identify the statistical unit of the data set
specification.
C.
Where the statistical unit is defined as a metadata item elsewhere in METeOR
(e.g. Object class, Glossary item) it should be linked using hypertext.
10.10 Implementation start date
Definition:
The date upon which the collection of data for this specific version of the data
set specification was first implemented.
Obligation:
Conditional completion: mandatory if the data set specification is also a
National Minimum Data Set (NMDS).
Creator:
Developer.
Visibility:
All users.
A.
To specify the implementation start date, select the relevant day, month and
year from the drop down lists to indicate a fully formed date (i.e., 15 February
2006).
B.
If the data set specification does not have an implementation start date (e.g. it
is not an NMDS), this attribute can be set to not applicable by ticking the
checkbox to the right of the date selector.
C.
An NMDS should be approved as a standard on a date that is that is before its
implementation start date.
METeOR business rules for online data standard development Version 6.0
51
10.11 Implementation end date
Definition:
The date upon which the collection of data for this specific version of the data
set specification was completed.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users.
A.
To specify the implementation end date, select the relevant day, month and
year from the drop down lists to indicate a fully formed date (i.e., 15 February
2006).
B.
If the data set specification does not have an implementation end date (it is not
an NMDS or is a current NMDS), this attribute can be set to not applicable by
ticking the checkbox to the right of the date selector.
52
METeOR business rules for online data standard development Version 5.0
11 Attributes specific to indicator sets
A single or multi-word designation assigned to a set of performance indicators. This appears
in the heading for each performance indicator.
Indicator sets have three attributes which are unique within METeOR: Indicator set type,
Outcome areas linked to this indicator set, and Indicators linked to this indicator set.
11.1 Indicator set type
Definition:
Refers to the origin of the Indicator set and the auspice body responsible for
defining the Indicator set.
Obligation:
Mandatory completion
Creator:
Developer.
Visibility:
All users
11.1.1
Indicator set type information
Currently there are four indicator set types. These have been developed in line with
Australian Government policy decisions. More Indicator set types may be added to METeOR
as required.
11.1.1.1 COAG-IGA
This includes indicators outlined in the Council of Australian government (COAG)
Intergovernmental Agreement (IGA) on Federal Financial Relations relevant to national
reporting on health, housing assistance and community services. The overall objective of
these agreements is the improvement of the well-being of all Australians.
Each Specific Purpose Payments (SPP) is associated with a National Agreement that contains
the objectives, outcomes, outputs and performance indicators, and clarifies the roles and
responsibilities that will guide the Commonwealth and States in the delivery of services
across the relevant sectors. COAG agreed to six new National Agreements, the National
Healthcare Agreement, National Education Agreement, National Agreement for Skills and
Workforce Development, National Disability Agreement, National Affordable Housing
Agreement, and the National Indigenous Reform Agreement.
•
National Affordability Housing Agreement
•
National Disability Agreement
•
National Healthcare Agreement
•
National Indigenous Reform Agreement
11.1.1.2
COAG-NP
COAG has agreed to a new form of payment called National Partnership (NP) payments to
fund specific projects and to facilitate and/or reward States that deliver on nationallysignificant reforms, such as:
•
Homelessness
METeOR business rules for online data standard development Version 6.0
53
•
Remote Indigenous Housing
•
Social Housing
11.1.1.3
Report on Government Services
The Review of Government Service Provision was established in 1993 by Heads of
government (now the Council of Australian Governments or COAG) to provide information
on the effectiveness and efficiency of government services in Australia. A Steering
Committee, comprising senior representatives from the central agencies of all governments,
manages the Review with the assistance of a Secretariat provided by the Productivity
Commission.
The Review aims to:
•
enable ongoing comparisons of the performance of government services
•
report on government service provision reforms that governments have
implemented or that are under consideration
Two main tasks of the Review, as set out in the original terms of reference, are to:
•
develop agreed national performance indicators for government services
(which are published in the annual Report on Government Services)
•
analyse service provision reforms.
The Review does not consider policy issues. Rather, it aims to assemble indicators of
performance given the existing policy framework of governments. The
performance measures established are to assist each government in the
formulation of its policy objectives and priorities
REF:
http://www.pc.gov.au/gsp/review
•
Aged care services
•
Disability services
•
Housing
•
Primary and community health
•
Protection and support services
•
Public hospitals
11.1.1.4
Other indicator set
This includes indicator sets which do not fit the criteria of the other data specification sets.
This may include indicator sets such as the Children’s Headline Indicator set or the Child
Protection Framework.
11.2 Outcome areas linked to this indicator set
Definition:
54
A link to a statement that specifically defines the target, standard, or the ideal
result of the indicator against which the indicator is to be assessed. Outcomes
should be strategic, high level and observable, expressed in clear, measurable
METeOR business rules for online data standard development Version 5.0
and achievable terms. Several outcome areas may be identified for each
objective.
Obligation:
Conditional obligation: only those outcome areas which implement this
indicator set as specified in the indicator are to be listed.
Creator:
Developer.
Visibility:
All users
11.3 Indicators linked to this indicator set
Definition:
A list of hyperlinks detailing the indicators associated with an indicator set.
Obligation:
Conditional obligation: only those indicators which implement this indicator
set are to be listed.
Creator:
Developer.
Visibility:
All users
METeOR business rules for online data standard development Version 6.0
55
12 Attributes specific to outcome areas
A statement that specifically defines the target, standard, or the ideal result of the indicator
against which the indicator is to be assessed. Outcomes should be strategic, high level and
observable, expressed in clear, measurable and achievable terms. Several outcome areas may
be identified for each objective.
Outcome areas have two attributes which are unique within METeOR: Indicator sets linked
to this outcome area and Indicators linked to this outcome area.
12.1 Indicator sets linked to this outcome area
Definition:
A list of hyperlinks detailing the Indicator sets associated with a specific
outcome area.
Obligation:
Conditional completion: only those indicator sets which implement this
outcome area as specified by the indicator are to be listed.
Creator:
Developer.
Visibility:
All users
12.2 Indicators linked to this outcome area
Definition:
A list of hyperlinks detailing the Indicators associated with an outcome area.
Obligation:
Conditional obligation: only those indicators which implement this outcome
area are to be listed.
Creator:
Developer.
Visibility:
All users
56
METeOR business rules for online data standard development Version 5.0
13 Attributes specific to indicators
A statistical measure used to describe the progress or performance of the health or welfare
system. This may be linked to a population or a number related to the provision of goods
and services-output.
Indicators have thirty attributes which are unique within METeOR: Indicator Type, Indicator
common name, Description, Rationale, Indicator set, Outcome area, Population group age
from, Population group age to, Computation description, Formulae, Numerator, Numerator
items, Denominator, Denominator items, Disaggregation items, Data element/Data set, Data
source, NMDS/DSS, Collection Methods/Guide for use, Framework and dimensions,
Methodology, Formulae, Reporting requirements, Organisation responsible for providing
data, Accountability, Benchmark, International comparisons, Further data
development/collection required, Other issues caveats, and Release date.
13.1 Indicator Type
Definition: The type of indicator used to describe the progress or performance of the health
or welfare system. This may be a performance indicator linked to a population or a number
related to the provision of goods and services-output.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users
13.2 Common name
Definition: A short or common name or designation by which the indicator is known and
might be identified.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users
13.3 Description
Definition: A short statistical description of an indicator. Values include percentage, count,
proportion, mean (average), and percentile.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users
METeOR business rules for online data standard development Version 6.0
57
13.4 Rationale
Definition: A designation or description of the application environment or discipline in
which an indicator is applied or from which it originates, as well as a justification for
inclusion of the indicator.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users
13.5 Indicator set
Definition: A single or multi-word designation assigned to a set of indicators. This appears in
the heading for each indicator.
Obligation:
Conditional obligation: only those indicator sets which implement this
indicator are to be listed.
Creator:
Developer.
Visibility:
All users
13.6 Outcome area
Definition: A statement that specifically defines the target, standard or the ideal result of the
performance indicator, against which performance is to be assessed. Outcomes should be
strategic, high level and observable, expressed in clear, measurable and achievable terms.
Several outcome areas may be identified for each objective.
Obligation:
Conditional obligation: only those indicators which implement this outcome
area are to be listed.
Creator:
Developer.
Visibility:
All users
13.7 Population group age from
Definition: Contextual information about a group people having approximately the same
age. Specifically, denotes the age at which the collection of information commences.
Obligation:
Optional completion.
Creator:
Developer.
Visibility:
All users
13.8 Population group age to
Definition:
Contextual information about a group people having approximately the same
age. Specifically, denotes the age at which the collection of information ceases.
Obligation:
Optional completion.
58
METeOR business rules for online data standard development Version 5.0
Creator:
Developer.
Visibility:
All users
13.9 Computation description
Definition:
The plain text description of the formulae used to calculate an indicator.
Obligation:
Conditional completion: complete for indicators that have a clearly described
calculation or formula.
Creator:
Developer.
Visibility:
All users
13.10 Computation
Definition:
A group of symbols that make a formal mathematical statement.
Obligation:
Conditional completion: complete for indicators that have a clearly described
computation or formula
Creator:
Developer.
Visibility:
All users
13.11 Numerator
Definition:
A description of the number above the line in a fraction showing how many of
the parts indicated by the denominator are taken.
The numerator may also be used to represent a count, rather than a fractional
representation. In this case the denominator should be left blank.
Obligation:
Conditional completion: complete for indicators that have a clearly described
numerator.
Creator:
Developer.
Visibility:
All users
13.12 Numerator data items
Definition:
A set of items used to calculate the numerator, including data element/data
set, data source, NMDS/DSS, and collection methods/guide for use.
Obligation:
Conditional obligation: only those data elements or data sets which
implement this indicator as a numerator are to be listed.
Creator:
Developer.
Visibility:
All users
13.13 Denominator
Definition:
A description of the number below the line in a fraction.
METeOR business rules for online data standard development Version 6.0
59
Obligation:
Conditional completion: complete for indicators that have a clearly described
denominator.
Creator:
Developer.
Visibility:
All users
13.14 Denominator items
Definition:
A set of items used to calculate the denominator, including data element/data
set, data source, NMDS/DSS, and collection methods/guide for use.
Obligation:
Conditional obligation: only those data elements or data sets which
implement this indicator as a denominator are to be listed.
Creator:
Developer.
Visibility:
All users
13.15 Disaggregation
Definition:
A description of the number that has been separated into smaller component
parts.
Obligation:
Conditional completion: complete for indicators that have a clearly described
disaggregation.
Creator:
Developer.
Visibility:
All users
13.16 Disaggregation items
Definition:
A set of items used to calculate the disaggregated output, including data
element/data set, data source, NMDS/DSS, and collection methods/guide for
use.
Obligation:
Conditional obligation: only those data elements or data sets which
implement this indicator as a disaggregation are to be listed.
Creator:
Developer.
Visibility:
All users
13.17 Data element/Data set
Definition:
A set of data elements to calculate the numerator, denominator or
disaggregation.
Obligation:
Conditional obligation: only those data elements or data sets which
implement this indicator are to be listed.
Creator:
Developer
Visibility:
All users
60
METeOR business rules for online data standard development Version 5.0
13.18 Data source
Definition:
A specific data set, database and reference from where data are sourced.
Obligation:
Conditional obligation: only those data sources that are used by this indicator
are to be listed.
Creator:
Registrar
Visibility:
All users
13.19 NMDS/DSS
Definition:
The name of the National minimum data set (NMDS) or data set specifications
(DSS) from which the data element is sourced.
Obligation:
Conditional obligation: only those data sets specifications that are used by this
indicator are to be listed.
Creator:
Developer
Visibility:
All users
13.20 Collection Methods/Guide for use
Definition:
Methods of data collection including census, sample survey, and
administrative by-product.
Obligation:
Conditional completion: complete for indicators that have a clearly described
collection method or guide for use.
Creator:
Developer
Visibility:
All users
13.21 Performance framework and dimensions
Definition:
The name of the conceptual framework which this performance indicator can
be reported against. This may include tiers and dimensions and subdimensions. A conceptual framework provides a structure to guide the
understanding and evaluation of the system (health/welfare) being
investigated.
Obligation:
Conditional obligation: only those frameworks or framework dimensions that
are used by this indicator are to be listed.
Creator:
Developer
Visibility:
All users
13.22 Methodology
Definition:
The detailed description of the formulae used to calculate a performance
indicator.
METeOR business rules for online data standard development Version 6.0
61
Obligation:
Conditional completion: complete for indicators that have a clearly described
methodology.
Creator:
Developer
Visibility:
All users
13.23 Formulae
Definition:
A group of symbols that make a formal mathematical statement.
Obligation:
Conditional completion: complete for indicators that have a clearly described
formula/e.
Creator:
Developer
Visibility:
All users
13.24 Reporting requirements
Definition:
The agreement arrangements under which the Indicator is reportable.
Obligation:
Mandatory completion.
Creator:
Developer
Visibility:
All users
13.25 Organisation responsible for providing data
Definition:
An organisation which provides indicator data.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users
13.26 Accountability
Definition:
Responsible organisation/s for developing, collecting and reporting data for
indicators.
Obligation:
Mandatory completion.
Creator:
Developer.
Visibility:
All users
13.27 Benchmark
Definition:
A standard, or point of reference, against which things can be compared,
assessed, measured or judged.
Obligation:
Conditional completion: complete for indicators that have a clearly described
benchmark.
62
METeOR business rules for online data standard development Version 5.0
Creator:
Developer.
Visibility:
All users
13.28 International comparisons
Definition:
A statement or indication of similarities and differences relating to an
indicator between Australia and other countries.
Obligation:
Conditional completion: complete for indicators that have a clearly described
international comparison.
Creator:
Developer.
Visibility:
All users
13.29 Further data development/collection required
Definition:
Describes whether the data specifications for an indicator are interim or long
term. Planned data development such as changes to definitions and
methodology indicate the indicator is an interim specification.
Obligation:
Conditional completion: complete for indicators where there is a need for
further data development or data collection.
Creator:
Developer
Visibility:
All users
13.30 Other issues caveats
Definition:
Any additional information required to interpret the data, or any other issues
or caveats which have not been reported in another field in the template.
Obligation:
Obligation:
Conditional completion: complete for indicators where there is a need to
describe other issues or caveats.
Creator:
Developer
Visibility:
All users
13.31 Release date
Definition:
The day, month and year a performance indicator is publicly released.
Obligation:
Conditional completion: complete for indicators where there is a specified
release date.
Creator:
Developer
Visibility:
All users
METeOR business rules for online data standard development Version 6.0
63
14 Attributes specific to frameworks
A conceptual framework provides a structure to guide the understanding and evaluation of
the system (health/welfare) being investigated. This may include tiers and dimensions and
sub-dimensions.
Frameworks have two attributes which are unique within METeOR: Dimension of
Framework, and Indicators in this framework.
14.1 Dimension of Framework (whether broad level
or sub-dimension).
Definition:
A concise statement that expresses the facet in which the indicator is grouped.
Typically there will be three dimensions, the child, parent and grandparent.
Obligation:
Conditional completion: complete for frameworks that have a clearly
described sub-dimension.
Creator:
Registrar
Visibility:
All users
14.2 Indicators in this framework
Definition:
Hyperlinks to the indicators which have been grouped under the framework.
The highest level dimension will display all indicators grouped under each of
the dimensions and sub-dimensions of the framework. Lower level
dimensions will only display indicators grouped to that level, and lower.
Obligation:
Conditional obligation: only those indicators that are used by this framework
or framework dimension are to be listed.
Creator:
Registrar
Visibility:
All users
64
METeOR business rules for online data standard development Version 5.0
15 Attributes specific to quality
statements
A statement of multiple quality dimensions for the purpose of assessing the quality of the
data for reporting against the PI.
Quality statements have eight attributes which are unique within METeOR: Quality
statement summary, Institutional environment, Timeliness, Accessibility, Interpretability,
Relevance, Accuracy and Coherence.
15.1 Quality statement summary
Definition:
An overview of the seven quality dimensions and a description of any specific
strengths and/or limitations.
Obligation:
Mandatory completion.
Creator:
Developer
Visibility:
All users
15.2 Institutional environment
Definition:
The institutional and organisational factors which may impact on the
effectiveness and credibility of the agency producing the statistics.
Obligation:
Mandatory completion.
Creator:
Developer
Visibility:
All users
15.3 Timeliness
Definition:
measured.
The delay to which the information correctly describes the phenomena being
Obligation:
Mandatory completion.
Creator:
Developer
Visibility:
All users
15.4 Accessibility
Definition:
The ease with which the information can be obtained.
Obligation:
Mandatory completion.
Creator:
Developer
Visibility:
All users
METeOR business rules for online data standard development Version 6.0
65
15.5 Interpretability
Definition:
The availability of the supplementary information necessary to interpret the
statistical information.
Obligation:
Mandatory completion.
Creator:
Developer
Visibility:
All users
15.6 Relevance
Definition:
The degree to which information meets the needs of users.
Obligation:
Mandatory completion.
Creator:
Developer
Visibility:
All users
15.7 Accuracy
Definition:
The degree to which the information correctly describes the phenomena being
measured.
Obligation:
Mandatory completion.
Creator:
Developer
Visibility:
All users
15.8 Coherence
Definition:
The degree to which the information can be brought together with other
information, and over time.
Obligation:
Mandatory completion.
Creator:
Developer
Visibility:
All users
66
METeOR business rules for online data standard development Version 5.0
16 Attributes specific to data sources
A specific data set, database and reference from where data are sourced.
Data sources have four attributes which are unique within METeOR: Link to data source,
Frequency, Data custodian and Data custodian contact details.
16.1 Link to data source
Definition:
Hyperlink or address of the data source.
Obligation:
Conditional completion: complete for data sources that have a clearly
described electronic link.
Creator:
Registrar
Visibility:
All users
16.2 Frequency
Definition:
The recommendation of frequency at which a data collection is conducted.
Obligation:
Conditional completion: complete for data sources that have a clearly
described frequency of collection.
Creator:
Registrar
Visibility:
All users
16.3 Data custodian
Definition:
A person that ensures that data holdings are properly documented,
maintained, controlled and accessed.
Obligation:
Mandatory completion.
Creator:
Registrar
Visibility:
Restricted
16.4 Data custodian contact details
Definition:
The primary contact person’s name and organisation, and avenue of contact
such as postal address, email address, website or telephone number.
Obligation:
Mandatory completion.
Creator:
Registrar
Visibility:
Restricted
METeOR business rules for online data standard development Version 6.0
67
17 Notes
Notes is a field in which the Developer of a metadata item and the Registrar can provide
iterative comments on a metadata item.
17.1 Notes
Definition:
Suggestions and or justification for any changes to an item.
Obligation:
Optional completion.
Creator:
Registrar and Developers with edit permissions for the workgroup that the
item resides in.
Visibility:
Registrar and Developers with edit and/or view permissions for the
workgroup that the item resides in.
17.1.1
Rules common to all metadata items
A.
Notes cannot be edited or removed once saved.
B.
Notes should be expressed precisely and unambiguously.
68
METeOR business rules for online data standard development Version 5.0
18 Attributes specific to object class
specialisations
An object class specialisation exists where an object class (known as the parent object class)
has one or more sub-typed object classes (known as child object classes). This structure
allows the building a hierarchy of object classes, from specialised to generic.
An object class specialisation has four attributes: Name of object class specialisation,
Description of object class specialisation, Parent, and Children.
All object classes should be linked to an object class specialisation before they receive a
candidate registration status.
18.1 Name of object class specialisation
Definition:
A designation assigned to an object class specialisation.
Obligation:
Mandatory completion.
Creator:
Registrar only.
Visibility:
All users.
A.
The concatenation of the parent object class name, followed by a space, and the name
of the facet capitalised and enclosed in brackets. For example, where the parent object
class name is Person and the facet name is Sex, the name should read: Person (Sex)
18.2 Description of object class specialisation
Definition:
A concise statement that expresses the facet by which the object class is
specialised.
Obligation:
Mandatory completion.
Creator:
Registrar only.
Visibility:
All users.
No rules defined.
18.3 Parent
Definition:
The name of the object class from which one or more object classes are subtyped.
Obligation:
Mandatory completion.
Creator:
Registrar only.
Visibility:
All users.
A.
Only one parent may be specified.
METeOR business rules for online data standard development Version 6.0
69
18.4 Children
Definition:
The name of any object classes which are sub-types of a parent object class.
Obligation:
Mandatory completion.
Creator:
Registrar only.
Visibility:
All users.
No rules defined.
70
METeOR business rules for online data standard development Version 5.0
19 Attributes specific to property groups
Property groups are a tool for grouping all the properties that describe similar
characteristics. For example, the properties Body weight and Body Height are both grouped
into the property group Physical characteristics. Each property can only belong to a single
property group.
A property group has three attributes: Name of property group, Description of property
group, and List of properties.
19.1 Name of property group
Definition:
A single or multi-word designation assigned to a property group.
Obligation:
Mandatory completion.
Creator:
Registrar only.
Visibility:
All users.
No rules defined.
19.2 Description of property group
Definition:
A concise statement that expresses the essential nature of the property group
and its differentiation from other object class specialisations.
Obligation:
Mandatory completion.
Creator:
Registrar only.
Visibility:
All users.
No rules defined.
19.3 List of properties
Definition:
A list of all properties associated with the property group.
Obligation:
Mandatory completion.
Creator:
Registrar only.
Visibility:
All users.
No rules defined.
METeOR business rules for online data standard development Version 6.0
71
20 Referencing guidelines
This section provides rules for the appropriate formatting of references used within the text
of metadata items. These are based on the AIHW publication style guides that are regularly
used to format the national data dictionaries.
20.1 In-text references
A.
In-text citations should follow one of the following formats:
i.
[Left bracket+] Author [+space +] year of publication [+right bracket + page
number(s) if applicable]
ii.
Author [+space + left bracket +] year of publication [+right bracket + page
number(s) if applicable]
B.
When citing a classification scheme or other document which is better known by a
short title, use the short title for the in-text citation e.g. ICD-10-AM 6th edition.
C.
The short, formal title of a piece of legislation should be cited exactly, in full, and in
italics, followed by the jurisdiction (abbreviated and enclosed in parentheses) e.g. Health
Insurance Act 1973 (Cwlth).
20.2 Reference list
References within the Origin and Reference documents attributes should be listed using the
following guidelines:
A.
If more than one publication is cited that was published in a given year and written
by the same author, append the date with a lower case letter to the date in the in-text
reference e.g. ‘(Rose 1984a)’ and in the full reference e.g. ‘Rose G 1984a…’.
B.
If a reference has two authors, join the names with an ampersand (&) in the in-text
reference e.g. ‘(Rose & Smith 1984)’ and in the full reference e.g. ‘Rose G & Smith A
1984…’.
C.
Append the first author with the term ‘et al.’ in an in-text reference which has three or
more authors e.g. ‘(Rose et al. 1984)’ or ‘Rose et al. (1984).’ In the full reference,
append the first author with the term ‘et al.’ only if there are more than six authors
e.g. ‘Rose G et al. 1984…’.
D.
Acronyms may be used for organisation names: in an in-text reference, the acronym is
the author e.g. ‘(AIHW 1997),’ in the full reference, list the acronym, followed by the
full name of the organisation enclosed in brackets e.g. ‘AIHW (Australian Institute of
Health and Welfare) 2001…’.
E.
Provide page numbers only when it is deemed necessary to guide readers to the
quoted material e.g. when quoting from a long document or when summarising an
entire publication.
F.
In-text references to legislation are sufficient – do not reference legislation in full in
either the Origin or Reference document attribute.
72
METeOR business rules for online data standard development Version 5.0
20.2.1
A.
Journals
Author [space +] year of publication [full stop + space] title [full stop + space] journal
name [space] volume number [colon] page numbers [full stop]
For example:
Rose G 1984. International trends in cardiovascular disease: implications for
prevention and treatment. Australia New Zealand Journal of Medicine 14:375–80.
20.2.2
A.
Books
Author [space +] year of publication [full stop + space] title [full stop + space] place of
publication [colon + space] publisher [comma + space] page numbers
For example:
Brennan D 1994. The politics of Australian child care: from philanthropy to feminism.
Melbourne: Cambridge University Press
National Centre for Classification in Health 2008. The International statistical
classification of diseases and related health problems, tenth revision, Australian
modification (6th edn). Sydney: National Centre for Classification in Health, Faculty
of Health Sciences, The University of Sydney
20.2.3
Electronic
20.2.3.1
Website
A.
Author [space +] year the site was created or last revised [full stop + space] the name
of the sponsor of the source [comma + space] place of the sponsor of the source [full
stop + space + Viewed] day, month and year viewed [+ comma + space + less than
sign] URL [greater than sign]
For example:
Department of Finance and Administration 2001. Department of Finance and
Administration, Canberra. Viewed 7 August 2001, <http://www.finance.gov.au>
20.2.3.2
A.
Document within a website
Author [space] year the most recent version of the document was created [full stop +
space] the title of document (comma + space + version number if applicable) [full stop
+ space +] sponsor of the source [+ comma +] place of the sponsor of the source [full
stop + space] description of document if applicable [full stop + space + Viewed] day,
month and year viewed [+ comma + space + less than sign] URL [greater than sign]
For example:
International Narcotics Control Board 1998. International Narcotics Control Board
report for 1998. United Nations, Vienna. Viewed 1 October 1999,
<http://www.incb.org/e/index.htm>
METeOR business rules for online data standard development Version 6.0
73
20.2.3.3
A.
Electronic email list, Usenet group and bulletin board
Author [space +] <author email address> [space +] year of posting [full stop + space]
title of posting [full stop + space +] description of posting [comma + space] day,
month and year viewed [+ comma + space + less than sign] URL [greater than sign]
For example:
Murphy L <[email protected]> 2000. News for old hacks. List server, 20
January 2000. National Journalists Association. Viewed 7 February,
http://www.nja.net.au/listserv/
74
METeOR business rules for online data standard development Version 5.0
Appendix 1: Format examples
Table 9: Examples of values to be represented and their associated format
Values to be represented
Representation format
Examples
5 alphabetic characters are required,
followed by up to 2 numeric characters.
AAAAA[NN]
AAAAA or
AAAAAN or
AAAANN
Up to 6 alphabetic characters, followed
by up to 2 numeric characters. Note: this
format accepts blank entries.
[AAAAAANN]
A
AA
AAA
AAAA
AAAAA
AAAAAA
AAAAAAN
AAAAAANN
AN
AAN
AAAN
etc or
blank
Either 1 alphabetic character or 4
alphabetic characters are required.
A{AAA}
Either 1, 2, 3 or 4 alphabetic characters
are required:
A[AAA]
A or
AAAA
A or
AA or
AAA or
AAAA
15 alphanumeric characters are
required.
X(15)
XXXXXXXXXXXXXXX
Up to 15 alphanumeric characters.
[X(15)]
X or
XX or
XXX or
XXXX or
XXXXX
or etc
or blank
2 numeric characters are required,
followed by up to 3 alphabetic
characters, and 4 required alphabetic
characters.
NN[AAA]AAAA
NNAAAA or
NNAAAAA or
NNAAAAAA or
NNAAAAAAA
1 alphabetic character followed by 1
numeric character is required, followed
by a either a full stop and up to 2
numeric characters or nothing.
AN{.N[N]}
1 alphabetic character, followed by 1
numeric character, a full stop, and 1
numeric character is required, followed
by up to 1 numeric character.
AN.N[N]
AN or
AN.N or
AN.NN
AN.N or
AN.NN
METeOR business rules for online data standard development Version 6.0
75
Values to be represented
Representation format
Examples
Either 9 numeric characters and 1
alphabetic character or nothing.
{N(9)A}
NNNNNNNNNA or
Up to 3 numeric characters followed by
up to 1 alphabetic character
[NNNA]
blank
N or
NN or
NNN or
NNNA or
NA or
NNA or
A or
blank
6 numeric characters are required,
followed by either 2 alphabetic
characters or nothing.
76
NNNNNN{AA}
NNNNNN or
NNNNNNAA
METeOR business rules for online data standard development Version 5.0
21 Appendix 2
A data element cluster is a grouping of data elements and is used to describe how some data
elements relate to each other for a specific purpose. A data element cluster will have a
statement that describes how the data elements are to be collected in relation to each other. It
can be included in a data set specification when there is a need to better describe a group of
data elements and how they should be collected or reported.
The purpose of a data element cluster is to provide additional understanding of how data
elements are to be collected and interpreted. The implementation of data element clusters
will assist developers, users and reviewers of data set specifications through the clear
explanation of its purpose, what is to be collected and how it fits into the data set.
Data elements contained in a data element cluster could be common to any business that
collects information on that subject/specialty and it will establish general standards at
cluster level. Not all subjects would need to have a generic cluster, and generic clusters
would not need to include all possible data elements that describe the subject.
Criteria for endorsing a data element cluster
A data element cluster will contain data elements according to the criteria agreed by the data
committee. There are two types of data clusters that have been identified.
Matched data element cluster
To be used when data is to be reported for the purpose of cross classificatory data collection.
The use of a data cluster in this instance reduces the number of data elements in a data set
specification. For example data to be collected in the same format such as expenditure on
various types of health services can be expressed using two data elements. The first data
element in the data element cluster represents the types of health services provided and the
second data element represents expenditure in dollars. The two data elements can then be
collected together to obtain the amount of expenditure on the types of health services when
they are included in a data element cluster.
Example of a matched data element cluster
Gross capital expenditure (accrual accounting) data element cluster
Establishment—gross capital expenditure types (accrual accounting), code N[N]
Establishment—gross capital expenditure (accrual accounting) (financial year), total Australian currency N[N(8)]
Common data element cluster
The criteria for establishing this type of data cluster is where data elements are to be reported
in conjunction with each other in a particular data set. For example collecting clinical data
about an electrocardiogram requires information about the date and time of the test as well
as a number of indicators regarding the presence of absence of abnormalities. This data
cluster can be included in the data set for Acute Coronary Syndrome.
Example of a common data element cluster
Electrocardiogram data element cluster
Electrocardiogram—electrocardiogram date, DDMMYYYY
Electrocardiogram—electrocardiogram time, hhmm
Electrocardiogram—electrocardiogram bundle-branch block indicator, yes/no code N
Electrocardiogram—electrocardiogram bundle-branch block location, code N
METeOR business rules for online data standard development Version 6.0
77
Electrocardiogram—electrocardiogram bundle-branch block status, code N
Electrocardiogram—electrocardiogram change location, code N
Electrocardiogram—electrocardiogram change type, code N
Electrocardiogram—electrocardiogram lead V4R indicator, yes/no code N
Electrocardiogram—electrocardiogram Q waves indicator, yes/no code N
Electrocardiogram—electrocardiogram Q waves, code N
Electrocardiogram—electrocardiogram ST-segment elevation in lead V4R indicator, yes/no code N
Electrocardiogram—heart rhythm type, code N[N]
Specification for a Data Element Cluster in METeOR
A data element cluster:
•
Is a set of data elements to be included in a data set specification.
•
Must be endorsed by the management group in the relevant sector/s of community
services, health or housing assistance.
•
Includes a reference to one or more organisations responsible for the submission of
the data element cluster for national endorsement as a standard.
•
Must include a description of the circumstances under which the collection of
specified data are required or recommended. The scope should be expressed
precisely and unambiguously so that the specified data can be collected under the
same circumstances by different data collectors. The statement should clearly
identify the relationship between the data elements included in the data element
cluster.
•
Has a unique identifier automatically generated by METeOR.
•
Has a list the data set specifications that implement the data element cluster.
•
Must only include data elements.
•
Must have a list of the data elements which are included the data element cluster and
must have at least two data elements.
•
Must be a subset of a data set specification.
78
METeOR business rules for online data standard development Version 5.0
Example of a proposed data element cluster in a data set downloaded from METeOR
Government expenditure NMDS
Metadata items in this Data Set Specification
Seq
No.
Metadata item
-
Gross capital expenditure (accrual accounting) data
element cluster
A data element cluster appears at the
Obligation
Max
occurs
Mandatory
1
top of the items included in a data set
or NMDS.
Establishment—gross capital
expenditure types (accrual accounting)
Data elements
Establishment—gross capital
expenditure (accrual accounting)
(financial year)
directly under the
included in the data
element cluster listed
name of the cluster
Government health expenditure provider
expenditure data cluster
Health industry relevant provider—
organisation main activity type, code
NNN
Organisation—type of health or health
related function, code NNN
Organisation—expenses, total
Australian currency NNNNN.N
METeOR business rules for online data standard development Version 6.0
79
References
ISO/IEC (International Standards Organization/International Electrotechnical Commission)
2004. Information technology—Metadata registries (MDR)—Part 1: Framework (2nd edn
2004-09-15), Geneva, Switzerland: ISO/IEC.
ISO/IEC (International Standards Organization/International Electrotechnical Commission)
2000. Information technology—Specification and standardization of data elements — Part 2:
Classification for data elements (1st edn 2000-02-15), Geneva, Switzerland: ISO/IEC.
ISO/IEC (International Standards Organization/International Electrotechnical Commission)
2003. Information technology—Metadata registries (MDR)—Part 3: Registry metamodel and
basic attributes (2nd edn 2003-02-15 Incorporating COR1), Geneva, Switzerland: ISO/IEC.
ISO/IEC (International Standards Organization/International Electrotechnical Commission)
2004. Information technology—Metadata registries (MDR)—Part 4: Formulation of data
definitions (2nd edn 2004-07-15), Geneva, Switzerland: ISO/IEC.
ISO/IEC (International Standards Organization/International Electrotechnical Commission)
1995. Information technology—Specification and standardization of data elements —Part 5:
Naming and identification principles for data elements (1st edn 1995-I 2-01), Geneva,
Switzerland: ISO/IEC.
ISO/IEC (International Standards Organization/International Electrotechnical Commission)
2005. Information technology—Metadata registries (MDR)—Part 6: Registration (2nd edn
2005-01-15), Geneva, Switzerland: ISO/IEC.
ISO/IEC (International Standards Organization/International Electrotechnical Commission)
2004. Information technology—Metadata interoperability and bindings (MDIB)—Part 002:
Common vocabulary (ISO/IEC CD 20944-002 Release sequence #6), Geneva, Switzerland:
ISO/IEC. Viewed 23 July 2004, <http:www.jtc1sc32.org/>.
ISO (International Standards Organization) 2000. ISO 8601:2000 Data elements and
interchange formats -- Information interchange -- Representation of dates and times (2nd edn
2004-12-03). International Organization for Standardization, Geneva, Switzerland: ISO/IEC.
International Bureau of Standard Weights and Measures 2004. Sizes, Inc., California, United
States of America. Viewed 3 August 2004, <http://www.sizes.com/units/meter.htm>.
80
METeOR business rules for online data standard development Version 5.0
List of tables
Table 1: Registration status values, their associated meanings, valid administration status values and
the workflow action required to achieve this value ................................................................... 22
Table 2: Definition templates for value domains ............................................................................................ 24
Table 3: Related metadata values and their associated meaning ................................................................. 29
Table 4: Examples of properties and their association with object classes .................................................. 35
Table 5: Representation class values and their associated meaning ............................................................ 40
Table 6: Data type values and their associated meaning ............................................................................... 40
Table 7: Format values and their associated meaning ................................................................................... 41
Table 8: Example units of measure classified by measure ............................................................................. 44
Table 9: Examples of values to be represented and their associated format ............................................... 75
METeOR business rules for online data standard development Version 6.0
81