ISoP ISoP on Twitter | ACoP ACoP on Twitter | PAGE | WCoP | PAGANZ | PAGJa

Submission of PK/PD/PMx files to regulatory agencies: experiences and challenges

PK/PD Programmer (ASA/ISOP)
#1

The PKPD Programming Forum will meet on June 21st, 2019 from 10:30 to 12:00 EST with a focused discussion on this topic.

Submission of PK/PD/PMx files to regulatory agencies: experiences and challenges

We will review a summary of current experiences and challenges with data and analysis file submissions to regulatory agencies, specifically:

  • Discuss up to date file and data submission experiences with various regulatory agencies
  • Compare and contrast requests/needs of different analysis types
  • Compare and contrast member experiences
  • Identify gaps and emerging trends with Regulatory Agencies other than USFDA and EU.

Consider providing input to the following questions:

  1. Are there any other agencies that have requested population based, data, model files, or summaries, beyond what would be provided to the FDA?
  2. Does your experience differ w/r the types of files requested or submitted?
  3. What have been the most challenging aspects of data and model file submission for your company?
  4. How consistent has your submission experience been across departments within the same agency? E.g., CBER, CDER, vs others.
  5. What has been your experience and consistency with agencies that outsource pharmacometric review, e.g., Australia?
  6. Are there specific agencies you prefer to work with over others (successes vs. challenges)?
  7. Have any challenges with data integrity converting back and forth between SAS transport files (e.g., data format, issues with forcing data from ASCII text to SAS Transport and back)?
  8. Are there specific best practices that work for your company to ensure successful submissions (e.g., content clarification meetings)?
  9. We have heard that the FDA will now accept files in their native format and nomenclature (original file name, not in SAS transport format), as long as they are ASCII text format, Had your company started taking advantage of this? Have you even heard that this is possible?

All are welcome to join in the conversation.

Dave Radtke

…
Join Skype Meeting
Trouble Joining? Try Skype Web App
Join by phone

+1 (317) 277-1498,674294# (United States) English (United States)
+1 (855) 545-5910,674294# (United States) English (United States)

Find a local number

Conference ID: 674294

1 Like
#2

Dear All based on my personal consulting experience here is some comments:

  1. Are there any other agencies that have requested population based, data, model files, or summaries, beyond what would be provided to the FDA?

EMEA requests will depend on what rapporteur country you have and many times we get some extra requests on doing additional vpc or extra sensitivity analyses. FDA might rerun some models and queries on their end while EMEA will often ask the sponsor to do it and send back. especially redoing the VPC stratficiation and pred correction, and how pediatric models are being fitted and evaluated.

  1. Does your experience differ w/r the types of files requested or submitted?
    The same files request and structure applies whether it is NONMEM or Phoenix NLME or any other software

  2. What have been the most challenging aspects of data and model file submission for your company?
    keep everything reproducible and documented.

  3. How consistent has your submission experience been across departments within the same agency? E.g., CBER, CDER, vs others.
    Very similar across FDA departments
    somewhat different depending on EMEA rapporteur country.

  4. What has been your experience and consistency with agencies that outsource pharmacometric review, e.g., Australia?

  5. Are there specific agencies you prefer to work with over others (successes vs. challenges)?

FDA , as they have some dedicated pharmacometricians and Statisticians that do actual data analyses on the sponsor data and we can have constructive joint efforts while EMEA is more like back and forth efforts. At One time an EMEA reviewer asked us to run a logistic regression on a time to event end point this did not make any statistical sense …

  1. Have any challenges with data integrity converting back and forth between SAS transport files (e.g., data format, issues with forcing data from ASCII text to SAS Transport and back)?

as long as we get the labels right no challenges xpt is open format some sponsors send us zipped or other non open formats that are not what the FDA request.

  1. Are there specific best practices that work for your company to ensure successful submissions (e.g., content clarification meetings)?
    we need some meetings to organize the eCTD package module 5 etc. it really depends

  2. We have heard that the FDA will now accept files in their native format and nomenclature (original file name, not in SAS transport format), as long as they are ASCII text format, Had your company started taking advantage of this? Have you even heard that this is possible?

No but that is really nice as long as we provide them with a clear define and data provenance that should be possible !

[/quote]

1 Like
#3

Look forward to the discussion!

#4

Thank you to everyone who participated in the discussion. Attached is the presentation. I did manage to record the session and will try and figure out a way to share the file (230 Mb). I will also try and post my notes shortly.

DaveReglatory_Submission_2019_update.pptx (194.2 KB)

#5

Here are some notes from today’s discussion.

  1. There seems to be alignment with the experiences listed in the presentation no additional experiences were discussed, if there are additional experiences not listed in the presentation, please let us know so we can update the material.

  2. Conversion of datasets to SAS transport format has continuing challenges some are:

    a. SAS compression and encoding can be different depending on the versions of SAS used and some of the online working environments. This has caused issues with transport files appearing corrupt and presenting as errors when they are used or accessed. Be aware that this can be an issue both with sharing files between companies and with regulatory agencies. It was pointed out that the new SAS VIYA environment uses UTF8 Encoding which may not be compatible with existing environments.

    b. Depending on settings, the creation of SAS transport files can force data element conformation from numeric to character and vice versa. Text fields representing dates and times can be forced to SAS format which then do not extract correctly. This could have impacts on how data is handled in programs like R or SPLUS where character date and time fields are used in calculations.

  3. Some best practices cited were:

    a. Consider formatting all columns in a SAS transport file as character to retain data in format that can be used by external programs.

    b. Test any submitted R and SPLUS scripts (even SAS) with datasets created by extracting from transport files that will be submitted to ensure there are no translation issues that creep in as a result of the transport process.

    c. Ensure you carry through USUBJID in all PK/PD files, even if it is dropped by the analysis program to maintain linkage to current collected data files (SDTM). If programs are not able to carry through a character value like USUBJID, either arrange to add it back into output or create id translation files as supplements for submission.

  4. Most regulatory agencies (other than the FDA) either do not want or will not except SAS transport files, be prepared to submit CSV or other ASCII files to OUS agencies.

1 Like