Flexible CDISC standardisation using Biomedical Concepts
By Kirsten Langendorf
[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.
Excellent post. I cannot agree with you more about the need for biomedical concepts to drive data collection/standardization/analysis downstream. It would definitely make life so much easier. Standard definitions are critical in this regard. I have a minor point regarding the use of the term “assessment” in this setting, as in “schedule of assessment.” What is typically specified in this schedule is observations, not assessments, which in clinical medicine are considered very different. Rarely a true assessment takes place (i.e. an adjudication panel meets to review the collected observations to assess if a particular medical condition is present, e.g. a myocardial infarction). In this regard, a more accurate description would be a Schedule of Activities. Bottom line is Biomedical Concepts represent clinical observations, and assessments describe how those observations are analyzed to identify/characterize medical conditions.
Thank you for this clarification and for your response. Agree that BCs represents clinical observations and not a medical judgments – assessments.