1. End-to-End With Standards – A Regulatory Reviewer’s Perspective
Benjamin Vali, M.S.
Regulatory Project Manager
Division of Gastroenterology and Inborn Errors Products
CDER/OND/ODEIII
U.S. Food and Drug Administration

2. FDA Disclaimer
This presentation reflects the views of the author and should not be construed to represent FDA’s views or policies.

3. The Details

4. The BIG Picture

5. Outline What Do We Need? Basics of Product Development
What is Your Medical Objective?
Trial Protocol
Case Report Form (CRF)
Clinical Database
Analysis Database

6. Outline Clinical Study Report (CSR) Product Labeling
Putting It All together – End-to-End With Standards
Appendix: A Word On Post-Data-Capture Mapping

7. What do we need? All Regulatory Reviewers at FDA/CDER
Metadata
Traceability
Data Standards

8. Why Push for Traceability?
Full transparency for each data point throughout clinical data lifecycle
From the source “to my computer”
Ensure consistency with what was pre-specified in the Protocol and Statistical Analysis Plan (SAP)
Best supports Quality Validation

9. Why Push for Standards?
Further streamlines Regulatory Review (and Industry Production) of traceable content
Consistent data structure and/or format of content
Consistent nomenclature
Analysis-ready
Standard automated analyses leveraging review tools using SDTM
Protocol/SAP specified analyses using ADaM

10. Why Push for Standards? Standardize not only the data Metadata
Define.XML
Communication
Study Data Standardization Plan
Study Data Reviewer’s Guide (SDRG)
Analysis Data Reviewer’s Guide (ADRG)

11. End-to-End Standards achieves both

12. Basics of Product Development (Sans CMC)
Proof of Mechanism (“Bench-side” Proof of Concept) Non/Pre-Clinical

13. Basics of Product Development (Sans CMC) con’t
Clinical Proof of Principle (I) Clinical Proof of Concept (II) Confirmation of Clinical Proof of Concept AND Long-term Extension (III) Post-Market (IV)

14. What is your medical objective?

15. Achieving your medical objective
Identifying appropriate patients/subjects
Determining appropriate trial design
Determining specific data to be collected (and when and how it should be collected)

16. Where do you formally present all of the aforementioned information?
The Trial Protocol

17. Trial Protocol
Need to standardize into human AND machine readable format while enabling adequate information management and reuse
Step 1 – Protocol Template
Improve quality, completeness, and consistency of protocol submissions across all therapeutic areas
Improve review efficiency and reduce the number of FDA-sponsor protocol queries

18. Trial Protocol Step 1 con’t – Protocol Template
Improve the ability to more quickly understand the clinical trial
Enhance ability to compare/contrast trial designs
Step 2 – Now make it machine readable
Provide a link to enable downstream data capture, analysis, reporting, and review

19. Trial Protocol
Coalition for Accelerating Standards and Therapies (CFAST) involvement starts at this juncture
TransCelerate’s Common Protocol Template
Protocol Representation Model (PRM)

20. What instrument is utilized to capture the data needed (as described in the protocol) to achieve your medical objective?
Case Report Form (CRF)

21. CDASH Clinical Data Acquisition Standards Harmonization (CDASH)
Best facilitates creation of high quality CRF pages and mapping to a Study Data Tabulation Model (SDTM) compliant clinical database
Done at the data capture stage!

22. CDASH
Closest to 1-to-1 mapping in terms of structure, content and format
Covers majority of SDTM domains
Best Practices for creating other domain pages
Eliminates the need for more downstream work (i.e., post-data-capture mapping)
We’ve come a long way since previous versions
Developing Therapeutic Area (TA) CRFs

23. A Quick Word on Source Data
Per PDUFA V (FDASIA), there is a push to move exclusively into the electronic world
No more paper
This applies to source data as well
Electronic Source Data eliminates the paper transcription step
The eCRF should be the source

24. A Quick Word on Source Data
Adequate controls should be in place to ensure confidence in the reliability, quality, and integrity of the Electronic Source Data
Quality of the Electronic Data Capture (EDC) System is the key
Guidance for Industry: Electronic Source Data in Clinical Investigations

25. Where is the data, captured by the CRF, ultimately housed?
Clinical Database

26. SDTM Study Data Tabulation Model (SDTM)
Structure of clinical database highly dependent on CRF
Hence the importance of CDASH
Development of standard mapping for TAs
Currently trying to make SDTM database more like traditional clinical database

27. SDTM What do you mean by “derived”?
Operationally-Derived
Analysis-Derived
We have to standardize the definitions first…

28. SDTM – Definitions
Operationally-Derived: An operationally-derived value is one that is typically computed at the point of data capture, or by data management systems during study conduct, prior to making data available for analysis as per the Protocol/SAP. These data should be clearly and consistently derivable based on standard methods.

29. SDTM – Definitions
Analysis-Derived: An analysis-derived value is one that is typically computed after data capture and is associated with derivation logic that is specified by a statistician and/or statistical programmer. These data are derived for the sole purpose of directly analyzing study data per the Protocol/SAP or for supporting said analyses.

30. SDTM
SDTM should really just be captured CRF (CDASH) data and Operationally-Derived data
Analysis-Derived data should be moved over to the Analysis Data Model (ADaM) compliant analysis database
But, we need to account for FDA Review Tools as well

31. So what about the Protocol/SAP analysis?
Analysis Database

32. ADaM Analysis Data Model (ADaM)
Modeling analysis data in general is more ‘gray’ than ‘black and white’
Multi-purpose (a dataset may support many different analyses as per Protocol/SAP)…hence less modeling rules
ADaM makes things a lot LESS ‘gray’

33. ADaM
ADaM delicately tries to balance Traceability and ‘Analysis-Ready’ with a predictable structure
Contains Analysis-Derived data
In lieu of dropping records/observations not used for analyses (e.g., data from unscheduled visits), it implements various analysis flags

34. ADaM ADaM appropriately emphasizes Traceability
Relevant data should directly be imported from SDTM
Prohibits changes to an SDTM value
Sequence variable(s) are included, i.e., --SEQ or SRCDOM/SRCSEQ, as the link back to SDTM records
Becoming more involved in the TA process

35. Clinical Study Report (CSR)
Where do the Protocol/SAP analysis results go?
Clinical Study Report (CSR)

36. ICH E3 CSR Practical Template for a CSR
Contains the Tables, Listings, and Figures (TLFs) built from the analysis database (ADaM)
PhUSE white paper on scripts for standardizing basic analyses and TLFs

37. After a LOT of work, what next?
Product Labeling

38. Product Labeling
On January 24, 2006, the FDA issued final regulations governing the content and format of Prescribing Information (PI) for human drug and biological products
The rule is commonly referred to as the “Physician Labeling Rule” (PLR) because it addresses prescription drug labeling that is used by prescribers and other health care providers

39. Product Labeling
The goal of the PLR content and format requirements is to enhance the safe and effective use of prescription drug products by providing health care providers with a clear and concise PI that is easier to access, read, and use

40. PLR – Highlights

41. PLR – Table of Contents

42. PLR – Full Prescribing Information

43. End-to-End with Standards – Linear Method + Standards from the Start
TransCelerate/PRM
CDASH
SDTM
ADaM
ICH E3 CSR
PLR PI

44. A Word on Post-Data-Capture Mapping/Legacy Data Conversion (LDC)

45. Traceability vs. Data Standards
What we often see submitted by Applicants
In the creation of standard data for submissions, traceability is (at times), compromised by post-data-capture mapping/LDC
Right now we are living during a “transitional” period (i.e., from legacy to standardized data), hence you need to do what you need to do for imminent deliverables

46. Current Approaches

47. Approach #1 (Historical/Legacy)
… Legacy CRF  Clinical Database  Analysis Database  TLFs …

48. Approach #2 (Starting Out …)
SDTM
… Legacy CRF  Clinical Database  Analysis Database  TLFs …

49. Approach #3 (Getting Better …)
SDTM ADaM
… Legacy CRF  Clinical Database  Analysis Database  TLFs …

50. Approach #4 (Better and Better …)
SDTM  ADaM
… Legacy CRF  Clinical Database  Analysis Database  TLFs …

51. Approach #5 (Getting There …)
… Legacy CRF  Clinical Database  SDTM  ADaM  TLFs …

52. Approach #6 (The Best)
… CDASH CRF  SDTM  ADaM  TLFs …

53. As We Move Forward…
Don’t map for the sake of mapping (i.e., from legacy datasets to SDTM and ADaM)
Approaches #2, #3 and #4
Unnecessary cost (time and money) to applicants
Includes time and money wasted for responding to subsequent Information Requests during the review cycle!
Strive for Approach #6 – no onerous mapping required!

54. As We Move Forward… The principle behind this approach is key
More so than the CDASH standard itself
Implementation is everything!
More so than the content standards in general themselves
Must adhere to CDISC foundational principles

55. How’s the view?

56. Thank You
Benjamin Vali, M.S. Regulatory Project Manager Division of Gastroenterology and Inborn Errors Products CDER/OND/ODEIII U.S. Food and Drug Administration