5.2.1.3.3 - Extend Sept. 6, 2010

Allows the user to dynamically define the data sets they want

Gap Analysis::Extend::019 - Dynamic Data Set Definitions

dynamicDataSetDefinition,

Support more terminologies to be made available to the modelers, unapproved or in-review terminologies need to be advertised to help modelers suggest terms for inclusion in either NCIt or BiomedGT.

Gap Analysis::Extend::043 - Support More Terminologies

localizeTerminologies,

Add additional data elements to applications at run time. These could be discovered in a metadata repository or, if the appropriate data element does not yet exist, it may need to be created. These newly added data elements need to then be immediately discoverable and made available through the application programmatic interface.

Gap Analysis::Extend::056 - Add data elements at run time

runtimeDataElementAddition,

Support local and non public standards that can extend public regional or global standards, providing extensibility with individual element granularity

Gap Analysis::Extend::078 - Support Localized Standards

localizeElements,

Be capable of easily consuming information from the USHIK resource as static semantic content.

Gap Analysis::Extend::095 - USHIK Semantic Content

ushikMetadataRegistryAPI,

Provide for interoperation with external research communities depending upon semantically aware networks.

Gap Analysis::Extend::116 - External Research Community Interoperation

externalResearchCommunityInteroperation,

Provide a standard for units (expand UCUM)

Gap Analysis::Extend::145.2 - Extend UCUM

ucumUnitsOfMeasureAPI,

Support adding arbitrary binary data to data element definitions

Gap Analysis::Extend::161 - Support arbitrary binary data

binaryData,

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

dynamicDataSetDefinition, localizeTerminologies, runtimeDataElementAddition, localizeElements, ushikMetadataRegistryAPI, externalResearchCommunityInteroperation, ucumUnitsOfMeasureAPI, binaryData, dataModelExtensibility, internationalization,

There is a need to support extensions to the existing caDSR UML model and its exposure of these extensions as an API without the need for writing new caDSR code in the original application.  Local data models are dynamic; a change in previously curated data model (e.g., clinical trial schema) can take months and involve lots of people.  A faster way to update the caDSR CDEs and their value domains to better reflect the semantics of local information models is desired.  A good place to start supporting extensions is in the ability to change permissible value sets in the clinical domain.  The underlying motivations for these capabilities include: * Pathology, imaging, and clinical data elements are required to annotate biospecimens, patient/participant encounters, and patients/participants are unique to the complex disease being studied. * Even if the existing model is comprehensive enough, cutting edge research will continue to demand the comprehensive capture of new kinds of data (e.g. a novel, predicted biomarker for prostate cancer). * Users may also want to capture associated information that may be institution-specific and will not be shared (e.g. a freezer’s maintenance contract # and support end date). *Source:  * * caDSR documentation * Interview 5/24/2010, Dianne Reeves

Gap Analysis::caDSR::caDSR-7 - Support data model extensibility

dataModelExtensibility,

The Knowledge Repository should provide appropriate references and/or attributes to enable the use of all objects internationally.  This globalization requirement will be expanded upon in the CDSIC Requirements Package 2. *Source:  * * CDISC Requirements Package 1 - NCI Semantic Infrastructure, 5/28/2010, Section 2.7

Gap Analysis::CDISC::CDISC-17 - Support internationalization of biomedical research and healthcare data

internationalization,