Returns – setup and change

The pattern of data returns across the sector is fairly well established though data requirements are continually evolving; some level of annual change is normal and many of the major collections undergo major review and re-write every few years. Whether it is a new collection or a change to an existing collection, the broad stages of preparation are the same.

Understanding the specification

Data collectors publish the specification of the data that must be submitted and all submitting institutions must build an understanding of this specification.

For an individual data collection this burden is consistent across all institutions.

Individual data collecting organisations can minimise the burden associated with this stage of the process by:

  • Publishing high-quality documentation that is clear, unambigous and easy to navigate.
  • Publishing details of the quality assurance applied to the return.
  • Publishing details of how the data will be used.
  • Publishing the data specification well in advance of the collection, ensuring enough time for changes to systems and business processes to be implemented and tested.
  • For changes to existing collections, publishing a summary of changes.
  • Supporting the specification through the provision of a high-quality helpdesk service.
  • Supporting the specification through the provision of high-quality training and/or webinars.

Institutions need to build this understanding for each data collection that they are required to submit to. Therefore institutions have to deal with all of the differences – intentional or otherwise – between specifications. For each institution this burden will vary depending on which data collections they submit to and the extent to which these data specifications are consistent in content, presentation and support.

Collectively, data collecting organisations can minimise the burden associated with this stage of the process by:

  • Standardising the data specification and the terminology used to describe it.
  • Standardising the approach to presenting data specification documentation.

Defining how to build the return

Once the data specification is understood, the institution needs to work out how the requirements of the return will be met. This will typically involve reviewing data that the institution already captures and processes in order to establish:

  • Which elements of the data return can be satisfied directly from existing data.
  • Which elements of the data return can be satisfied through derivations or computations from existing data.
  • Which elements of the data return will require additional data capture and processing; how this additional data will be captured, processed and assured.

For each institution this burden will vary according to:

  • The extent to which the institutions provision neatly fits within the coding structures of the data specification; the issue of fit.
  • The extent to which the institution already captures the types of data that are included in the data specification; the issue of scope.

Both scope and fit are significantly random factors in the assessment of burden.

System development

The final element of burden in this section is the work involved in updating and testing the systems necessary to process and generate the data for the return.

For each data collection at each instituition this burden will vary according to:

  • The type of computer systems used for managing data and generating returns
  • The extent to which external reporting requirements are supported by systems suppliers
  • The extent of the changes required
Back to the data burden projectNext: Returns – data processes