1. Metadata Curator's Assessments on CDISC CT Mappings

2. Test and Test Code is a one-to-one relationship No units are mapped
FRMSIZE
CL: C66741
C: C49680
Body Frame Size
CL: C67153
C: C49680
Test and Test Code is a one-to-one relationship
No units are mapped

3. Test and Test Code is a one-to-one relationship
Collection
BODYFAT
CL: C66741
C: C12472
Adipose Tissue
CL: C67153
C: C12472
Test and Test Code is a one-to-one relationship
Units to Test & Test Code pair is a one-to-one relationship
A code may exist in more than 1 codelists, e.g., C25613 (%) exists in 3 different codelists %
CL: C67153
C: C25613

4. Test and Test Code is a one-to-one relationship
Collection
TEMP
CL: C66741
C: C25206
Temperature
CL: C67153
C: C25206
Test and Test Code is a one-to-one relationship
Units to Test Code is a many-to-one relationship, i.e., a collection of units
A code may exist in more than 1 codelists, e.g., C25206 (TEMP) exists in 4 different codelists
Collection F
CL: C66770
C: C44277 C
C: C42559

5. Test and Test Code is a one-to-one relationship
Collection
PACEMAKR
CL: C71153
C: C111285
Pacemaker
CL: C71152
C: C111285
Test and Test Code is a one-to-one relationship
Results to Test Code is a many-to-one relationship, i.e., a collection of ECG results
Collection
PACED RHYTHM
CL: C92233
C: C88140
PACED ATRIAL RHYTHM
C: C92233
...

6. Questions (1)
Is there a rule for which column is the “nucleus” of a given CT mapping? The drawings above assumes the mappings evolve around C66741 for Vital Signs, and C71153 for ECG [Context: asset organization]
Notes: Units technically apply to both TESTCD and TEST; therefore, the nucleus is a combination of both
CDASH, SEND, SDTM all have EG and VS domains. Will mappings be unique to a particular standard? How about unique to one version of a standard? [Context: asset organization]
Notes: CDASH is a direct absolute subset of SDTM. CDASH may not use all the test/test codes. There may be a chance CDASH further subset an SDTM CT. PoC will focus on SDTM for now.
Will new mappings be always additive, i.e., will there be deprecations? Corrections? [Context: asset versioning]
Notes: Code depreciation is possible, therefore CT Mappings will need to reflect that change. Add/modify/delete are all possibilities.
Will mappings contain which codelist the codes belong? [Context: asset relationship]
It is a nice to have so we don’t need to “guess”; agreed to be explicit to facilitate imports

7. Questions (2)
Is it conceivable ECG will have units mappings like Vital Signs? If so, will mappings have names to differentiate multiple mappings? [Context: asset naming convention; asset organization]
Can a domain have more than 1 CT mapping?’
Notes: Not for PoC now; will wait and see if this scenario surfaces in the future
Will there be one gigantic CT mapping for domain LB? In other words, will there be one for urinalysis, another for hematology, etc? Similarly, a set of ECG mappings for QT studies, another for holter monitoring, etc?
Notes: The lab CT team will tackle one lab test at a time to sort out what units apply; therefore, still 1 CT mapping; the SHARE dev team is okay with a rolling spreadsheet with mappings

8. Questions (3) From listening to the CT meeting on Friday, 2014-07-18:
Methods for VS tests: Are the methods “extensible”? [Context: Mapping attributes]
Notes: Doesn’t really apply. It all depends on the codelist themselves
SME may benefit from being able to review the list on the METHOD codelist so that they can pick (check) codes that apply per test
SHARE has this functionality; can demo
Notes: Defer tool usability

9. Action Items
* A.Chow to i/f w/ JS and schedule the next meeting + agenda
* B.Dempsey to add c-codes to CT Mapping examples + VS to have Position