Flexible CDISC standardisation using Biomedical Concepts
[You can read an update on the development of Biomedical Concepts here: https://www.s-cubed-global.com/news/biomedical-concepts-the-time-is-now]
CDISC standardisation starts when you write a protocol and you decide how your CRF should look. The current way of working makes data collection and processing in a CDISC standardised way very inefficient and resource demanding. Using a Metadata Repository (MDR) with Biomedical Concepts (BC) definitions can help to solve this.
Current way of working and issues
The protocol often contains a tabular overview of the schedule of assessments(SoA). In the SoA, it can be specified that vital signs will be collected at every visit. To understand what vital signs are required, the reader will need to go to a section in the protocol to read that vital signs for this study is defined as heart rate, systolic and diastolic blood pressure and temperature. It typically doesn’t specify which unit (mmHg) and under which condition it is measured: left arm, right arm, standing, sitting, resting for 5 min etc. The protocol isn’t specific enough to allow for data collection. The ‘translation’ from the protocols wording to create the database and EDC setup requires further work. Time and effort is expended by data management and clinical operations.
Then the CRF needs to be defined. A standardised organisation will have a master library of standard CRFs that every study must use to ensure efficient study setup in EDC and other databases. If a study needs a modification to the standard CRF it typically needs to be approved by the standards governance group. Impact assessments need to be conducted if the change is to be added to the standard CRF or a new standard will be made, adding to a growing master library to maintain. A master library ending up with ‘standard’ CRFs that are nearly the same but not quite. There is a proliferation of standard forms.
Also, the medical staff express a resistance to adhere to the standard CRF because it will ‘limit’ them in getting the best study setup for ‘their’ study.
Then the data are collected, and the data needs to be standardised to SDTM. This is typically done using some mixture of excel-based specifications for the SDTM model and a set of programs that makes the transformation. If lucky, the organisation has a receiving database that has some alignment to SDTM, but some programming is typically needed. The annotated CRF (aCRF) is often done by ‘hand’ having some pdf-tools to ease the task. It is typically done late in the study process when data arrives in the database. In many organisations a considerable amount of programming hours is spent on mapping collected data to SDTM and creating the aCRF.
What is a BC and how can it improve the current setup?
A BC is a definition of a thing we measure or ask a subject (e.g. in a clinical trial). It is more than just the term for what we measure, e.g. Temperature but also the (allowed/possible) unit (Celsius or Fahrenheit), the format of the result (integer or float, if higher precision) and perhaps also where it should be measured: mouth, ear, anus. To standardise to CDISC terminology, the actual code value can be specified (temperature is code C25206), see Figure 1.
For the data manger and the programmer that creates the data collection (CRF) and data tables (SDTM), the Biomedical Concepts definition will provide the needed unambiguous information for data collection setup and dataset creation, see Figure 2 and Figure 3.
Through the definition of the BC the data transformation from protocol terms, CRF page to data table (SDTM) is ensured and, as a consequence, we also get the traceability, see Figure 1, Figure 4 and Figure 5 .
Once the data arrives, see Figure 4, we know where the data goes as it is defined by the BC definition. The link to the BC identifier is kept in the receiving file allowing for linking the actual data to the BC metadata. Derivations can also be stored as metadata in the MDR and applied to the data when linked back to the BCs.
If you have a MDR with these definitions – the Biomedical Concepts – and can specify the protocol electronically using these BCs, then it is clear to all contributing to the trial reporting (medical, data managers, statisticians, medical writers) the specifics of the data collected.
Using BCs, you don’t really need a master standard CRF library or it can be decentralised to the individual clinical projects or therapeutic areas. Only the BCs need to be centrally governed. A CRF is conceptually just a piece of paper or a screen in EDC – a definition of what you decide to display together and what instructions you need to provide. A study or project team can build their own forms (or have their own library of forms) if they base it on the BCs. Defining Biomedical Concepts is a more modular way of defining data collection specifications while still ensuring adherence to CDISC standards and data traceability.
The challenge with many controlled terminology versions (and SDTM models) and identifying where it impacts the BC, forms etc. is done by a query in the MDR and displaying it to the user, see Figure 7
The top of the Figure shows the meta definitions (e.g. BC, Forms and domains) that are impacted, and the bottom part displays which terminology it related to. The detailed changes are displayed by pressing the Changes button. The relevant part of the MDR that is affected is visualised to the right.
The standards curator will then know what BCs to update and those in charge of the forms can update those to align with the new terminology.
Populating the collection of Biomedical Concepts in the MDR to reflect all things an organisation will examine in all their studies will take some effort. But once in place it can be re-used and ensure consistency and adherence to CDISC standards. If BCs are used in the definition of SoA it will ensure use of CDISC standard from the beginning of the study data collection process with the end-product in mind being the SDTM data. In addition, the creation of CRFs will allow for more flexibility without compromising CDISC standardisation.