CDISC SDTM IG for Associated Persons 1.0 Overview

1. CDISC SDTM IG for Associated Persons 1.0 Overview March 2016 – DC CDISC user group Michael DiGiantomasso -

2. Foreword • Data • about people …. • not in the study …. • that could affect study subjects … • or who have been accidentally exposed • There are hardly any new concepts. The key is separation to avoid ambiguity and confusion

3. Contents • Overview • Document Keys • History • Examples • Specification table • Single-Domain • Special Purpose • Interventions • Events • Findings • Multi-Domain • Purpose • Prerequisites • Definition • Intention • Data not applicable • Use Cases Conformance Rules CDISC SDTM IG 3.2 • Core Concepts • Data Separation • Domains • Variables • Identifiers • Relationships • Conclusion • Goals • Questions

4. Document Keys

5. History AP is already 2+ years old

6. Definition • An AP classifies the non-subject participants in a clinical study, and the data of interest about them. • non-subject participants may be associated with • the study itself (when no clear relationship exists) • a study device • a study subject • family member • caregiver • organ donor

7. Data Not Applicable • Domains which describe a subject’s progress through a study (SE, SV, DS)are not allowed for associated persons since they…. • are not in the study (screened nor randomized) • do not have their own visits • do not participate in epochs • are not dispositioned

8. Technical Intention • data collected about APs may be important to • understand & analyze study data • follow an AP for potential adverse reactions • AP-IG is based on the assumptions that it may be necessary … • to distinguish Associated Persons (AP) data from subject data • to physically keep AP and study subject data separate in a • data submission • data warehouse • It is unknown how a user might query for data in a data warehouse… • the mechanisms for keeping AP data from being confused with subject data will be described in “Core Concepts” slides

9. Use Cases CDISC Disclaimer: “The use cases listed below have come to the attention of the SDS Team. It is probablynot an exhaustive list.” • Family history: data about a subject’s family members • Donor info: original owners of donated organs, blood, tissues, etc. • Caretakers: a questionnaire administered to the caretaker of a study subject about their experience as a caretaker • Sexual partners: demographics, sexual and/or pregnancy history of the study subject’s sexual partner • Environmental exposure: the smoking habits of a person who lives in the same household as a study subject • Diagnostic samples: when study topic is an investigational device,…the tissue or blood sample dasta used in a diagnostic test can be an AP • Accidental study treatment exposure: • someone (not enrolled) is exposed to a study treatment (e.g., estrogen cream, radioactive isotope),…their exposure (APEX) and adverse event data (APAE) is needed • There may not be a study subject to whom the associated person is related. • Operator accidents: • adverse event data (APAE) about research staff who are injured while using an investigational device, especially when the device is the topic of the study • There may not be a study subject to whom the associated person is related. • Source / Contact Case Investigation (highlighted in TAUG TB 2.0) – not mentioned in AP IG

10. TA Use Cases • Risk and disease transmission for Infectious Disease (S/C Case) • TAUGTB (Tuberculosis) 2.0 • TAUG EVD (Ebola Virus Disease) 1.0 • the non-study subject from whom the study subject likely contracted the disease. • the non-study subject who may have contracted the disease from a study subject . • Family History • TAUG Dyslipidemia 1.0 • Cancer Studies • Polycystic Kidney Disease (PKD) • Immunosuppressive Therapy / Solid Organ Transplants • Any trials collecting data about organ donors • Any study that solicit pregnant women, since by default their offspring would be an associated person

11. Core Concepts • Data Separation • Domains • Variables • Identifiers • Relationships

12. Data Separation • datasets are given a prefix of AP-- to distinguish them from study subject data. • AP domain codes belong in the DOMAIN column • prefixed with AP • 4 characters long. • Domain label names begin with “Associated Persons” • records require the population of the APIDvariable. That’s it…

13. Domains • AP domains parallel … • general observation class • Demographics (DM) • Comments (CO) potentially • AP domain structure is same as those for study subject domains • Exception: variables that only apply to study subjects are prohibited (USUBJID, SPDEVID) • all other general assumptions about SDTM and SDTMIG variables and domains will apply to AP data • Domain naming conventions by example • APDM - demographicdata collected about an associated person • APLB -labdata about an associated person • APMH - medical history about an associated person • APFASU - findings about the substance use of an associated person • SQAPDM – supplemental qualifiers for associated person demographics • SQAPFAMH – supplemental qualifiers for findings about medical history of an associated person • AP Variable prefixes will NOT include AP • There is one special purpose domain APRELSUB which will be discussed in the “Relationships” section

14. Identifier and Qualifier Variables

15. Timing Variables • All general date variables are allowed. • Study-basedtiming variables • can be used to place an AP record in the study context for the related study-subject • not appropriate if the AP is associated only with • the study • Non study-subject device • If an AP has relationships with multiple study subjects, • study-based timing variables may be ambiguous: use with caution

16. Variables not to be used 4 sets of Demographics variables that only apply to study subjects • RFSTDTC – Subject Reference Start date • RFENDTC – Subject Reference End date • RFXSTDTC – First study treatment date • RFXENDTC – Last study treatment date • RFICDTC - Informed Consent date * • RFPENDTC – End of Participation date • ARMCD - Planned Arm Code • ARM - Planned Arm • ACTARMCD – Actual Arm code • ACTARM - Actual Arm * Informed Consent only applies to being in the study. An associated person is not in the study, so consent in that context does not apply. Naturally, if a person is identified as an AP after they have been accidentally exposed, or for which the protocol wants to collect information for other reasons after the study started, then the concept of “consent” probably occurs in that context. Post study informed consent would be in SQAPDM (suppqual for associated person demographics). With regard to the information for a donor, they most likely already gave consent or license to use their organ(s), and in doing so provided any information needed that would be part of an AP domain for a donor.

17. AP Identifiers • not always collected and often must be generatedby sponsors. • ~ artificial process to allow APs to relate to study subjects outside the CRFs • unique items (subject IDs, domain codes, visit #) can assist in the creation • CRFs often collect data acrossdomains. Sponsors should be careful to • preserve known data relationships • avoid an appearance of a relationship where none exists or is unknown. • sponsors who already have a method of identifying APs… • may need to assign new APIDs for submission (APIDs are not required to be unique outside of a study) • If uniqueness is intendted, that should be indicated in the SDRG • 3Points to consider: • same APID should always identify the same associated person. • allows sponsors to maintain relationships between data split into different domains • allows reviewers to see that the relationship exists • distinct APIDs should be usedwhen there is no known relationship • AP Identifies a single unit: (a single person OR a group/pool of people) • Differentiation between single person vs. group should be apparent. • APID naming conventions will aid reviewers when data contains a mix of single and group APs

18. It’s all about Relationships

19. CDISC Codelistfor Relationship • CDISC/NCI provides an Extensible vocabulary • C100130 – Relationship to Subject (RELSUB) • 54terms • 4 categories • Familial • Spouse/Sexual Partner/Friend • Health Care Providers • Donors • AP data may be collected because they bear some relation to an investigational device (i.e. SAMPLE DONOR) • If AP is related to a subject, the RELSUBcodelist should be consulted above • If AP is related to an investigational device, other terminology may be needed. CDISC does not provide http://evs.nci.nih.gov/ftp1/CDISC/SDTM/

20. CDISC RELSUB Codelist Items Many terms for targeted specificity

21. Relationship Rationale • The relationship to a study subject is often the reason for collecting data about that AP and is reflrectedin SRELvariable. • Multiple relationships • may be collected in additional values of SREL, The most relevant relationship should be first.. • Example: a child with a debilitating disease is a subject and the associate person is the Aunt and Caregiver • Study 1 is concerned with paternal relatives’ family history only • AP is an AUNT, BIOLOGICAL PATERNAL who is also a CAREGIVER • Study 2 is concerned with Affect of disease on subjects' caregivers' QoL • AP is a CAREGIVERwho is also a RELATIVE. • APEX and APAE collection reason is implicit • APEX - study treatment exposure, most likely by accident. • APAE - adverse events, most likely from exposure to study treatment or an accident involving an investigational device • relationship should explain how the accidental exposure occurred. • If no relationship exists, default is “ACCIDENTAL ASSOCIATION” with the study, • (i.e. if study treatment was delivered to the wrong hospital patient through a clerical error) • Relationship vocabulary can overlap withevaluators. • same values can appear in the variables SREL and EVAL. • unless data are collected about the evaluator, that person is not an AP. (don’t get overzealous about using AP) • Ex: a caregiver provides evaluations of a subject <> not an AP data about the caregiver was collected, such as a questionnaire assessing the caregiver’s quality of life.

22. Multiple Relationships and APRELSUB • A relationship must exist for a non-subject to be an associated person. • Single Relationships • fairly common and are easy to comprehend • does not require APRELSUB domain • relationship is specified explicitly in the AP domain using SREL • Multiple Relationships • 1 Associated person ... • having 1 to many relations • to 1 to many Subjects/Devices • 1 AP to many relations: SREL = MULTIPLE • 1 AP to many subjects: RSUBJID = MULTIPLE • APRELSUB must be used to record 1 record per relationship and has 4 variables of interest • APID – Associated Person • SREL - Relationship • RSUBJID – Related Subject • RDEVID – Related Device • APRELSUB is similar to the RDF model that uses Subject-Predicate-Object triples:

23. APRELSUB assumptions • Allowed relationships • associated person  studysubject • associated person  studydevice • Prohibited relationships • study subject  associated person • study device  associated person • associated person  associated person

24. APRELSUB Examples Ex 1: two study subjects received donated organs from same AP, who was biologically related to one of them. critical for immunosuppressive therapies for solid organ transplants Ex 2: include all APs even though only one has multiple relationships to the subject Ex 3: caregivers and family members. The sponsor chose to include only those APs with multiple relationships

25. AP Domain Examples • Specification table • Single-Domain • Special Purpose (DM) • Interventions (EX,SU) • Events (AE, MH x 2, ) • Findings (8: [LB,QS,RP,SC] x 2 • Multi-Domain (2) • AP domains are based on domains from other IG • therefore documentation is generally limited to examples. • The domains in this IG do not include all possible AP domains, • those involved in the use cases which came to the attention of the SDS Team and led to the development of this IG. • Additional domains may be included in future versions

26. Example: AP Specification Table

27. Example: Single Domain – Special Purpose APDM • Associated Persons Demographics • Not required • Only submit if data is collected about APs • If POOLDEF records exist and demographics about the pool is collected, otherwise submit for each individual in pool • Example: CRF collects organ donor demographics • D456 = donor • TRS_0520DS_056 = Recipient study subject

28. Example: Single Domain – Interventions APEX • Associated Persons Exposure • Assumptions • accidental exposures to study treatment • If an AP is related to a study subject, that relationship should be captured • If no relation between an AP and any study subject, SREL = ACCIDENTAL ASSOCIATION • Example: • study treatment was inadvertently dispensed to someone other than the intended study subject

29. Example: Single Domain – Interventions APSU • Associated Persons Substance Use • family history: CRF asks about the subject’s mother’s drinking and smoking habits • document environment exposure: second hand smoke • CRF asks about smoking habits of up to five household members. Subject lives with only 3 people x x

30. Example: Single Domain – Events: APAE Associated Persons Adverse Events - CRF collects data about a Device Operator (DEV_2011_OP04) with no related study subject CT Scan Operator exposed to radioactive contrast agent x X X X 04 2008 05 X

31. Example: Single Domain – Events: APMH • Associated Persons Medical History • study subject 2011-02-02-031 has family members who have been diagnosed with PompeDisease • The CRF collects data about both • single-person APIDs (mother, father) – naming conventions with “N” • group APIDs (siblings, cousins) – naming conventions with “NS” 2

32. Example: Single Domain – Findings: APLB Associated Persons Laboratory Test Results • CRF is collecting lab information about an organ donor • D456 = donor • TRS_0520DS_056 = Study Subject Example: FDA submission of Viral Serologies and other related data for donors in a Tacrolomius study – extremely complicated and hard to understand without AP

33. Other Examples for Single Findings Domain • Associated Persons Questionnaires (APQS) • Caregiver Quality of Life (CGQOL) questionnaire that the caregiverof a study subject completes • Associated Persons Reproductive Systems (APRP) • find out if the subject’s female partner became pregnant during the study • Associated Persons Subject Characteristics (APSC) • CRF is collecting blood-group information about a donor

34. Multi-Domain Example 1 • Accidental exposure of a study treatment to non-study subject • Exposure triggers and adverse event

35. Multi-Domain Example2 • CRF collects data about a subject’s family history relating to Polycystic Kidney Disease (PKD). • data collected about them falls into 6 domains • APMH - Medical History • APDM– Demographics • APSC– Characteristics • APPR - Procedure • APSS - Survival Status • APDD - Death Details • APRELSUB- AP to Subject Relation

36. TB Exposure and Risk Factors • Two Types of investigation: • Source case : identify from whom the subject contracted TB • Contact case: identify those who came in contact with a subject diagnosed with TB • Passive – AP self refers / presents them self • Active – Investigator looks for contacts Evaluate TB strain characteristics Evaluate risk of exposure Associated Persons Domains are essential for Infectious Disease studies. The examples in the TAUG could be applied to any study requiring source and/or contact cases

37. Source Case Investigation • A pediatric study subject, Mary, has been enrolled and exposed to TB. • Mary, a child, has difficulty producing sputum… • makes bacteriologic confirmation of infection difficult. • it is necessary to identify the source case (adult) capable of producing the sputum sample. • After identification, investigators can collect and test a sputum sample to learn about the TB strain suspected Microbiology susceptibility tests (MS) can be run on the sample to determine drug resistance, if any

38. Contact Case Investigation Investigate an associated person (not in the study) who may have come into contact with the infected study subject. E.g. a mother with TB is enrolled, her child would be an associate person for whom a contact case is initiated  NSVs

39. Rule Development for CDISC Standards CDISC has published a draft version of SDTM IG 3.2 Conformance Rules 8 of the 416 rules (1.9%) are linked to AP IG

40. Conclusions • AP IG mainly adds a few new variables to support associated persons in relation to any other domain • It’s the same domains and concepts, with another prefix, that segregates data for non study subjects • Having SDTM-IG AP 1.0 is a positive step in the evolution of the standard. Not having it will only allow for interpretation and confusion in industry between sponsor, CRO and regulatory agencies.

41. Nice to have Industry Goals(other than to start using it) • Standardization on these concepts: • Use of study-based timing variables If an AP has relationships with multiple study subjects • APID naming conventions for data with a mix of both.. • single APs • group Aps • use of APRELSUB to … • only include APs with multiple relationships • oralways to use as a single summary listing for all Aps • TA mandates/requirements for AP domains such as .. • any studies involving solid organ transplants • Infectious disease studies such as TB and HIV for identifying source and contact case investigations • Hereditary diseases where family history is heavily involved.

42. Appendix and Extras

43. About the Presenter Mike is an Ursinus College 1999 Grad with a B.S. in Computer Science and Mathematics and a Founding Partner and Technical lead at Pinnacle 21 , LLC. He has 20 years experience in the IT field of which the last 17 have been supporting all stages of clinical development.   Mike currently works as a  Jumpstart and Data Fitness analyst at the FDA, while helping them adopt new and existing CDISC standards to the FDA catalog.    He also developed the clinical trials.gov miner tool and ADaM rules for Pinnacle 21 Community while participating on the CDISC ADaM Validation Subteam. In the past he was the Data Architect for the FDA Janus CTR  and served at Merck for 11 years as a developer and business analyst. mike.digian@pinnacle21.net mike@opencdisc.org http://www.pinnacle21.net/#about http://wiki.cdisc.org/display/~mike