SEND Implementation Wiki - FAQ - Handling of SEND in Study Documentation

From PhUSE Wiki
Jump to: navigation, search

This page covers the handling of SEND in study documentation, such as the protocol, treatment by QA/QC and systems validation, and unofficial FDA expectations.

<< Go back to the SEND Implementation Wiki - FAQ page

Disclaimer

Note: The content of this page is currently being worked on. Also, like all pages on this wiki, it was prepared by PhUSE working group and SEND team members and should not be considered as official FDA guidance or direction. This content exists to provide implementers with quick and unofficial guidance as things change.

High-level

At their core, SEND datasets are a standardized format of the individual data listings. However, how organizations generate and use them varies widely, running the gamut from being (a) an integral component/step in the study interpretation and reporting process to (b) additional, non-GLP deliverables generated well after finalization.

The following are some key tenets driving how/if your datasets fall under GLP, for those studies intended at some point to be submitted to the FDA:

  • GLP status is based on whether the SEND datasets themselves are used in making study decisions or to generate the tabulations included in study reports.
    Like any other deliverable, if a SEND dataset is either directly or indirectly used to make study decisions (in other words, it is used as the basis of interpretations or impacts the course/direction of a study), it is under the GLP hood. If the datasets are merely another deliverable outside of the general reporting process, not used for analysis, etc., then they do not fall under GLP regulations.
  • For submissions to the FDA, you can expect that they will want you to ensure the validity and accuracy of the SEND datasets, regardless of whether or not they were used in study decisions.
    In every submission, methods should be in place to check validity and accuracy of the SEND datasets (validating your software/process is one way of ensuring this, although validation is not necessarily required), and the results from that verification need to be available in the event of Agency request.

The following sections describe in more detail the rationale for handling the SEND datasets in study documentation, specifically for those studies intended for possible later submission to the FDA, GLP or no. Purely operational cases (e.g., solely for data warehousing or inter-organization transfer without intent to submit) are outside of the scope of the discussions below.

Protocol / Contract Deliverable

High level - It is advantageous to include the production of SEND datasets in some document as a unit of work to be tracked and delivered.

Whether or not this goes in the protocol or another document like a study contract is up to each organization, primarily driven by whether doing so would incur undue audit requirements.

Protocols and Reports

For many organizations, protocols serve a dual purpose as both the study plan and a detailed listing of the tasks that are expected to be completed. This makes the protocol a useful tool for scheduling resources and deliverable dates as well as a natural list for the QA unit to determine what tasks are required for auditing purposes.

Because SEND is a deliverable that is not generally subject to QA audit, this can potentially cause some concern when SEND is included in GLP protocols. Because many companies have scheduling and resourcing systems built around the use of the protocol, the benefit of including SEND in the protocol is significant; however, such benefit is lost if this then entails a QA audit.

If your organization's QA unit:

a) Considers everything in the protocol subject to QA audit, then we recommend including SEND datasets in your contract/scheduling/etc. to ensure that production of the datasets, as a unit of work, is properly scheduled and accounted for.
b) Allows for inclusion of items in the protocol that are exempted from QA audit, then we recommend that the protocol statement clearly indicates whether or not the SEND datasets will fall within the scope of GLP Part 58. As stated above, SEND datasets are only within the scope of GLP Part 58 when the datasets are used to make study decisions, in all other applications SEND datasets are a deliverable outside the scope of GLP Part 58. Some examples:
SEND v3.0 datasets will be prepared for this study; these datasets will not be used to make study decisions and are outside the scope of 21 CFR Part 58 regulations and as such will not be subject to QA audit.
OR
SEND datasets will be prepared and supplied electronically to the sponsor based on the final reports. The final dataset issued will include data integration, as appropriate and a Study Data Reviewers Guide and will be compliant with the FDA Guidance for Industry - Providing Regulatory Submissions In Electronic Format — Standardized Study Data. The SEND datasets will not be subject to Quality Assurance inspection.

Contracts

For any outsourced study, it is a necessary task for the Sponsor and CRO to agree on the expected deliverables of the studies. SEND datasets may not be required of all outsourced study types; however, if SEND datasets are required, they will have an associated resource impact and may have an associated cost. To assure full agreement on study deliverables and costs, consider inclusion of SEND datasets within the study contract, or statement of work, as applicable.

Quality Controls

QA

For non-GLP cases (including non-GLP datasets for GLP studies, such as datasets created after study finalization and not used for study decisions), the GLP Quality Assurance unit would not be required and so would typically not be involved at least on an official basis.

For GLP cases where the SEND output is used in making study decisions, SEND output would be subjected to similar QA controls as those that are applied to the production of individual data listings.

QC

The FDA is relying on the sponsor to appropriately verify that data in the SEND datasets are an accurate representation of the data in final reports. If the datasets are eventually intended for submission, then QC should be covered at some level regardless of whether the datasets are considered GLP. Like individual tabulations, if the process used to generate those SEND datasets is validated, you can skip much (or all) of the QC. However, depending on the study and your implementation, some areas may require manual intervention, such as TS, TA, TE, timing fields in PC. As a result these may require more QC.

Examples:

  • Minimal to no QC for validated process generating datasets (GLP or no)
  • 100% QC for non-validated process generating GLP datasets
  • Sampling for non-validated process generating non-GLP datasets

System Validation

If your SEND datasets are not bound by GLP, then system validation is an optional exercise. It may still be useful to do, in that it can satisfy the general need to ensure accuracy of your data, but it is not required.

If your datasets are bound by GLP, then consider validation for the systems and/or processes which produce SEND datasets to be similar to validation for similar systems that produce individual listings, namely, that, given a set of inputs and a set of actions performed in the system with those inputs, that you receive the expected outputs.

In addition, given that the outputs are electronic data, there can additionally be some opportunities for electronic verification of the data, which can make validation somewhat easier.

Study Director Responsibility

If your datasets are not bound by GLP, then there is no signature necessary by the study director, as it is not officially part of the study report.

If your datasets are bound by GLP, then the Study Director's signature works in the same way as it does for other components of the study report, namely, it indicates accountability for the validity of the content of the datasets.



Last revision by Troy.smyrnios, 2017-03-1