Overview of the SKL
===================

The data model for all mental health data sets includes a hierarchy
describing the layers of mental health service delivery systems, for
example, regional and organisational levels, and is an important design
feature of the mental health collections. Ideally, the hierarchy reported
by jurisdictions should be repeated among their various mental health data
collections.

The Mental Health Information Strategy Standing Committee (MHISSC), and its
National Minimum Data Set Subcommittee, agreed to a number of key
principles to scrutinise the hierarchies reported in the various mental
health data sets. In essence, the committees agreed to provide a ‘Skeleton’ of the Mental
Health Establishments (MHE) National Minimum Dataset (NMDS), to be known as
an SKL dataset, at the same time in the reporting cycle as the Community
Mental Health Care and Residential Mental Health Care NMDSs, and the
National Outcomes and Casemix Collection (NOCC). This ‘Skeleton’ is
considered the ‘gold standard’ against which all other mental health data
files are compared, including the CMHC, RMHC, NOCC and MHE files.

The Online Validator supports the mental health collections as the vehicle for
checking data submissions and provides the necessary interactive space for
discussions about data issues between various stakeholders. The Online
Validator has the capacity to check the hierarchy between collections, as
well as identifying changes compared to previous submissions, using the
comparisons with the SKL file.

The purpose of this module is to outline the layout and format of the
Mental Health Establishments Skeleton (SKL) dataset to be submitted by
States and Territories to the Australian Institute of Health and Welfare
(AIHW) and Department of Health, Disability and Ageing in respect of the |current-year| year. The
file is identical in structure to an MHE file, however, is limited to key
components of the MHE file in order to facilitate the ‘between-data set’
comparisons.

Changes for |current-year|
--------------------------

The specific detailed changes
to the |current-year| (version |version|) specifications, compared to |previous-year| (version |previous-version|) are listed below.

Changes to the data model
^^^^^^^^^^^^^^^^^^^^^^^^^

.. No changes to the data model have been made.

The data model changes to the |current-year| specifications, compared to |previous-year| are listed in :numref:`table-data-model-changes`.

 .. _table-data-model-changes:

 .. csv-table:: Changes made to |current-year| data model compared to |previous-year|
    :file: data-model-changes.csv
    :header-rows: 1


Changes to definitions
^^^^^^^^^^^^^^^^^^^^^^

.. No changes have been made to any of the relevant definitions.

The definitional changes to the |current-year| specifications, compared to |previous-year| are listed in :numref:`table-changes`.

 .. _table-changes:
 .. csv-table:: Changes made to |current-year| definitions compared to |previous-year|
    :file: changes.csv
    :header-rows: 1


Principles and agreements
-------------------------

The SKL submission has been built using the following principles.

.. _principles-and-agreements:

.. csv-table:: SKL principles
   :file: principles-and-agreements.csv
   :header-rows: 1

Comparisons
-----------

The following comparisons between the SKL and other data sets
are made in the Online Validator. Comparisons between data sets are made
only on those entities that are logical to compare. For example, an
organisation in the SKL may only have admitted and ambulatory
services. In this case, a check for the existence of a service unit
between the SKL and the RMHC file would not be logical.

Region and organisation level comparisons
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Regional and organisation entity matching is considered a minimum
requirement, regardless of the collections being compared.

SKL vs. RMHC service unit level comparisons
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

SKL vs. RMHC comparisons will be made according to the following.

+------------------------+------------------------+----------------------+
| Analysis level         | SKL data element       | RMHC data element    |
+========================+========================+======================+
| Region level           | RegId                  | RegId                |
+------------------------+------------------------+----------------------+
| Organisational level   | RegId, OrgId           | RegId, OrgId         |
+------------------------+------------------------+----------------------+
| Service unit           | RegId, OrgId, ResiId   | RegId, OrgId, SUId   |
+------------------------+------------------------+----------------------+

SKL vs. CMHC service unit level comparisons
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

SKL vs. CMHC comparisons will be made according to the following.

+------------------------+---------------------------------+--------------------------------+
|                        | SKL data element                | CMHC data element              |
+========================+=================================+================================+
| Region level           | RegId                           | RegId                          |
+------------------------+---------------------------------+--------------------------------+
| Organisational level   | RegId, OrgId                    | RegId, OrgId                   |
+------------------------+---------------------------------+--------------------------------+
| Service unit level     | RegId, OrgId, AMBU\_TargetPop   | RegId, OrgId, SERV.TargetPop   |
+------------------------+---------------------------------+--------------------------------+

SKL vs. NOCC entity comparisons
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

SKL vs. NOCC comparisons will be made according to the following.

+----------------------------+---------------------------------+--------------------------------------------+
| Analysis level             | SKL data element                | NOCC data element                          |
+============================+=================================+============================================+
| Region level               | RegId                           | RegId                                      |
+----------------------------+---------------------------------+--------------------------------------------+
| Organisational level       | RegId, OrgId                    | RegId, OrgId                               |
+----------------------------+---------------------------------+--------------------------------------------+
| Hospital level             | RegId, OrgId, HospId            | RegId, OrgId, HospId                       |
+----------------------------+---------------------------------+--------------------------------------------+
| Admitted service unit      | RegId, OrgId, AdmiId            | RegId, OrgId, SUId, SUType=1               |
+----------------------------+---------------------------------+--------------------------------------------+
| Residential service unit   | RegId, OrgId, ResiId            | RegId, OrgId, SUId, SUType=2               |
+----------------------------+---------------------------------+--------------------------------------------+
| Ambulatory service unit    | RegId, OrgId, AMBU\_TargetPop   | RegId, OrgId, (SUId\_Targetpop,SUType=3)   |
+----------------------------+---------------------------------+--------------------------------------------+

Data Integrity
^^^^^^^^^^^^^^^

For cases of missing data (that is, unknown, not stated or not
available):

-  For **Numeric [Num] fields**, the data should be reported as zero,
   using leading zeros when necessary to pad out the field to the
   required length. The principle here is that all numeric fields
   require a valid value.

-  For **Text [Char] fields**, the data should be space-filled to the
   required length. For single character fields where a ‘missing/not
   stated’ value has been specified for a particular data element (for
   example, ‘9’ has been specified for missing data), use the stated
   value for ‘missing/not stated’ rather than simply space filling.

Values in **Date** [**Date**] fields must be recorded in compliance with
the standard format used across the *National health data dictionary*;
specifically, dates must be of fixed 8 column width in the format
DDMMYYYY, with leading zeros used when necessary to pad out a value. For
instance, 13 March |end-year| would appear as 1303\ |end-year|.

Values in **Numeric** [**Num**] fields must be zero-filled and
right-justified. These should consist only of the numerals 0 to 9 and
the decimal (’.’) point if applicable to the data element.

Note: Fields defined as ‘Numeric’ are those that have numeric
properties—that is, the values, for example, can be added or subtracted
in a manner that is valid. Where a field uses numeric characters that do
not have these properties (for example, the use of numbers for *Patient
identifier*), the field is defined as ‘Character’.

Values in **Character** [**Char**] fields must be left justified and
space-filled. These should consist of any of the printable ASCII
character set (that is, excluding control codes such as newline, bell
and linefeed).

Dataset specifications (DSS)
----------------------------

The following tables specify the order in which the data items should be
provided to the AIHW.

The extract format consists of a set of hierarchically ordered *Data
records*, of which there are fourteen types (see :numref:`table-record-types`).
In each extract file for any given period, the *Data records* must be
preceded by a single *File Header Record* having the structure outlined
in :numref:`table-records/hr`.

All records presented in the extract file should be grouped in the
following order: Header Record; State/Territory details records; State MH NGO details records; Region
details records; Region MH NGO details records; Organisation details records; Organisation full-time
equivalent staff by service setting details records; Hospital/Service
unit cluster details records; and Service unit details records.

With the exception of State MH NGO, Region, Region MH NGO, Organisation and Service unit cluster
details records, all data records should include the following elements
in the order shown:

-  Record type

-  Establishment identifier (comprising: *State/Territory identifier;
   Region identifier*; *Organisation identifier*; *Hospital
   identifier/Service unit cluster identifier*; and *Service unit
   identifier*)

-  Specific data in the format specified for the given record type.

The State MH NGOE and Region MH NGOE payments records use different Establishment identifier compositions: 

- State MH NGOE: State/Territory identifier; and Mental health non-government organisation identifier

- Region MH NGOE: State/Territory identifier; Region identifier; and Mental health non-government organisation identifier

The order of fields in a record must be the same as the order they are
listed in the Record Layouts specified below. Field values should be
formatted as specified in the Record Layouts.

The first field in each record must be *Record Type*. Valid values for
*Record Type* are shown in :numref:`table-record-types`.

.. _table-record-types:

.. csv-table:: Valid values for Record Type
   :file: record-types.csv
   :header-rows: 1

NGOE records may be supplied but do not contribute to the SKL checking processes.

File header record
^^^^^^^^^^^^^^^^^^

The first record of the extract file must be a File Header Record
(*Record Type* = ‘HR’), and it must be the only such record in the file.

The File Header Record is a quality control mechanism, which uniquely
identifies each file that is submitted to the Online Validator.

The layout of the File Header Record is shown in :numref:`table-records/hr`.

.. _table-records/hr:

.. csv-table:: Record Layout for File Header Record within the data extract Data record layout
   :file: records/hr.csv
   :header-rows: 1

.. include:: records/hr-notes.rst

State/Territory data record
^^^^^^^^^^^^^^^^^^^^^^^^^^^

The extract format for the *Data records* is specified in detail in
:numref:`table-records/st` to :numref:`table-records/resi`. The order of fields in each record must be the same
as the order they are shown below. Field values should be formatted as
specified.

.. _table-records/st:

.. csv-table:: Data record layout - State/Territory details
   :file: records/st.csv
   :header-rows: 1

.. include:: records/st-notes.rst

State MH NGO details record
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - State MH NGO details
   :file: records/stngo.csv
   :header-rows: 1

.. include:: records/stngo-notes.rst

State MH NGOE Payments data record
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - State MH NGOE Payments
   :file: records/stngoe.csv
   :header-rows: 1

.. include:: records/stngoe-notes.rst

Region data record
^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - Region details
   :file: records/reg.csv
   :header-rows: 1

.. include:: records/reg-notes.rst

Region MH NGO details record
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - Region MH NGO details
   :file: records/regngo.csv
   :header-rows: 1

.. include:: records/regngo-notes.rst

Region MH NGOE Payments data record
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - Region MH NGOE Payments
   :file: records/regngoe.csv
   :header-rows: 1

.. include:: records/regngoe-notes.rst

Organisation data record
^^^^^^^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - ​Organisation Details
   :file: records/org.csv
   :header-rows: 1

.. include:: records/org-notes.rst

Organisation: FTE staff by Service Setting data record
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - ​Organisation: FTE staff by Service Setting data record
   :file: records/fteorg.csv
   :header-rows: 1

.. include:: records/fteorg-notes.rst

Hospital data record
^^^^^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - ​Hospital details
   :file: records/hosp.csv
   :header-rows: 1

.. include:: records/hosp-notes.rst

Service Unit Cluster data record
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - ​Service Unit Cluster Details
   :file: records/clus.csv
   :header-rows: 1

.. include:: records/clus-notes.rst

Admitted Patient Service Unit data record
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - ​Admitted Patient Service Unit Details
   :file: records/admi.csv
   :header-rows: 1

.. include:: records/admi-notes.rst

Ambulatory Service Unit data record
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. csv-table:: Data record layout - ​Ambulatory Service Unit Details
   :file: records/ambu.csv
   :header-rows: 1

.. include:: records/ambu-notes.rst

Residential Service Unit data record
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. _table-records/resi:

.. csv-table:: Data record layout - ​Residential Service Unit Details
   :file: records/resi.csv
   :header-rows: 1

.. include:: records/resi-notes.rst


Data elements
-------------

.. include:: records/data-elements.rst

Virtual elements
----------------

.. include:: records/virtual-elements.rst

Rules
-----

.. include:: records/rules.rst