SDTM question for EPOCH variable

EPOCH

Epoch is a permissible variable in CDISC, but it's also a variable requested by FDA in CDER Common Data Issues document and should be included in the dataset for these domains:

Thanks.

Thank you mdigian  for your response!

Epoch variable added by FDA to existing standard

This is an example of the very bad practice that a stakeholder is changing the standard after its publication, where it had the opportunity to request for the incorporation of the variable during the review period. How can we trust standards when a stakeholder deviates from it and creates its own "dialect"?

Thanks again!

Thanks, helpful answer, and something that's not easy to discover from the FDA website!  Downloaded OpenCDISC just a couple of days ago and already it's proving very helpful!

CDER Common Data Standards Issues Document

This was published in December 2011 by the FDA, a major stakeholder of the standards.  

http://www.fda.gov/downloads/Drugs/DevelopmentApprovalProcess/FormsSubmissionRequirements/ElectronicSubmissions/UCM254113.pdf

SDTM 3.1.3 was published after this guidance.    Do you know if CDISC simply chose not to change EPOCH's core value from Perm to Req for certain domains ? 

EPOCH variable - location

Hi,

Anyone know where the EPOCH variable should go in the table?  At the end?  After all the --DTC/--DY variables?  Anywhere?

Thanks,

Rosie

Hi Rosie,  A position of any

Hi Rosie, 

A position of any variable including EPOCH is defined by SDTM Model.

E.g., for SDTM v1.4 see a Table 2.2.5 (Timing VAriables for All Classes) on page 19:

VISITNUM

VISIT

VISITDY

TAETORD

EPOCH

--DTC

--STDTC

--ENDTC

--DY

....

EPOCH should be just before --DTC, --STDTC variables.

Kind Regards,

Sergiy

Thanks, Sergiy!  I was using

Thanks, Sergiy!  I was using the SDTM IG and forgot about the SDTM doc.  Really don't understand why they publish them as separate docs...

Why MH need EPOCH?

Hi mdigian,

I don't understand why MH also need an EPOCH variable? All MH records are supposed to be collected during screening phase.

1 SDTM (Model) --> Many IGs

Think of the SDTM 1.x as the generic model for the 3 general observation classes: FINDINGS, INTERVENTIONS, EVENTS.  It defines the blue print and superset of variables available for those classes.  The order of variables is a general starting point.

The IG then inherits and implements a generic class as a domain while supplying domain specific semantics (controlled terminology assignments, assumptions, prohibiting use of some variables).  In some cases, the domain will override the variable order.  in the case where a variable is not mentioned and not prohibted, its order is inherited from the parent class.

This is why they publish two separate docs.  Base Parent (Model) and IG (instance of model).

SDTM 1.x is implemented by the following:

1. SDTM-IG 3.x (clinical/human)
2. SEND-IG 3.x (non-clinical/toxicology/animal)
3. AP-IG 1.0 (Associated Persons)
4. MD-IG 1.0 (Medical Devices)
5. PGx-IG 1.0 (Pharmacogenomics/genetics)
6. TA-UGs (currently over 20 Therapeutic Area User Guides)

Why MH need EPOCH?

Why MH need EPOCH?

EPOCH for all clinical subject-level observations

Short answer, FDA requires it in their Tech Conformance Guide: http://www.fda.gov/downloads/ForIndustry/DataStandards/StudyDataStandards/UCM384744.pdf

"..variable EPOCH  should be included for every clinical subject-level observation ... This will allow the reviewer to easily determine during which phase of the trial the observation occurred as well as actual intervention the subject experienced during that phase"

My take / long answer...

while MH is "supposed" to be collected during screening phase, perhaps a use case will develop where it is collected throughout the study.  Perhaps for early stage alzheimer's.    The other use case is if some database warehouse or tool wants to stack all EVENTS observations into one table.   Having EPOCH populated for medical history will allow a consistentency in the combined view.   Finally, at any point during a study (especially for pediatric studies) it's possible someone could simply offer up more medical history than what they previously recalled.  Or a parent/guardian recalls something signficant about their child in a study which was not previously recorded.   

Bottom line, from a tech perspective (mapping), it's easy just to hardcode this variable to SCREENING if that is your case and move on to more challenging endeavors.

Take care, 

Mike.

Thanks so much, it is very

Thanks so much, it is very helpful.

EPOCH on CM domain

Hi,

1) How would you populate the EPOCH variable in the CM domain in the event that dates are partially known? Does one needs to impute dates in order to determine the EPOCH?

2) What if the CM dates indicates that the medication was taken long before the study screening period? for example few years before the study ever conducted, will it be accurate to mention the EPOCH as screening period?

Thanks,

Liron

Epoch on CM

partial dates: do NOT impute EPOCH (imputations are not allowed in SDTM).

medication taken long time before study start:
EPOCH is an extensible codelist. So you can add your own terms. For example, you could add "PRESCREENING" to the codelist in the define.xml (do not forget to add the attribute def:ExtendedValue="Yes") to the "CodeListItem" or "EnumeratedItem" element, and use that for all dates (also partial ones) that are clearly before the study start date. For example "2015-01" is clearly before the study start date "2015-02-01".

As explained in http://cdiscguru.blogspot.com/2015/08/epoch-expected-in-most-sdtm-domains-why.html this is a ridiculous requirement of the FDA, as EPOCH can easily be automatically be derived and added as tooltip or column by the tools that the FDA is (or should be) using. It took me less than 2 hours to do so in my visualization tool.

Thank you

Thank you

Epoch not generally applicable to MH

Long comment to an old post dropped (belatedly saw dates)

A few comments: While MH is

A few comments:

1. While MH is typically collected during screening, the timing of the events captured in MH is, by definition, before the screening epoch (medical events occurring during or after screening are AEs).
2. Epoch timing periods are by definition during the study.  Epoch describes the timing of the occurrence (event/intervention/finding), not the collection of the occurrence. By definition, events occurring prior to the first defined epoch (generally screening) cannot have a value for epoch.
3. From the above two comments, it is expected that MH events would not have a value for the EPOCH variable.  As EPOCH is a permissible variable, when null for all records it should be omitted from the dataset.
4. This is also true for all pre-study records, so while the EPOCH variable should be in CM, it should not be populated for prior medications taken historically before the study.

EPOCH in MH

Here is a 1:1 copy of what is in the latest "Study Data Technical Conformance Guide" (October 2015):

"Please include the variables EPOCH for every clinical subject-level observation (e.g., adverse events, laboratory, concomitant medications, exposure, vital signs). This will allow the reviewer to easily determine during which phase of the trial the observation occurred (e.g., screening, on-therapy, follow-up), as well as actual intervention the subject experienced during that phase.. Inclusion of ELEMENT and ETCD (element code) is desired as well, to help reviewers understand timing of events whose durations span multiple epochs. However, because of implementation challenges associated with this request, CDER is not yet requiring these for submission of SDTM data". (see http://www.fda.gov/downloads/ForIndustry/DataStandards/StudyDataStandards/UCM384744.pdf).

So the previous statement of one of the contributors "... it's also a variable requested by FDA in CDER Common Data Issues document and should be included in the dataset for these domains" looks like a complete overinterpretation of the FDA's position.
"Please include ..." does not sound like an obligation to me, and "e.g. adverse events ..." does not sound like a complete list (MH is even missing in that list). So I think this rule should either disappear or be downgraded to "INFO".

BTW, reviewers should be able to derive EPOCH themselves - it is really piece of cake to do so.

Best regards,

Jozef

EPOCH discussion in Tech Guide vs. Pinnacle Rule Implementation

Replying at the top level, as nesting getting burdensome...

Overall, my understanding of the Technical Conformance Guide is that the agency did NOT impose a new interpretation on EPOCH, but rather that they have promoted it, for submissions to them, in applicable domains from a Core attribute of Permissible to Expected in SDTM parlance. This is still threading the needle on interpretation, but it seems to make sense from the quoted language.  This is how I have understood it, and so would generally disagree with any rule violations around requiring EPOCH in MH if they did occur (documenting as appropriate).

As to the rest, only FDA and Pinnacle21 can really speak to rules or requirements that go beyond compliance/conformance to the base model.  For such rules (both FDA and PMDA at this point), my understanding is that these have evolved through agency discussions, both internnaly, and with Pinnacle21 staff. As I have said to Pinnacle21 staff, the challenge with the published FDA rules is that they identify rule messages (as opposed to logic) as they appeared at the time (2014?) in the OpenCDISC software, which is not necessarily sufficient or appropriate to define all rules.

In the absence of a more robust specification, the industry is left with the Pinnacle21 interpretation as de facto guidance, with a need to critically examine the vendor implementation for correctness (a requirement regardless of circumstance or vendor to my mind), and with an avenue for documenting differences in understanding (Reviewer's Guide). 

Regardless of any additional burdens this may impose, I advocate that Reviewer's Guides not be seen as punative, but rather as a clear line of communication between sponsor and agency.

Regards,

Carlo