CDISC is the Clinical Data Interchange Standards Consortium, a nonprofit organization whose goal is to “develop and support global, platform-independent data standards that enable information system interoperability to improve medical research and related areas of healthcare.” CDISC develops standards for packaging and reporting clinical research and related data. According to the CDISC website, use of these data standards will “become mandatory 2 years after the final guidance is issued for NDAs and BLAs, and will apply to all new studies begun 1 year after the final guidance is published.” The final guidance is required by fiscal year 2017.
Some of the more significant standards include:
CDASH (Clinical Data Acquisition Standards Harmonization) is used for acquiring clinical study data. The goal of CDASH is to harmonize clinical element names, definitions and metadata.
SDTM (Study Data Tabulation Model) is used for reporting clinical study data in a machine-readable format. SDTM reports clinical observations as series of variables. These variables represent values in a corresponding table.
ADaM (Analysis Data Model) is used for analyzing data.
LAB (Laboratory Data Model) is a standard for transmitting laboratory data. Unlike the other standards, the name is not an acronym. It was originally created to facilitate transferring data from Labs to Clinical organizations.
The different standards are used for different parts of the clinical process: acquiring data (CDASH), reporting data (SDTM) and analyzing data (ADaM).
The usual flow of clinical data through the CDISC standards is:
Data sets are generally only human-readable at the beginning and end of this process. The CDASH and LAB can be human readable when viewed directly with some experience. SDTM and ADaM data are not human-readable; programs use SDTM and ADaM data to produce the tables, listings, figures, and statistical results that are the core of the Clinical Study Report (CSR).
We’ve all looked at a price tag (“How many zeros?”) and felt sticker shock.
When you take your clinical data collection design to most clinical data management contractors and ask for an estimate, you will likely receive a series of implementation requirements tacked on, such as:
Looking at this list of implementation requirements (“How many zeros?”), you are feeling requirement shock.
Ofni Systems designed Ofni Clinical to avoid requirement shock:
Our last Ofni Clinical database project was based on a 172 page Case Report Form and had 55 Edit Checks.
It was implemented in under 100 hours – less than two and a half weeks.
Contact us to find out how Ofni Clinical can help you avoid requirement shock.
Calculations represent one of the highest risk components of any computer validation project. When results are displayed on a form or report, users tend to accept those results as correct. Validation has to ensure that the results are actually correct. One common method to validate calculations is to enter a few known values and verify that the expected results are returned. However, even if the results of a calculation are correct in a few cases that does not mean the underlying formula is correct. For that reason, Ofni Systems’ preferred method is to directly verify the function or formula.
The User/Functional Requirements is the appropriate place to document what each formula is supposed to calculate. All of the components of the function should be explained, including any Boolean logic that is used to capture errors or unusual conditions. For example:
The Design Specification is the appropriate place to document the actual calculation. It is a good practice for the author of the Design Specification to document the arguments in the calculation to ensure that the calculation does represent the intended calculation; if the author notices that the calculation does not match the requirement, this should be brought to the appropriate person’s attention. For example:
The test protocol then ties the User/Functional Requirements to the Design Specification. The protocol procedure describes the requirement. The tester documents the calculation in the results along with the individual components of the calculation. The tester then verifies that the calculation accurately describes the requirement. This does require a tester who is has enough experience to review the formulas, compare them with the requirement and verify that the formula meets the requirement. It also requires that the functions are directly accessible by the tester. The advantage of this method is that the function itself has been directly verified and validated, rather than a few selected inputs.
ISPE has just released version 5 of GAMP, Good Automated Manufacturing Practices. GAMP 5 emphasizes a cost effective approach to compliance, while incorporating recent regulatory and industry developments that focus attention on patient safety, product quality and data integrity.
The new GAMP 5 emphasizes leveraging risk assessment and risk management to scale validation efforts appropriately. GAMP 5 favors a holistic approach to risk management, not individual risk assessments of each individual computer systems. Risk is so important that it’s in the new subtitle of the standard: A Risk-Based Approach to Compliant GxP Computerized Systems
Ofni Systems can help your company review their policies and practices to ensure they follow the best practices guidelines outlined in GAMP 5. Ofni Systems can also provide your employees with the training to remain in compliance with all applicable regulations.