Patient Profiles and Standard Submission Data Experience with the Patient Profile Viewer Pilot Proje

1
Patient Profiles and Standard Submission
DataExperience with the Patient Profile Viewer
Pilot Project

• Fred Wood, Procter Gamble Pharmaceuticals
• Michael Walega, Covance, Inc.

2
Outline
3
Outline
4
Outline

• Decision to participate
• Decision on data to be submitted
• Decision whether to partner with a CRO

• Assess the datasets what do we have?

• The process where and how to start

• Challenges along the way
• Key learning points

5
Decision to Participate
Reasons

• Experience of using the CDISC standards in a
  simulated submission
• Get a feel for time and effort which might be
  required for a real submission
• Opportunity to see how the PPV worked with real
  data
• FDA project

• Added Incentive
• The mapping was reusable if company standards
  were used.

6
Decision on Data To Be Submitted
Considerations

• For PGP, should it be a study from our current
  CDMS (Oracle Clinical) or our legacy system?
• Different standards
• Recent (unsubmitted) study or previously
  submitted study?
• Most companies chose previously submitted studies
• Data structure and contents conform closely to
  pilot specifications
• Minimize transformations

7
Decision on Whether to Partner with a CRO

• Resources
• Knowledge/Experience with the Data
• Confidentiality
• Ownership/Control

8
(No Transcript)
9
The Process Where and How To Start

• Similar to data integration in support of
  marketing applications
• Requirements
• Strategy
• Tool Development
• Execution
• Delivery

10
Requirements

• Manage data confidentiality
• Identify and review areas of concern
• Remove / mask data
• Assess mapping needs
• Data domains
• Variable attributes

11
PPV Domains
12
Mapping Process
NDA Specifications
CDISC v2 Specifications
PPV Pilot Specifications
Domains, Variables Data Transform Tools

13
Mapping Strategy

• First pass
• Leverage specifications document to construct
  automated mapping tools
• Too many non-standard/pre-defined variables to be
  effective
• Second pass
• Create template of requirements
• Manually map variables from NDA to CDISC/PPV
  specifications
• Map PGP codelists to CDISC codelists where
  required

14
Tool Development

• SAS v8.2
• Full automation not feasible
• Legacy CDISC PPV specifications
• Domain-specific mapping tools developed
• Subject Characteristics, Exposure and
  Disposition domains
• Data masking
• What was automated
• Final data preparation
• Data transfer (XPORT files)

15
Execution
? Working Together ? Frequent discussions on
issues and challenges arising from mapping
process ? Paper mapping conducted in parallel,
cross-checked between PGP and Covance
? Domain / Variable Mapping ? All tool
development performed by Covance ? Ongoing review
of metadata and data by PGP
16
Delivery

• Preparation for submission
• Supportive documentation generated by Covance,
  reviewed by PGP
• SAS transport files generated by Covance based on
  PPV specifications and current NDA Guidances
• Submitted to CDER by PGP

17
(No Transcript)
18
Challenges Along the Way

• This was most participants first experience in
  applying the CDISC SDS models to real data, so a
  number of questions arose (e.g., what about
  recurring variables or multiple levels of coding
  from a dictionary such as MedDRA).
• Because the Patient Profiles roles were
  hard-coded in the version of the software used
  for the pilot, the specifications for variable
  names needed to be followed exactly.
• There were variables in the FDA specifications
  that were not in the CDISC SDS model (e.g,
  MHSTDTC, Start date of condition or procedure),
  so variable names andattributes needed to be
  agreed upon.

19
Challenges Along the Way (contd)

• Participants had to agree upon controlled
  terminology to be included in the Subject
  Characteristics domain since this was new to
  CDISC, and broadly defined in the FDA
  specifications.
• Participants had to determine and agree upon what
  to do for mapping if the codes (values) in their
  systems were more diverse than the specified
  controlled terminology (e.g., no E2B code for
  dose interrupted).
• Datasets were expected to contain columns for all
  the variables in the specification. Therefore,
  variablesneeded to be added to the datasets even
  if theywere not used in the study (e.g.,
  AESYMFL, theflag for Symptoms Reappearing).

20
Challenges Along the Way (contd)

• Some participants needed to derive data for
  variables in the specification that may not have
  been collected exactly that way in the study
  (e.g., SAE flags).
• Time was required to understand the data from a
  legacy CDMS which did not enforce/utilize the
  standards we have today. We had instances where
  the same information was collected differently
  across studies.

21
Resource Requirements ( )
person-hours
22
Key Learning Points

• There is a considerable amount of effort required
  the first time that mapping to CDISC standards is
  performed, but this would be significantly
  reduced in future submissions if the sponsor has
  and uses data standards.
• The time and effort required are difficult to
  estimate without experience. For some companies,
  the dataset-preparation process took longer than
  expected, but for others it took less time than
  expected.
• The pilot project provided an opportunity for the
  participants to apply the CDISC models to real
  data outside of a real submission.

23
Key Learning Points (contd)

• The pilot project provided opportunities for the
  FDA to1) receive real clinical-trials data using
  the CDISC model, and 2) give feedback on the data
  model.
• The pilot project provided an excellent
  opportunity to assess the quality of the CDISC
  models. Strengths as well as areas for
  improvement were identified.
• SAS Programming expertise and knowledge of the
  CDISC models was extremely important.
• Obtaining company buy-in required time and effort.

24
Acknowledgements

• Kerry Deem, Covance
• Troy Johnson, PGP
• Mary Lenzen, Pfizer
• Dave Ramsey, PGP
• Chris Tolk, Bayer
• Sara Williams, PGP