Rule CT2001/FDAC340 RACE = MULTIPLE

Hi Ceci,  We are changing

Hi Ceci, 

We are changing this message to Warning.

CDISC CT (RACE) codelist is "non-extensible" since 2013-04-12. I believe that it's completely incorrect and non-compliant with FDA Guidance on collection race and ethnicity. Unfortunately the CDISC team ignores all complains and requests to fix (RACE) control terminology.

Please consider "Errors" messages for RACE check in OpenCDISC Community as a bug. We are fixing it in the next Auto-Update release.

Kind Regards, 

Sergiy

RACE Severity Type

Sergiy and the OpenCDISC Team in general,

If setting the severity type to WARNING is a decision based solely on internal OpenCDISC discussions, I encourage you NOT to change the severity of this message without input from FDA, CDISC, or both. The RACE codelist reflects several conflated issues, and returning to the OpenCDISC v 1.5 approach of masking these issues by de-escalating the message would be a disservice to the broader community.

Taking the original poster’s question first, flagging the use of MULTIPLE as a violation of the codelist is based on an OpenCDISC interpretation of CDISC’s approach to publishing Controlled Terminology. This is counter to the guidance in the SDTM IG, as well as to FDA guidance that indicates a preference for race to be self-reported and to allow for multiple races to be chosen. This is independent of the question of whether the codelist should be extensible.

As to whether RACE should be extensible or not, I think your reading of the FDA guidance is incorrect, and unless you have specific information from the agency to the contrary, I encourage you to not override the CDISC interpretation. Such an override was done in OpenCDISC v1.5, where only the RACE non-extensible message was set to severity type INFORMATION with a message treating it as extensible, while all other non-extensible messages were given a severity type of ERROR.

This had two impacts. First, it complicated the discussion within companies as to how to understand the FDA and CDISC guidance by providing a counter-example from an authoritative source. Second, by being flagged as a INFORMATION, it masked a change made by CDISC, precluding a discussion within many companies.

I welcomed the simplification of Controlled Terminology processing as implemented in OpenCDISC 2.0, and regret to hear that some of the old issues may be reintroduced.

However you proceed, I would note that the ETHNIC codelist should be processed the same way as RACE, as it also is non-extensible and governed by the same FDA guidance.

Regards,

Carlo

Hi Carlo, Yes, we are also

Hi Carlo, 

Yes, we are also changing messages for the ETHNICITY CT check from Error to Warning.

Kind Regards, 

Sergiy

Race codelist

I presume that Carlo's argumentation is based on the following:
- "MULTIPLE" and "OTHER" are not races (of course they are not), so they are not in the list
- Essentially the SDTM-IG states: either take one from the codelist, OR, when the subject states that he/she is of mixed race, then set "MULTIPLE", or when he/she cannot agree with one of those from the list (self reporting), set "OTHER".
In both of the two last cases, at least one record in SUPPDM is expected, in the first case with QNAM=RACE1,RACE2, ... and with QNAM=RACEOTH in the last case.

At least, that is what I understand from the SDTM-IG 3.2, pages 68-69.

So it is more that just "present or absent in the codelist".

Carlo, can you agree on that - you are more the expert than I am.

Race Codelist

A challenge is that the use of "OTHER" in the IG is both outdated and problematic, as it reflects guidence from when the RACE codelist was extensible. 

For "MUTLIPLE" however, this is a keyword used per CDISC guidance to reflect when multiple VALID responses are appropriately collected for a given variable (not just RACE).  To date, CDISC has not represented this term in published controlled terminology, presumably considering it implicit when appropriate, just as with null values, which are also not included.

OpenCDISC's position (I presume) is that CDISC needs to publish the term explicitly for it to be valid, and so reports its use as a violation of the codelist.  The challenge is that FDA guidance explicitly calls for such a mechanism (Guidance for Industry: Collection of Race and Ethnicity Data in Clinical Trials, p. 5):

We recommend that study participants self-report race and ethnicity information whenever feasible, and that individuals be permitted to designate a multiracial identity.

Until such time as either CDISC or FDA issue an explicit rule requirement or clarification, we are left with the OpenCDISC constraint and the need to document when the rule logic is in conflict with published the standard.  A worst case would be for companies to adjust data to the rule (e.g., arbitrarily identify a "primary" value for RACE and override the self-reported aspect of the data).

Separate from this is the non-extensible attribute.  OpenCDISC disagrees with this attribute for RACE, and so consistently strives to minimize the impact of the requirement.  As they know from our past discussions, I think it a concerning precedent when an implementation explicitly alters a standard, regardless of correctness.  That I see the standard as a more correct interpretation of the FDA guidance than OpenCDISC's makes it even more so.

 

Regards,

Carlo

opencdisc community 2.0.2

I noticed that this was an error again after I downloaded the updated for opencdisc community 2.0.2. Is this just a bug or was this intentional?

It's a bug. A fixed version

It's a bug. A fixed version will be available soon.