2014-08-08 Terminology_SHARE Call #4 Meeting Notes

• • 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

• 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

• 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

Proof of Concept: As Data Element Concepts

• Asset URL on SHARE-Training: http://bit.ly/1u38vuH

• Work assumptions

• Approached from the ISO 11179 angle

• Treating test and test code pairs in vertical domains (e.g., VS, EG) as clinical concepts

• Then, qualifiers such as position, units, method are properties

• Then, properties have value representations

• Then, map CDISC Controlled Terminology into properties

• Benefits

• Able to reuse CT assets already loaded into SHARE

• Able to express codelist and codes explicitly

• Able to map to CDASH and SDTM variables

• Unrestricted by # of properties and codes

Considerations

• Can properties in object class be further reduced to some reusable components? For example, Measurement Name, Short Name, Result Units, etc. are now repeated for each DEC. It seems we can combine “Properties” and “Represented By” to the same level. Furthermore, the strategy can be expanded to develop a template.

• For labs, codelist codes will have functional dependencies. For example, urine specimens (LBSPEC) often don’t have non-quantitative results (LBSTRESU). Further, specimen conditions (LBSPCCND) are not applicable.

• Versioning -- we have root VD at the codelist level. Supposed we need to maintain functional dependencies, will we need root DV? Concepts, if done correctly, are likely immutable