Saturday, September 24, 2016

The first drug approval by FDA for treating Duchenne Muscular Dystrophy (DMD) - who win, who lose?

Early this year, I wrote an article about “Race for the first drug approval by FDA for treating Duchenne Muscular Dystrophy (DMD)”, now came a great news for DMD patients and the biotechnology company Sarepta Therapeutics. This week, FDA approved Sarepta’s Eteplirsen for treating DMD patients – the first drug approved by FDA for treating DMD. Approval of Eteplirsen is a great example of a drug approved for treating rare disease where FDA’s flexibility and sensitivity to the obstacles of drug development for rare diseases has brought forth a successful treatment.  

However, this approval has a lot of controversies. In April, 2016, FDA’s advisory committee voted against the approval citing that there was not sufficient evidence demonstrating the efficacy. It is rare that FDA did not following advisory committee’s recommendations. On the other hand, we can clearly see that there are a lot of pushes from the patient advocate groups orchestrated most likely by the company. FDA tends to bow to the public pressure in approving drugs where there may not be substantial evidence. It is shown in the approval of Eteplirsen for DMD in this case and in the approval of Flibanserin (Addyi or so-called female Viagra) last year for the treatment of pre-menopausal women with hypoactive sexual desire disorder (HSDD).  


Food Drug and Cosmetic Act says:
…the term ‘‘substantial evidence’’ means evidence consisting of adequate and well-controlled investigations, including clinical investigations, by experts qualified by scientific training and experience to evaluate the effectiveness of the drug involved, on the basis of which it could fairly and responsibly be concluded by such experts that the drug will have the effect it purports or is represented to have under the conditions of use prescribed, recommended, or suggested in the labeling or proposed labeling thereof.”

The adequate and well-controlled investigations should have the following features:
1.      A clear statement of the objectives of the investigation and a summary of the …methods of analysis
2.      The study uses a design that permits a valid comparison with a control to provide a quantitative assessment of drug effect. The protocol…should describe the study design precisely.
3.      The method of selection of subjects provides adequate assurance they have the disease or condition being studied.
4.      The method of assigning patients to treatment and control groups minimizes bias and …assure(s) comparability of the groups.
5.      Adequate measures are taken to minimize bias on the part of the subjects, observers, and analysts of the data.
6.      The methods of assessment of subjects’ response are well-defined and reliable.
7.      There is an analysis of the results of the study adequate to assess the effects of the drug.

Based on FDA’s briefing document for advisory committee meeting, there were a lot of issues that were against these principles for an adequate and well-controlled investigations. The primary efficacy endpoint was not statistically significant. The assay and assessment were not reliable. There was inadequate handling of missing data in analysis. There was inadequate use of the historical control. There were a lot of fishing expeditions - searching for the positive signals in largely negative studies.  

As mentioned in an article in Boston Globe "For a mother, a bittersweet victory as a long-sought drug is finally approved":
In approving the drug — called eteplirsen, it’s made by Cambridge-based Sarepta Therapeutics — the FDA overruled its own staff and advisers, who concluded there was not enough evidence it worked. Even if it does, it’s expected to help only 13 percent of the estimated 20,000 people in the United States with Duchenne.
But advocates like Christine McSherry begged the FDA to approve it, arguing it was their only hope

Studies to Support the Approval of Eteplirsen
Studies
Phase
Sample Size
Study Design
Protocol title
Study 28
Phase 1
7
Single arm, no concurrent control

Study 33
Phase 1/2
19
Open label, dose-ranging study

Study 201
Phase 2
12 (4 patients per arm)
Randomized, controlled study with two active dose groups versus placebo

Study 202
Phase 2
12
Open label extension

Right after FDA’s advisory committee voted against the approval of Eteplirsen, the Catch-22 for FDA was clear:
Does the agency approve a generally safe but possibly ineffective DMD treatment based on limited data, and then rely on post-marketing data to see if the treatment is really effective, possibly raising false hopes of families and young boys that believe the drug is working?
Or
Does FDA reject eteplirsen, wait for more data to prove its effectiveness and possibly deny access to the treatment (for up to three years) until more concrete evidence of the treatment’s effectiveness?

FDA decided to go with the first option to approve eteplirsen. Eteplirsen is approved under accelerated approval regulatory pathway and Sarepta is required to conduct a confirmatory study after the approval. Theoretically if the confirmatory study cannot show the efficacy, the drug should be withdrew from the market. However, it will be extremely difficult or unlikely to withdraw the drug from the market even if the evidence about the efficacy is not substantial from the post-marketing study. FDA bows to the public pressure now and will face even more daunting pressure then. 

The approval of eteplirsen is the win for drug developer, for DMD patient advocate group, and for orphan drug development. The approval of eteplirsen is also the loss for FDA who approves a drug largely due to the public pressure.  

As for DMD patients, on the surface, it seems to be a victory to have a drug available, however, it is a drug with unproved benefit that may give the patients the false hope. Hopefully, the fight for efficacious treatment for DMD will continue and the approval of eteplirsen will not impede the further pursuit of DMD treatment by other companies.  

Tuesday, September 13, 2016

Free FDA Information Repository


To learn and understand the regulations in drug development and clinical trials, the documents from FDA’s website are extremely helpful. Luckily, there is another website available now for FDA information repository.

Today DIA regulatory affairs community organized a WebEx. Stephen Weitzman, Executive Director from the MedDATA Foundation gave an overview of the IRAI FREE FDA Information Repository. The IRAI repository was initiated under a contract with the FDA with the objective of implementing a new system for cataloging FDA materials in an easily accessible and searchable format for research and training at academic universities and for all other stakeholders interested in FDA’s law, regulation, policies and procedures.

IRAI-Online.Org is open access to all and contains pretty all information from FDA’s website plus additional information that may not be available from FDA’s website or difficult to search on FDA’s website. Some clinical trial related information from NIH website are also included in this new FDA Information Repository website. To request an access, go to IRAI-ONLINE.ORG.

According to the presenter, Stephen Weitzman, the new FDA information repository is cataloged better and more searchable than FDA's website. It is organized by volume I to XXII (volume 1 to 22). The list of volumes is listed below.


Friday, September 02, 2016

Dealing with encoding issue in clinical trial data: WLATIN1 and UTF-8

Nowadays, the clinical trials go to global and are usually multinational. The data collection also goes to the electronic data capture (EDC) and the clinical trial data are entered directly by the investigational sites no matter whether the sites are in English-speaking countries or the non-English speaking countries. One issue we often run into is the data encoding issue.

Encoding is the process of transforming a set of Unicode characters into a sequence of bytes. In contrast, decoding is the process of transforming a sequence of encoded bytes into a set of Unicode characters.

To accommodate the multinational trials and the necessity of handling the non-English language characters, the EDC vendors may choose to use the encoding = UTF-8 for their data sets. However, when we use SAS for Windows system, the compatible encoding system is usually WLATIN1.

In the Windows environment, if we try to read a data encoded with UTF-8 format, we will get an error message such as below:

NOTE: Data file xxxxx is in a format that is native to another host, or the file encoding does not match the session encoding. Cross Environment Data Access will be used, which might require additional CPU resources and might reduce performance.
ERROR: Some character data was lost during transcoding in the dataset xxxxx Either the data contains characters that are not representable in the new encoding or truncation occurred during transcoding.

Here is also a discussion about this issue on SAS website.

To ensure that the data is transcoded correctly from one encoding to another, there are several ways. The following three papers provided very good explanations:

According to paper by Song, there are three ways to change the encoding:
1.    Force the transcoding by specifying that it needs to become WLATIN1, using the dataset option ENCODING=.
data x(encoding='WLATIN1');
set x;
run;
2.    USE PROC DATASETS
The second approach is to use PROC DATASETS as below:
proc datasets lib=libname;
modify x/correctencoding='WLATIN1';
run;
However, this way is NOT recommended: it only changes the encoder indicator but not actually translate the data itself!

3.    USE PROC MIGRATE
When you would like to convert multiple SAS datasets from wlatin1 into UTF-8, you can use PROC MIGRATE.
proc migrate in=inlib out=outlib;
run;
This migrates all SAS datasets in libname inlib to libname outlib. It retains SAS datasets labels as well. Note that inlib and outlib should be two different locations.

Also, we can use the following approaches:
1   1. inencoding option in libname statement.
libname in 'directory\' inencoding=asciiany;
data x;
   set in.x;
run;
    2. Directly use encoding option after the data set
 proc sort data=RAWDM.AE(encoding='wlatin1') out=OUTSTATS.AE ;
by subject;run;
Here are some approaches / examples for resolving the data encoding issues from NLS reference guide:

Example 1: Creating a SAS Data Set with Mixed Encodings and with Transcoding Suppressed
By specifying the data set option ENCODING=ANY, you can create a SAS data set that contains mixed encodings, and suppress transcoding for either input or output processing.
In this example, the new data set MYFILES.MIXED contains some data that uses the Latin1 encoding, and some data that uses the Latin2 encoding. When the data set is processed, no transcoding occurs. For example, the correct Latin1 characters in a Latin1 session encoding and correct Latin2 characters in a Latin2 session encoding are displayed.
libname myfiles 'SAS data-library';
data myfiles.mixed (encoding=any);
set work.latin1;
set work.latin2;
run;

Example 2: Creating a SAS Data Set with a Particular Encoding
For output processing, you can override the current session encoding. This action might be necessary, for example, if the normal access to the file uses a different session encoding.
For example, if the current session encoding is Wlatin1, you can specify ENCODING=WLATIN2 in order to create the data set that uses the encoding Wlatin2. The following statements tell SAS to write the data to the new data set using the Wlatin2 encoding instead of the session encoding. The encoding is also specified in the descriptor portion of the file.
libname myfiles 'SAS data-library';
data myfiles.difencoding (encoding=wlatin2);
run;

Example 3: Using the FILE Statement to Specify an Encoding for Writing to an External File
This example creates an external file from a SAS data set. The current session encoding is Wlatin1, but the external file's encoding needs to be UTF-8. By default, SAS writes the external file using the current session encoding.
To specify what encoding to use for writing data to the external file, specify the ENCODING= option:
libname myfiles 'SAS data-library';
filename outfile 'external-file';
data _null_;
set myfiles.cars;
file outfile encoding="utf-8";
put Make Model Year;
run;
When you tell SAS that the external file is to be in UTF-8 encoding, SAS then transcodes the data from Wlatin1 to the specified UTF-8 encoding.

Example 4: Using the FILENAME Statement to Specify an Encoding for Reading an External File
This example creates a SAS data set from an external file. The external file is in UTF-8 character-set encoding, and the current SAS session is in the Wlatin1 encoding. By default, SAS assumes that an external file is in the same encoding as the session encoding, which causes the character data to be written to the new SAS data set incorrectly.
To specify which encoding to use when reading the external file, specify the ENCODING= option: 
libname myfiles 'SAS data-library';
filename extfile 'external-file' encoding="utf-8";
data myfiles.unicode;
infile extfile;
input Make $ Model $ Year;
run;
When you specify that the external file is in UTF-8, SAS then transcodes the external file from UTF-8 to the current session encoding when writing to the new SAS data set. Therefore, the data is written to the new data set correctly in Wlatin1.

Example 5: Using the FILENAME Statement to Specify an Encoding for Writing to an External File
This example creates an external file from a SAS data set. By default, SAS writes the external file using the current session encoding. The current session encoding is Wlatin1, but the external file's encoding needs to be UTF-8.
To specify which encoding to use when writing data to the external file, specify the ENCODING= option:
libname myfiles 'SAS data-library';
filename outfile 'external-file' encoding="utf-8";
data _null_;
set myfiles.cars;
file outfile;
put Make Model Year;
run;
When you specify that the external file is to be in UTF-8 encoding, SAS then transcodes the data from Wlatin1 to the specified UTF-8 encoding when writing to the external file.
Example 6: Using the INFILE= Statement to Specify an Encoding for Reading from an External File
This example creates a SAS data set from an external file. The external file's encoding is in UTF-8, and the current SAS session encoding is Wlatin1. By default, SAS assumes that the external file is in the same encoding as the session encoding, which causes the character data to be written to the new SAS data set incorrectly.
To specify which encoding to use when reading the external file, specify the ENCODING= option: 
libname myfiles 'SAS data-library';
filename extfile 'external-file';
data myfiles.unicode;
infile extfile encoding="utf-8";
input Make $ Model $ Year;
run;
When you specify that the external file is in UTF-8, SAS then transcodes the external file from UTF-8 to the current session encoding when writing to the new SAS data set. Therefore, the data is written to the new data set correctly in Wlatin1.

Incorrect encoding can be stamped on a SAS 7 or SAS 8 data set if it is copied or replaced in a SAS 9 session with a different session encoding from the data. The incorrect encoding stamp can be corrected with the CORRECTENCODING= option in the MODIFY statement in PROC DATASETS. If a character variable contains binary data, transcoding might corrupt the data.