About

Scope of the dataset specifications

This dataset specification aims to leave registries as much flexibility as possible for their individual considerations and local requirements, whilst providing clear guidance and precise requirements wherever necessary. Several things are deliberately not restricted by this dataset:

  • The dataset does not prevent registries from collecting further data. They are free to include any items not listed here.
  • The dataset does not specify a data collection form. Although example forms are given to illustrate the dataset and provide a starting point for implementation, registries are free to choose the structure and wording for their forms as they see fit. There are often multiple ways to capture some information and registries should identify the best solution for their requirements.
  • The dataset does not require registries to use a specific storage format or database structure. Although the items and records suggest a structure which is also used in the interactive example forms, registries will usually need to store further data. For example, many questions on a data collection form will have an “Unknown” option which is important for registries to track form completion, but which is not specified in the dataset. Similarly, it is often helpful to include further questions such as “Was an anti-AAV9 antibody test performed? (yes/no)” which lead to further questions being shown, even though the yes/no question does not correspond to an item in the dataset.

Conventions

This document describes the requirements for a registry conforming to the TREAT-NMD core datasets. TGDOC registries must inform TGDOC if they are not conforming to any mandatory requirements. Several keywords are used throughout the document to describe these requirements. When set in italics (e.g. “should”), the keywords are defined as follows:

  • must” or “required” or “shall“: specifies an absolute requirement for any registry conforming to this dataset
  • must not” or “shall not”: specifies an absolute prohibition for any registry conforming to this dataset
  • should” or “recommended”: specifies a recommendation that conforming registries should generally adhere to, but which may be disregarded if there are valid reasons to do so
  • should not” or “not recommended”: specifies something that conforming registries should generally not do, but this advice may be disregarded if there are valid reasons.
  • may” or “optional”: specifies a possibility which is truly optional and which a registry may freely decide to follow or not

These definitions closely follow the internet standard RFC 2119, but use italics instead of upper case to ease reading.

  • “Individual” refers to the registered person with the neuromuscular disease.
  • “Caregiver” refers to the parent or legal guardian who is providing responses on behalf of the individual.
  • “Clinician” refers to any healthcare professional working in clinic (for example physician, physiotherapist) who is providing data on behalf of individuals.
  • “Patient-reported (PR) registries”: all data are collected directly from patients with no data provided by clinicians. Data should be checked/verified wherever possible by the Registry Curator or team (for example by reviewing clinical notes or reports if available).
  • “Clinician-reported (CR) registries”: all data are provided via clinicians with no data collected directly from patients. Data could be entered into the registry directly by the clinicians, or by Registry Curators/other staff after review of clinical notes/reports or other health record systems.
  • “Dual-reported (DR) registries”: Some data in the registry are collected directly from patients, and some data are provided by clinicians as described above.
  • In this dataset specification, “baseline” or “baseline entry” always refers to the first data recorded for any given item or record, for an individual in the registry. “Update” refers to any subsequent data entries.

This dataset specification often uses the term “collect” or “capture”, for example “registries must collect the surgery date”. Collecting or capturing some information means including a question in a data collection form (or gathering it by other means) and having the possibility to store and use the information. It does not mean that this information must be present for all individuals. Certain things may be unknown to a data provider or may not be applicable in a certain context, and this should not interfere with the collection or usage of any other data.

A group is a collection of related items and records; previously called a “Section” in version 1 of the SMA dataset. Although this specification attempts to present the groups and their components in a logical order, neither the order nor the grouping itself is binding. A registry may use the groups and the order provided here as guidance for their data collection forms, but may also choose any other grouping or order. This also applies to the order of items within a record (see below for an explanation of items and records).

When this document refers to the ID of an item or record, the ID is set in a monospace font (e.g. Scoliosis surgery).

Data submission to TREAT-NMD

Schedule: Currently registries are asked to submit data to TREAT-NMD on an ad-hoc basis; when needed to respond to a 3rd party enquiry into the global registry.

Data: Currently registries are only asked to provide aggregate data (e.g. patient numbers, often stratified, against a specified number of data items).

The above conditions may change in the future if we are required to work with patient-level data as part of a specific postmarketing study, but this would not become a universal mandated requirement for all registries.

Method: Currently registries are asked to provide requested data by emailing it in an Excel spreadsheet. This will be made safer and more efficient in future with the development of the Global Registries Platform (GRP).

Identifiable personal data such as the name, address or contact details of registry participants will never be requested nor accepted by TREAT-NMD for central submission. If registries choose to collect these data locally they must ensure they are stored and processed according to relevant data protection legislation.

Back to top