Case Studies
Case study-I
The title of the project was
Based on the raw data, the given study data structure is
mapped to the targeted structure of CDISC SDTM with the aid of CRF and
annotated CRF. The following steps were done to complete the tasks and
delivered within the timeline:
The domains were decided based on the inputs provided by
client in reference to the CDISC SDTM Implementation Guide (Version
3.1.1).
Each dataset was defined by metadata definition that
provided information about the variables used in the dataset. The
definition was described in a data definition document.
Each dataset variable in the document owes seven distinct metadata attributes:
- The variable name (limited to 8-characters for compatibility with the SAS Transport format)
- A descriptive variable label, using up to 40 characters, which should be unique for each variable in the dataset
- The data type (e.g., whether the variable value is a character or numeric)
- The set of controlled terminology for the value or the presentation format of the variable (Controlled terms or format)
- The origin or source of each variable
- The Role of the variable, which determines how the variable is used in the dataset.
- Comments or other relevant information about the variable or its data.
In addition to these metadata attributes, another two
attributes were also added in preparing datasets- one column indicating a
note/algorithm relevant to use of each variable, and another to
indicate how a variable is classified as a CDISC core variable.
Based on this document, codes were developed according to
the coding standards followed by the client and thus analysis dataset
was created. The coding was done such that the programs could be run on
different operating systems. PROC SQL was used mainly.
Macros for conversion of date and time to CDISC date and time and study day calculation were generated.
Internal QC was performed for the code and the output datasets
- Parallel Programming
- Outputs datasets were reviewed by the QC
personnel through parallel programming. In this process QC personnel
generated datasets independently and these datasets were compared with
the datasets generated by the SAS programmers.
- Code Review
- This involved review of the coding standards and the quality of the data generated. This also included peer review.
Case study-II
In this study based on the raw data and CRF, the given raw datasets were mapped to the targeted structure of SDTM and ADaM.
The following steps were taken for the conversion of the
raw data to CDISC SDTM structure based on the raw data, protocol and
CRF/annotated CRF.
The domains were decided based on the inputs provided by
client in reference to the CDISC SDTM Implementation Guide (Version
3.1.2).
Each dataset was defined by metadata definition that
provided information about the variables used in the dataset. The
definition was described in a data definition document.
Each dataset variable in the document owes seven distinct metadata attributes:
- The Variable Name (limited to 8-characters for compatibility with the SAS Transport format)
- A descriptive Variable Label, using up to 40 characters, which should be unique for each variable in the dataset
- The data Type (e.g., whether the variable value is a character or numeric)
- The set of controlled terminology for the value or the presentation format of the variable (Controlled Terms or Format)
- The Origin or source of each variable
- The Role of the variable, which determines how the variable is used in the dataset.
- Comments or other relevant information about the variable or its data.
In addition to these metadata attributes, another an
attributes was also added in preparing datasets- one column indicating a
note/algorithm relevant to use of each variable.
Based on this document, codes were developed according to
the coding standards followed by the client and thus analysis dataset
was created.
Macros for conversion of date and time to CDISC date and time; study day calculation and other required macros were generated.
Based on this document, codes were developed according
to the coding standards followed by the client and thus analysis dataset
was created.
The issues that surfaced during the course of project
was escalated to the client and a discussion on the same was performed
wither through mail or telecon.
Internal QC via code review was performed for the code
and the output datasets by the QC personnel. This involved review of the
coding standards and the quality of the data generated. This also
included peer review. The peer review was done wherever required.
After finalization by the SAS programmer, a sanity check
and the quality check was performed by the team leader. The final
datasets and code and specification document was sent to the client.
The following steps were taken for the conversion of the
raw data to CDISC ADaM structure based on the raw data, protocol,
CRF/annotated CRF and SAP.
The domains were decided based on the inputs provided by client in reference to the CDISC ADaM Implementation Guide (Version 1.2) and SDTMIG version 3.1.2.
Similar procedure is carried out for ADaM domain as done for CDISC SDTM domain.
SOP
Standard Operating Procedures, commonly referred to as
SOPs, are documents which describe the standard processes that the
company should adopt while carrying out company and project related
activities. At Kreara, around 50 SOPs have been developed under the
following sections
- General activities
- Project management
- Data management
- Statistics
- SAS
The SOPs are developed based on the standard template
which have sections describing the document (including author, reviewer
and approver names), the revision chronology, effective date and the
scheduled review date. At Kreara, the SOPs are made self explanatory by
describing the process in detail with the help of flowcharts.
An SOP Review Board (SRB) is appointed comprising of the
Director Operations, Project Manager and the Quality Assurance Manager,
which is responsible for the development and maintenance of the SOPs.
The SOPs are reviewed and updated on a periodic basis to ensure that the
documents are not obsolete and any change in process has been
documented. If at any point it is felt that a new SOP needs to be
developed, the request is placed before the SOP Review Board (SRB). The
SRB meets and decides the requirement of the new SOP and if approved,
supervises the development and the implementation of the SOP. SOP
Checklists are developed against each SOP to assist the Quality
Assurance Manager to check for process adherence for the various project
related and general activities.
