Discussion: sdtm updates

DISCUSSION: SDTM UPDATESMARCH 2013

Public commentsComments were requested from CDISC for the new and updated domains for SDTM v3.1.4 Batch 1 :

• RD - Reproduction Details / RP – Reproductive System Findings

• IS - Immunogenicity Specimen Assessment• SR - Skin Response• EX - Exposure• EC - Exposure as Collected

CDISC response available

No response from CDISC available yet

Overview of the comments:

Most comments were about : Label inconsistencies, Incorrect Type, CORE and Controlled Term/Codelist/Format informationSpelling errors

Controlled Terminology updatesQuestionsSuggestions

Public commentsUpdate : EX / EC domainIG v 3.1.4, batch 1

Comments (EXOCCUR/EXREASND):EX domain is an Interventions domain and therefore --PRESP, --OCCUR, --STAT

and --REASND are already available, they were only excluded from EX because according to the current Implementation Guide page 85: ‘EX should contain only medications received’ - as this concept is now changed, it's making sense to allow these variables in EX and fill them as in all other domains.

Interventions domain

Public commentsIG v 3.1.4, batch 1

• Also the SDTMIG V3.1.2 section 4.1.5.7 should be updated to document the use of a --REASND in combination with an --OCCUR=N. The table listed in this section is used by many electronic compliance checking tools as the set of allowed situations. It should be clearly stated that for EX/EC an exception is to be made. (Please note I refered to the SDTMIG V3.1.2 as there is not yet an updated version of this part of the IG available)

Update : EX / EC domain

Comments (EXOCCUR/EXREASND):

EXSTAT/EXREASND - In every other SDTM domain, REASND is used for the reason that an observation was not made. In findings domains, this is the reason a test was not done. In events domains, this is the reason that a question about a pre-specified event was not asked. In other interventions domains, this is the reason that a question about a pre-specified intervention was not asked. REASND is populated when STAT=NOT DONE.

In this proposal, REASND would be populated when OCCUR = N.

If it is desired to record the reason why a dose was not given, then a new variable for "reason not given" (or some such) should be created, instead of overloading the existing variable REASND. Even if we don't foresee using REASND for its original purpose in EX, this proposal would create a domain-specific exception to the general mapping of REASND to BRIDG, complicating the process of mapping future BRIDG-based SHARE content to SDTM.

Public commentsIG v 3.1.4, batch 1Update : EX / EC domain

Comments (EXOCCUR/EXREASND):

Public comments

IG v 3.1.4, batch 1

Update : EX / EC domain

It's also good to have the CRF collected dose/units and the protocol specified ones, but in my opinion it would be a lot easier to introduce something like Standard Dose and Standard Units like in the Finding domains, and there the dosage and units as specified in the protocol. The original collected dosage and unit can be kept in EXDOSE and EXDOSU. That would be more clear than making two very similar domains and linking them via RELREC.

Comments (EC Domain):

Public comments

IG v 3.1.4, batch 1

Update : EX / EC domain

Another argument for the EC/EX solution was that the values from EC can be summarized in EX to support analysis. In my opinion this should not be part of SDTM - as SDTM is usually not preparing tables for analysis but should reflect the CRF data as entered, sure some values are derived as well but to put one whole domain which is only derived and summarizing/pooling treatment data is maybe not what SDTM was intended for, for me that sounds more like ADaM.

IG v 3.1.4, batch 1

Update : EX / EC domain

It is indicated that EXVAMT will be deprecated, but it is not clear to me what replaces it. There are no examples showing collected doses based on a preparation step such as an infusion where study drug is diluted to a certain concentration in a vehicle such as saline.

Comments (EC Domain): ADaM?

Public comments

IG v 3.1.4, batch 1

Update : RD domain

In the NCI Terminology Codelists there is a RP (Reproductive System Findings) domain assigned, why did it change to RD ?

Comments :

The Response:It was decided by CDISC that this domain will be renamed to RP (Reproductive System Findings) as per CDISC controlled terminology.

Public comments

IG v 3.1.4, batch 1

Update : RD domain

• “Why RDSTDTC is not spelled out in the list of variables, given that one might want to know when a particular ‘finding’ occurred. What's being collected is RDDTC, the collection date. For some ‘tests’, like PREGNT, it is important to know when a pregnancy began, not simply the collection date. Reconsider this as a findings class.”

Comments :

The Response:RDDTC is the date of the reproductive finding and should not be confused with the collection date relative to when it was recorded on a CRF.

Public comments

IG v 3.1.4, batch 1

Update : RD domain

Control Terminology Suggestions:RDTESTCD – PREGSTAT / RDTEST- Pregnancy StatusRDTESTCD - EARLYTRM / RDTEST - Early Termination RDTESTCD – LIVEBRTH / RDTEST- Live Birth

PREGSTAT -PREGNANCY ONGOING, LIVE BIRTH, STILLBIRTH, EARLY TERMINATION EARLYTRM - SPONTANEOUS ABORTION, THERAPEUTIC ABORTION, ELECTIVE ABORTION, OTHER LIVEBRTH - NORMAL, BIRTH DEFECT, OTHER

The Response:Suggestions for controlled terminology should be send to the NCI EVS for consideration upon the release of the domain in provisional status.

Public comments

IG v 3.1.4, batch 1

Update : IS and SR domains

Public comments

IG v 3.1.4, batch 1

Update : IS and SR domains

Comments:• IS needs controlled terminology. Many of the tests used as

examples are existing LBTESTCD codes - either existing terminology e.g. HCAB or extensible e.g. as in Example 3. Will they be copied from LBTESTCD terms? Will they then be removed from LBTESTCD terminology?

• Will ALL Serology and Immunology tests now reside in this domain rather than LAB? How about VIROLOGY? Can you provide a list of tests which will move? I think this needs clear guidance as the definition of serology/immunology in relation to specific testing can be rather vague. Defining the CAT for each LBTESTCD/ISTEST would be helpful.

• Please explain why you don't have an upper limit of quantitation. We have serology data that requires this

.

Public comments

IG v 3.1.4, batch 1

Update : IS and SR domains

Comments:• I am concerned about moving categories of data out of LAB into

their own domain. Generally all the categories fit well within the existing LAB domain and may only need a few extra variables. My preference would have been to keep serology and immunology and viral within LAB but add extra optional variables to LAB e.g. ISLLOQ & ASSAYV with examples of how to use them. Dividing the data up too much leads to problems when people have different opinions as to whether this data is immunology or virology or biomark. We end up having the same data in different dataset domains due to study team preference. Does LAB just end up being haem, chem and urine?• ISTEST: Immunoglobulin E is given as an example in the CDISC notes and HCAB in example 1. These are already a lab test codes. Will ISTESTCD/ISTEST share same codelist as LB? If so, how will users know whether to report results in LB vs IS? Does purpose of test determine domain to use?

• Any specific reason why the data from IS can't be included in LB, differentiated by LBCAT?

Public comments

Summary of comments on v3.1.4 batch 1:

For the EX/EC/IS domains a lot more thought should go in there so that there is no duplication of information and a review of the quality of work to be reviewed by users should be done.

Non-standard variables

Supplemental QualifierDatasets

Non-standard variables

IG v 3.1.4, batch 2

Update : Non-standard variables

Biggest Concerns:

• Dataset Size• Validation• Cost Impact

NSVs in standard domains

IG v 3.1.4, batch 2

Update : Non-standard variables

Permitting NSVs in parent domain will likely produce datasets that are very wide and sparse in the NSV columns.

Practical

While SAS v5 XPORT files remain as the transport mechanism, sparse datasets will result in big files, which the US FDA openly complains

Reviewing wide datasets is very unlikely to improve review efficiency as mentioned in section 3.

There is also the issue of additional file size that is sure to occur from the NSVs being included in the datasets, which flies in the face of often repeated comments from CDER that we should not have dataset files that area "too big". Most of the records will likely not even have data for many of these NSVs, yet they will have the variables and the character spacing for them. The increase of the file size (for all files with Supplemental Variables) should be carefully weighed against the benefit of the "ease of use" by only some reviewers.

SuppQual increases the overall complexity of SDTM. SDTM isn’t easy to understand and explain. Jettisoning the SuppQual would make it a lot more appealing.

Separating data that belongs together in two datasets is confusing. Given that SuppQual is transposed it is even more confusing

Data transparency would be increased if extra variables were allowed.

"Please develop this. This would make the SDTM datasets more operationally useful, which is likley to lead to better transparency. More information is needed. Varied examples in the IG would be helpful."

No. While this may address some challenges, it will create others, and we think that therapeutic area development is an overriding priority.

NSVs in standard domains

IG v 3.1.4, batch 2

Update : Non-standard variables

Practical

Validation

The compliance-checking is a particularly worrisome prospect. How can a dataset be standard if it isn't?

If CDISC flips their fundamental constructs around as they did when moving from v2 to v3, especially when this is purely a matter of preference, I, and others, will throw up my hands in disgust and question the validity of the CDISC "standard".

Compiling NSVs into SUPPXX domain structure requires complex programming and subsequent QC algorithms.

Working on studies, when reviewing dataand confirming NSV's, it was found best to have them linked to the parent domain.

Programming and data review is more cumbersome and time consuming in SUPPXX structure. Much time is spent by sponsors programming teams removing NSV data from the original source parent domain where it is collected and moving it to the SUPPXX domain. Then again for internal data review sponsors must put the data back to the parent domain where it logically should be reviewed from.

At GSK we have invested millions of dollars and several years into developing an SDTM-compliant submission data development system. The creation of SUPP datasets are embedded into this system and are an integral part of the what defines the standard. Everyone knows that SUPP datasets can be transposed and merged for operational purposes. The existence of a standard is supposed to protect sponsors from having to adapt to various user preferences. To change SDTM to make it "optional" to include NSV in the main domain dataset will mean that reviewers will request it, so GSK would by necessity be forced to redesign our data creation and compliance-checking systems at great expense.

NSVs in standard domains

IG v 3.1.4, batch 2

Update : Non-standard variables

CostThe SuppQual paradigm favours larger companies that can provide the infrastructure and staff to handle the increased complexity associate with SuppQual operations

Companies with existing SuppQual infrastructure or companies that derive revenue by managing SuppQual for other companies will be advocating to keep the SuppQual paradigm.

The current SuppQual convention ignores the fact that not all data is ultimately submitted to the FDA so the SuppQual costs are incurred without benefit. Given the rate of failure in pharmaceutical development this doesn’t seem optimal.

NSVs in standard domains

IG v 3.1.4, batch 2

Update : Non-standard variables

CostFor organizations that have already invested significant resources into developing a system to handle raw data at the operational level and then create SDTM compliant data, there would be an obvious negative impact. These organizations have already found a way to collect and clean the data, then separate the non-standard data into SUPPQUAL sets. If this proposal eliminates the SUPPQUAL, the investment of resources is lost.

This is not however the only potential cost. Dependent upon how the proposal is developed, for all organizations the potential exists that adding NSV data to the standardized domains will require study level custom programming to draw these in the ADaM data. (As SDTM stands, NSV data is 100% predictable – values always appear as QVAL, transposed varnames are always in QNAM, etc.) Creating standardized programming to build analysis datasets is easier in the current model.

Dropping the use of SuppQuals in favour of using NSVs is a very good idea for the following reasons: Maintaining the infrastructure to transpose and merge SuppQual variables for operational, non-submission business use case is substantial. With the current standard extra costs are incurred not matter which paradigm a pharmaceutical company chooses. • The cost of converting operational, wide data sets to strict SDTM with SuppQual is expensive. • The cost of converting strict SDTM with SuppQual to operational, wide data sets is expensive.

We are not in favour of the proposed change. We do think that there would be a heavy cost impact because of the work that would need to be undertaken to change existing standards as implemented by industry. We feel that the change is not backwards compatible with existing work. The impact to validation via OpenCDISC or other tools should also be considered. The possibility that this will open the door to the inclusion of more derived variables in SDTM data is also a concern

NSVs in standard domains

IG v 3.1.4, batch 2

Update : Non-standard variables

Cost

No. Roche's "operational" SDTM datasets include NSVs. Roche has a standard procedure to separate the operational datasets into parent and supplemental qualifier domains and create study metadata (define.xml).

As SDTM exists today, the SUPPQUAL supports collection of standardized data. Using the SUPP- - to extend the standard requires additional effort. Sponsors are incentivized to look for existing variables that meet each purpose or to find related datasets (e.g., FA) to contain data. Should a sponsor find no other way to meet the standards, sponsors are more likely to create a review process to justify the deviation from accepted industry standards. (To properly build a SUPP- - domain for submission requires planning, programming resources, QC effort, etc.) By simplifying the ability to add non-standard data, this proposal increases the temptation to work outside the established standards and possibly negate the gains provided.

NSVs in standard domains

IG v 3.1.4, batch 2

Update : Non-standard variables

GeneralYes. Roche has queried members of TBI and the consensus support this proposal. Roche would like to see this proposal prioritized and expediently pushed through the SDS development process. Given the resource requirements of the TA standards development, Roche encourages CDISC to explore alternate resourcing methods. For example, could this proposal be formalized as part of an FDA/PhUSE project?

This will also be much easier to use the variables in ADaM.

Consequently, we at BI support this proposal of keeping NSVs in the parent domain with clear rules such as standard variable prefixes (ie) SP_NSV. This would help streamline SDTM dataset creation and subsequent data review.

Any Comments ?