FDA – Just Tell Me What You Want
“I just want to know what we need to do?”, “why can’t they tell me what they want?”, “are standards mandated?”, “do we need to be CDISC compliant next year?” These are some of the questions I hear at clients and conferences. And the organisation being referred to is of course the FDA.
Well good news. They have indeed told us what they want. Well a significant part of the FDA has told us what they want. The Center for Drug Evaluation and Research (CDER) have released a succinct ten page text entitled, “CDER Common Data Standards Issues Document.” The document discusses the CDISC standards – SDTM, ADaM and SEND – their use, some CDER wishes when using the standards, terminology and highlights some common errors. You can find a PDF on the Study Data Standards for Submission to CDER web page (a very useful page, the PDF is the first in the list, but this is a direct link to the PDF).
The document is incredibly useful. Why? Well consider the opening sentence:
The Center for Drug Evaluation and Research (CDER) is strongly encouraging sponsors to submit data in standard form as a key part of its efforts to continue with advancement of review efficiency and quality.
Good, CDER wants standards. The remainder of the first paragraph then talks about the CDISC standards. So they want standards and they want the CDISC standards. The second paragraph reflects on the submissions CDER has received to date and comments that everything is not what it should be:
however, due to differences in sponsor implementation of the standard, CDER has observed significant variability in submissions containing “standardized” electronic clinical trial data. CDER has received numerous “SDTM-like” applications over the past several years in which sponsors have not followed the SDTM Implementation Guide.
The paragraph concludes with:
The goal of this document is to communicate general CDER preferences and experiences regarding the submission of standardized data in order to aid sponsors in the creation of standardized datasets.
So, they want standards, they want CDISC standards, they want them this way and please read the Implementation Guide. It seems pretty clear to me.
Contents
There are two final paragraphs on the opening introductory page, the first about the need to communicate with the center – please note the US spelling for all my US colleagues – regarding submissions. We all know nothing beats good communication and the final paragraph states that the document will be updated in the future and notes the CDER data standards website which is a very useful resource. The remainder of the document goes into details about using the standards and what CDER would like to see in particular circumstances. To get a flavour of the document see the contents in the image to the right.
I will draw your attention to three paragraphs at the bottom of page 3 and the top of page 4. The first of the three paragraphs starts with:
The ideal time to implement SDTM standards for representation of clinical trial tabulation data is prior to the conduct of the study. The use of case report forms that incorporate SDTM-standard data elements (such as with CDASH-style case report forms) allows for a simplified process for creation of SDTM domains. This approach is preferred to the alternative of collecting data in a non-standard format and then converting to SDTM format after the trial (legacy data conversion).
The document then discusses legacy data conversion and the need for traceability and concludes with words about the potential pitfalls of late-stage conversion:
CDER has received applications in which the converted SDTM data sets were not consistent with the submitted analysis datasets and study report analyses, thus causing confusion during application review.
The FDA complains about inconsistent SDTM and Analysis
This last point about consistency is important and I believe both this and the traceability problem will become important issues in the coming years.
There are a couple of additional references that are worth reading. One is the new draft amendment 1 to SDTM that can be found on the CDISC website while the second is a guide to ensuring that define.xml schema validates. The define document is not new as it has been around a good while but I think it’s existence is not well known.
In this post I have picked out particular quotes and presented them as though they are the most important items to note. They are not. The whole text is important and I recommend that those working in the area of submission and/or standards should read the whole document carefully.
So this is all related to CDER, what about the Center for Biologics Evaluation & Research (CBER)? Well look at the CBER web page because the center is accepting SDTM submissions but it would be best to follow the information on the web page.
2 Responses to “FDA – Just Tell Me What You Want”
Comments
Read below or add a comment...
The point about the traceability problem is very interesting.
Using global identifiers for each single piece of data could be useful in improving traceability. This is done in other domains, such as for spending data in local UK government, e.g. http://spending.lichfielddc.gov.uk/spend/8605670 identifies one individual payment. This is a so called http-based URI (Uniform Resource Identifier). So, how could a URI look like for an observation in a clinical study? In a recent presentation in the CDISC Interchange Europe conference 1) you can see some examples (slide 40) for linking clinical data using URI:s
Also, using a data provenance approach to represent a detailed view on the life of a single pieces of data, using standards such as the Provenance Vocabulary 2), could be useful in improving traceability. Both for both data creation/capture, and for access/derivation
1) http://www.slideshare.net/kerfors/linking-clinical-data-standards
2) http://sourceforge.net/apps/mediawiki/trdf/index.php?title=Guide_to_the_Provenance_Vocabulary
This CDER document is a great step forward, as it also allows us to design (new) studies with the (future) expectations of CDER for our later submission of that study in mind (although things can change). This complements to the thought “set up studies with submission in mind”.
The document however contains a number of glitches but also some frightening things. A few examples:
- “Additionally, sponsors should refer to the Amendment 1 to SDTM V1.2 located at the following CDISC.org site”.
This amendment is still in public review and thus can still change. So I think it is a bit too early to refer to this document. The latter also contains some surprising things, such as new derived or “look up” variables which should not be in SDTM (I will blog separately about that).
- “As a transition step, CDER prefers that sponsors submit both the define.pdf and define.xml formats. CDER will advise when it is ready to only receive define.xml.”
Whoops! Six years after the publication of the define.xml standard, CDER seems still to be unable to implement it in its IT systems. Is that the reason they still want a define.pdf or is it because a PDF can be printed out and so the reviewers can take it home? Is printing out not a giant security risk? Would you, as a sponsor, like it to hear that a reviewer left the printed metadata about your study on the Washington metro on his/her way home?
- “Please include the variables EPOCH, ELEMENT, and ETCD … for every subject-level observation”.
This information is already available in the “trial visits” domain (TE) in the variable TVSTRL. So if VISITNUM is given (one could change it to “expected” in the next version of SDTM) a simple lookup would be sufficient to retrieve the information.
I agree that this is a minor issue, but it is replication of information.
- “The SDTM Implementation Guide (SDTMIG) should be followed carefully.”
In my opinion this conflicts with the previous statements about the (not-yet-approved) amendments and the statement about including “EPOCH” etc. If these are CDER requirements, they should go into a new, updated version of the SDTM-IG (and which should have a new version number by the way).
- “The size of the LB domain is often quite large and can exceed the reviewers’ ability to open the file using standard-issue computers. This size issue can be addressed by splitting the large LB dataset …” and “Sponsors should submit these smaller files in addition to the larger non-split standard LB domain file”.
This is a pretty dangerous statement. If the “full” LB.xpt file cannot be opened by the reviewer, could it then be opened by the sponsor? Or does CDER here require sponsors to submit a file that sponsors cannot open themselves? If the latter is true, how can the sponsor then validate that file? Or should the sponsor submit a black box?
- “Permissible variables in SDTM that CDER expects to see include: …”
Well if they are expected by CDER, then they should be listed as “expected” in the SDTMIG isn’t it? Or do we allow several versions of the SDTMIG: one for CDER, one for CBER, one for … ?
The statement also conflicts with the statement “The SDTM Implementation Guide (SDTMIG) should be followed carefully”.
- “Dates in SDTM and SEND domains should conform to the ISO 8601 format … Missing components should be handled by right truncation ..”
A minor issue, but this is not a correct statement for incomplete dates and times (this is NOT the same as partial date and time). ISO 8601 requires the missing part to be replaced by a dash. For example if the month is unknown, ISO8601 requires yyyy—dd (remark the middle dash).
- “SDTM should not include any imputed data”.
It would be nice if CDER defines what the word “imputed” means, as there may be different explanations/interpretations in different cultures (P.S. I am not a native english speaker). If it was meant that no values should be added to replace missing values, then the statement is correct. If it means that SDTM should not include derived data, then the statement is incorrect, as SDTM is (unfortunately) already full of derived data.
Further this an excellent document, giving us a lot of information, and repeating many of the “good practices” that experienced SDTM implementors already know.
P.S. I also mailed my comments to the FDA separately.