5.2.1.2.1 - Analysis Sept. 6, 2010

Artifact lifecycle management and metadata requirements include the ability to: * Manage lifecycle, governance and versioning of the models, content and forms * Establish relationships and dependencies between models, content and forms * Determine provenance, jurisdiction, authority and intellectual property * Create represention and views of the information, realized through the appropriate transforms * Provide access control and other security constraints * Create annotations for better discovery and searching of artifacts * Develop usage scenarios and context for the information * Provide terminology and value set binding The artifacts are bound to the services via the service metadata. The service metadata combined with the artifacts and supporting metadata provide a comprehensive service specification. The artifact management requirements listed above are derived from the following use cases: * caEHR: The caEHR project has adopted ECCF for specifications and CDA documents for interoperability. The caEHR project requirements include the need for an infrastructure for managing all the artifacts generated during specification process, including HL7 models and documents. The caEHR project also intends to publish these artifacts for the community and vendors. The infrastructure needs to support better discovery, making all the relevant information available in the right context. * ONC and other external EHR adopters: ONC has adopted CCD and CCR for meaningful use. All national EHR implementations are expected to support forms and the semantics of these forms play a critical role in interoperability. The semantic infrastructure must provide a mechanism to create, store and manage these forms. * Clinical Trials: Clinical trials use forms to capture clinical information, and the semantics captured by these forms are critical for interoperability and reporting. The semantic infrastructure must provide a mechanism to manage the lifecycle of these forms.

Semantic Infrastructure Requirements::Artifact Management::Artifact Lifecycle Management

Users of caDSR will often ask "How does data element XYZ, or model ABC, harmonize with BRIDG?"  caDSR and CDISC have different senses of harmonization.  In caDSR there is an agreed-upon set of common data elements.  Harmonization involves mapping these CDEs and associations to BRIDG concepts.   If this mapping cannot be achieved then new CDEs would be created.  CDISC harmonization efforts are starting with N local concepts and from these trying to define a set of common data elements.  These common data elements would then be harmonized with the BRIDG standard.  There is some concern that BRIDG concepts are too high level and may not easily map to common data element definitions.  The CDISC SHARE project is attempting to map CDISC standards (e.g., SDTM & CDASH) to BRIDG concepts and then have these concepts reused by CDISC participants (e.g., CDOs, Pharmas), who create their own local concepts.  The expectation is that 20%-30% of the local concepts are "new science," and will not map to the current version of CDISC standards.  One of the caDSR deficiencies is that the same data element and its values can have different meanings depending on the context.   For example a Likert scale can represent quality of life or a pain assessment depending on the context.  These kinds of ambiguity should be resolved, perhaps through additional meta-data. Additional harmonization requirements are: * UML Descriptions:  Descriptions should be specific, consistent with the context of the model, and not circular. * UML-CDE Synonymy:  The concepts assigned to the CDE should fully capture the semantics of the (local) UML definition and reflect the same level of specificity (not more or less general). * CDE Concepts:  The set of concepts assigned to the CDE should have only a single interpretation. *Source:  * * Interview 5/24/2010, Dianne Reeves

Gap Analysis::caDSR::caDSR-6 - Harmonize CDEs with BRIDG

caDSR does not currently incorporate entire external standards.   However caDSR does extensively incorporate and harmonize bits and pieces of external standards.  The Knowledge Repository should have the ability to input, present, normalize and harmonize all or parts of external standards.  These external standards should include: * Map to HL73 RIM with precise semantic meanings defined * Map to BRIDG Terminology Information * Map to  Data Type standards (e.g., ISO 21090) * Map to CDISC Standards (mainly STDM and CDASH) * Map to 11179 Metadata Repository Standard and identify concepts * Map to existing caDSR CDEs defined and agreed upon by the governance process and local information models * Map to domain analysis models from a top down approach so that traceability is insured using the ECCF specification stack caDSR data elements are constructed now, using a middle-in approach at the class level. Context for V3 DAM models requires a top down approach so that traceability is maintained down to the PSM level.   In principle caDSR wants to be able to integrate other external standards (e.g., CDISC) as needed and map existing caDSR CDEs and associations to them.  This includes incorporating external standard model elements as new CDEs and associations.  Examples of this external standards integration include the fact that parts of the NCI Thesaurus reflect the standards used by CDISC.   There have been in bi-weekly terminology harmonization meetings with NCI, FDA and HL7 for over four years to agree on candidate terminologies. *Source:  * * 05/21/2010 and 05/24/2010 Interviews, Dianne Reeves

Gap Analysis::caDSR::caDSR-8 -  Support the harmonization of external data standards, data types, and terminology information

CDISC does not currently incorporate entire external standards.  However, CDISC does extensively incorporate and harmonize bits and pieces of external standards.  The Knowledge Repository should have the ability to input, present, normalize and harmonize all or parts of external standards. Integrate current CDISC standards and extend them with efficacy-related domains & content as well as other needed external standards in an electronic, accessible format.   Examples of this partial normalization include the fact that parts of the NCI Thesaurus were reviewed and subsections harmonized; CDISC has been in bi-weekly terminology harmonization meetings with NCI, FDA and HL7 for over four years.   Wherever possible, existing controlled terminology will be used. Content will be provided from the external source and not duplicated in the repository (e.g., WHOdrug, MedDRA, FDA terminology, ICH, etc.).  UCOM (Unified Code for Units of Measure) and UCOM expressions as well as other units of measure have been reused.1  There was also a lot of reuse of selected metadata from NCI's caDSR project.  In terms of incorporating entire complex external standards their has been some work on reusing the drug discover process standards from the , the ISO 21090 Harmonized Data Types for Information Exchange, and the BRIDG standards. *Source:  * * CDISC Share Pilot Report and CDISC Requirements Package 1 - NCI Semantic Infrastructure, 5/28/2010, Section 2.4 * CDISC SHARE:  Pathway into the Future for Standards Development and Delivery, April 10, 2010, Brow W. Kisler, CDISC Senior Director * 05/20/2010 Interview, Dianne Reeves &  David Iberson-Hurst

Gap Analysis::CDISC::CDISC-3 -  Support the integration and harmonization of authoritative external data standards

A major CDISC requirement is to reuse and develop tooling that allows them to create high-quality standards faster.  These can be via NCI tools or some other external tools. It would similarly be useful to be able to add extra functionality to any collaborative/MDA environments.  CDISC is reviewing NCI, HL7, and BRIDG for candidate tools.  The intent is to use this tooling to define active touch-points among standards and eventually data sets.  The tooling touch-points can do some of the work of standards in achieving computer semantic interoperability (CSI).  This flexibility of adding additional functionality is analogous to FireFox browser plug-ins.  This flexibility is needed to support a diverse standards community needs and changing metadata authoring, harmonization and curation. A prototyping tools strategy that masks the complexity of the harmonization and standards development process is desired.   In addition, the CDISC SHARE (Shared Health and Research Electronic Library) may be based on the NCI Knowledge Repository code-base.   The proposed prototype tools should be reviewed by the two CDISC Teams (Team One-SDTM & CDASH, Team-Two-Metadata Structure for CDISC SHARE). *Source:  * * 5/20/2010 Interview, David Iberson-Hurst & David Hau

Gap Analysis::CDISC::CDISC-4 -  Develop tooling to shorten the time it takes to collaboratively define CDISC standards