Page History

Versions Compared

Old Version 3

changes.mady.by.user Unknown User (digret)

Saved on Sep 08, 2010

compared with

New Version 4

changes.mady.by.user Unknown User (digret)

Saved on Sep 09, 2010

Key

This line was added.
This line was removed.
Formatting was changed.

Wiki Markup
{scrollbar} {children} h3. {page-info:title} h4. Summary h5. Description of the profile The Semantic Infrastructure keeps track of each version, any relevant provenance information (e.g., who made the change), and supports the concept of being able to revert to any prior state. This version control would include the authoring of any new metadata (making contexts more explicit) and the assertions of model alignments. Version specializes capabilities architecturally implied by its associated concepts of Change . The implied architectural capabilities are described in the following paragraphs. Change Artifact descriptions change over time and their contents will reflect changing needs and context. Architectural implications of change on the Semantic Infrastructure are reflected in the following capabilities: * mechanisms to support the storage, referencing, and access to normative definitions of one or more versioning schemes that may be applied to identify different aggregations of descriptive information, where the different schemes may be versions of a versioning scheme itself; * configuration management mechanisms to capture the contents of the each aggregation and apply a unique identifier in a manner consistent with an identified versioning scheme; * one or more mechanisms to support the storage, referencing, and access to conversion relationships between versioning schemes, and the mechanisms to carry out such conversions. h5. Capabilities * [configurationManagement\|#_16_5_1_24a0131_1283700133655_905377_3117] * [dataElementHistory\|#EAID_ECE80B0D_86DB_495a_8514_0C0D7C14A2BD] * [lexWikiToolingVersioningManagement\|#_16_5_1_24a0131_1283180724193_489102_4845] * [transition\|#_16_5_1_24a0131_1283700246486_44421_3128] * [versioning\|#_16_5_1_24a0131_1283699095521_961509_3106] h4. Requirements traceability \|\|Requirement\|\|Source\|\|Capability\|\| \|View the history on a particular data element to view changes on prior versions that exist in caDSR. \|Gap Analysis::Manage::{anchor:_16_5_1_24a0131_1283085778659_442981_4338}026.1 - Data Element History\|{li}[dataElementHistory\|#EAID_ECE80B0D_86DB_495a_8514_0C0D7C14A2BD]{li}\| \|Provide a LexWiki tooling versioning management and upgrade mechanism. \|Gap Analysis::Manage::{anchor:_16_5_1_24a0131_1283085781793_583295_4356}136 - LexWiki tooling versioning management\|{li}[lexWikiToolingVersioningManagement\|#_16_5_1_24a0131_1283180724193_489102_4845]{li}\| \|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::{anchor:_16_5_1_24a0131_1283090023842_213150_4485}Artifact Lifecycle Management\|{li}[dataElementHistory\|#EAID_ECE80B0D_86DB_495a_8514_0C0D7C14A2BD]{li}\| \|In conjunction with CDISC-1 distributed Knowledge Repository a tool will be needed to create/add, delete, update/modify and retire content from multiple sources. There must be version control for CDISC objects (e.g., attributes, associations, classes, etc.). This includes versioning information about CDISC controlled terminology and any external authoritative source terminologies. The KR and Tools should provide a mechanism for preserving and viewing the contributing sources and/or contributing organizations for each object. Detailed tracking of contributions among objects is not required. Source: * CDISC Share Pilot Report * CDISC Requirements Package 1 - NCI Semantic Infrastructure, 5/28/2010, Section 2.5 & Section 2.8 \|Gap Analysis::CDISC::{anchor:_16_5_1_24a0131_1283075778818_720389_4053}CDISC-16 - Ensure versioning, change management and traceability\|{li}[dataElementHistory\|#EAID_ECE80B0D_86DB_495a_8514_0C0D7C14A2BD]{li}\| \|A service description is an artifact, usually document-based, that defines or references the information needed to use, deploy, manage and otherwise control a service. This includes not only the information and behavior models associated with a service to define the service interface but also includes information needed to decide whether the service is appropriate for the current needs of the service consumer. Thus, the service description will also include information such as service reachability, service functionality, and the policies and contracts associated with a service. A service description artifact may be a single document or it may be an interlinked set of documents. Architectural implications of service description on the Semantic Infrastructure are reflected in the following functional decomposition: * Description will change over time and its contents will reflect changing needs and context. This is elaborated in the inherited Change profile. * Description makes use of defined semantics, where the semantics may be used for categorization or providing other property and value information for description classes. This is elaborated in the inherited Semantic Model profile. * Descriptions include reference to policies defining conditions of use and optionally contracts representing agreement on policies and other conditions. This is elaborated in the inherited Policy profile. * Descriptions include references to metrics which describe the operational characteristics of the subjects being described. This is elaborated in the inherited Metrics profile. * Descriptions of the interactions are important for enabling auditability and repeatability, thereby establishing a context for results and support for understanding observed change in performance or results. This is elaborated in the inherited Interaction profile. * Descriptions may capture very focused information subsets or can be an aggregate of numerous component descriptions. Service description is an example of a likely aggregate for which manual maintenance of all aspects would not be feasible. This is elaborated in the inherited Composition profile. * Descriptions provide up-to-date information on what a resource is, the conditions for interacting with the resource, and the results of such interactions. As such, the description is the source of vital information in establishing willingness to interact with a resource, reachability to make interaction possible, and compliance with relevant conditions of use. This is elaborated in the inherited Interoperability profile. Policy capabilities are specialization of Artifact capabilities. \|Semantic Profile::OASIS SOA::{anchor:_16_5_1_24a0131_1283763560612_868976_4608}Service Description Model\|{li}[versioning\|#_16_5_1_24a0131_1283699095521_961509_3106] from inherited abstract profile Change{li}{li}[configurationManagement\|#_16_5_1_24a0131_1283700133655_905377_3117] from inherited abstract profile Change{li}{li}[transition\|#_16_5_1_24a0131_1283700246486_44421_3128] from inherited abstract profile Change{li}\| h4. {anchor:_16_5_1_24a0131_1283700133655_905377_3117}configurationManagement h5. Description Mechanisms to support the storage, referencing, and access to normative definitions of one or more versioning schemes that may be applied to identify different aggregations of descriptive information, where the different schemes may be versions of a versioning scheme itself. h5. Requirements addressed * [Service Description Model\|#_16_5_1_24a0131_1283763560612_868976_4608] h5. Overview of possible operations h4. {anchor:EAID_ECE80B0D_86DB_495a_8514_0C0D7C14A2BD}dataElementHistory h5. Description View the history on a particular data element to view changes on prior versions that exist in caDSR. h5. Requirements addressed * [Artifact Lifecycle Management\|#_16_5_1_24a0131_1283090023842_213150_4485] * [CDISC-16 - Ensure versioning, change management and traceability\|#_16_5_1_24a0131_1283075778818_720389_4053] * [026.1 - Data Element History\|#_16_5_1_24a0131_1283085778659_442981_4338] h5. Overview of possible operations h4. {anchor:_16_5_1_24a0131_1283180724193_489102_4845}lexWikiToolingVersioningManagement h5. Description Provide a LexWiki tooling versioning management and upgrade mechanism. h5. Requirements addressed * [136 - LexWiki tooling versioning management\|#_16_5_1_24a0131_1283085781793_583295_4356] h5. Overview of possible operations h4. {anchor:_16_5_1_24a0131_1283700246486_44421_3128}transition h5. Description One or more mechanisms to support the storage, referencing, and access to conversion relationships between versioning schemes, and the mechanisms to carry out such conversions. h5. Requirements addressed * [Service Description Model\|#_16_5_1_24a0131_1283763560612_868976_4608] h5. Overview of possible operations h4. {anchor:_16_5_1_24a0131_1283699095521_961509_3106}versioning h5. Description Configuration management mechanisms to capture the contents of the each aggregation and apply a unique identifier in a manner consistent with an identified versioning scheme. h5. Requirements addressed * [Service Description Model\|#_16_5_1_24a0131_1283763560612_868976_4608] h5. Overview of possible operations {scrollbar}

Wiki Markup


{scrollbar}
{children}

h3. {page-info:title}
	
h4. Summary

h5. Description of the profile

The Semantic Infrastructure keeps track of each version, any relevant provenance information (e.g., who made the change), and supports the concept of being able to revert to any prior state. This version control would include the authoring of any new metadata (making contexts more explicit) and the assertions of model alignments.

*Version* specializes capabilities architecturally implied by its associated concepts of  Change .  The implied architectural capabilities are described in the following paragraphs. 



*Change*  Artifact descriptions change over time and their contents will reflect changing needs and context. 

 Architectural implications of change on the Semantic Infrastructure are reflected in the following capabilities:  
* mechanisms to support the storage, referencing, and access to normative definitions of one or more versioning schemes that may be applied to identify different aggregations of descriptive information, where the different schemes may be versions of a versioning scheme itself; 
* configuration management mechanisms to capture the contents of the each aggregation and apply a unique identifier in a manner consistent with an identified versioning scheme; 
* one or more mechanisms to support the storage, referencing, and access to conversion relationships between versioning schemes, and the mechanisms to carry out such conversions.


h5.  Capabilities


* [configurationManagement|#_16_5_1_24a0131_1283700133655_905377_3117]
* [dataElementHistory|#EAID_ECE80B0D_86DB_495a_8514_0C0D7C14A2BD]
* [lexWikiToolingVersioningManagement|#_16_5_1_24a0131_1283180724193_489102_4845]
* [transition|#_16_5_1_24a0131_1283700246486_44421_3128]
* [versioning|#_16_5_1_24a0131_1283699095521_961509_3106]

h4. Requirements traceability
																					
																																
																																
																																			
																																			
																																			
																																			
															
||Requirement||Source||Capability||	
|View the history on a particular data element to view changes on prior versions that exist in caDSR. |Gap Analysis::Manage::{anchor:_16_5_1_24a0131_1283085778659_442981_4338}026.1 - Data Element History|{li}[dataElementHistory|#EAID_ECE80B0D_86DB_495a_8514_0C0D7C14A2BD]{li}|	
|Provide a LexWiki tooling versioning management and upgrade mechanism. |Gap Analysis::Manage::{anchor:_16_5_1_24a0131_1283085781793_583295_4356}136 - LexWiki tooling versioning management|{li}[lexWikiToolingVersioningManagement|#_16_5_1_24a0131_1283180724193_489102_4845]{li}|	
|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::{anchor:_16_5_1_24a0131_1283090023842_213150_4485}Artifact Lifecycle Management|{li}[dataElementHistory|#EAID_ECE80B0D_86DB_495a_8514_0C0D7C14A2BD]{li}|	
|In conjunction with CDISC-1 distributed Knowledge Repository a tool will be needed to create/add, delete, update/modify and retire content from multiple sources.  There must be version control for CDISC objects (e.g., attributes, associations, classes, etc.).  This includes versioning information about CDISC controlled terminology and any external authoritative source terminologies.  The KR and Tools should provide a mechanism for preserving and viewing the contributing sources and/or contributing organizations for each object.  Detailed tracking of contributions among objects is not required.    *Source:*   * CDISC Share Pilot Report   * CDISC Requirements Package 1 - NCI Semantic Infrastructure, 5/28/2010, Section 2.5 & Section 2.8 |Gap Analysis::CDISC::{anchor:_16_5_1_24a0131_1283075778818_720389_4053}CDISC-16 - Ensure versioning, change management and traceability|{li}[dataElementHistory|#EAID_ECE80B0D_86DB_495a_8514_0C0D7C14A2BD]{li}|	
|A service description is an artifact, usually document-based, that defines or references the information  needed to use, deploy, manage and otherwise control a service. This includes not only the information  and behavior models associated with a service to define the service interface but also includes  information needed to decide whether the service is appropriate for the current needs of the service consumer. Thus, the service description will also include information such as service reachability, service functionality, and the policies and contracts associated with a service.    A service description artifact may be a single document or it may be an interlinked set of documents.     Architectural implications of service description on the Semantic Infrastructure are reflected in the following functional decomposition:   * Description will change over time and its contents will reflect changing needs and context.  This is elaborated in the inherited Change profile.  * Description makes use of defined semantics, where the semantics may be used for  categorization or providing other property and value information for description classes. This is elaborated in the inherited Semantic Model profile.  * Descriptions include reference to policies defining conditions of use and optionally contracts  representing agreement on policies and other conditions.  This is elaborated in the inherited Policy profile.  * Descriptions include references to metrics which describe the operational characteristics of the  subjects being described.  This is elaborated in the inherited Metrics profile.  * Descriptions of the interactions are important for enabling auditability and repeatability, thereby  establishing a context for results and support for understanding observed change in performance  or results.  This is elaborated in the inherited Interaction profile.  * Descriptions may capture very focused information subsets or can be an aggregate of numerous  component descriptions. Service description is an example of a likely aggregate for which  manual maintenance of all aspects would not be feasible. This is elaborated in the inherited Composition profile.  * Descriptions provide up-to-date information on what a resource is, the conditions for interacting with the resource, and the results of such interactions. As such, the description is the source of vital information in establishing willingness to interact with a resource, reachability to make  interaction possible, and compliance with relevant conditions of use.  This is elaborated in the inherited Interoperability profile.      Policy capabilities are specialization of Artifact capabilities. |Semantic Profile::OASIS SOA::{anchor:_16_5_1_24a0131_1283763560612_868976_4608}Service Description Model|{li}[versioning|#_16_5_1_24a0131_1283699095521_961509_3106] *from inherited abstract profile* Change{li}{li}[configurationManagement|#_16_5_1_24a0131_1283700133655_905377_3117] *from inherited abstract profile* Change{li}{li}[transition|#_16_5_1_24a0131_1283700246486_44421_3128] *from inherited abstract profile* Change{li}|


h4. {anchor:_16_5_1_24a0131_1283700133655_905377_3117}configurationManagement
h5. Description

Mechanisms to support the storage, referencing, and access to normative definitions of one or more versioning schemes that may be applied to identify different aggregations of descriptive information, where the different schemes may be versions of a versioning scheme itself.
h5. Requirements addressed
																			
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]														

h5. Overview of possible operations



h4. {anchor:EAID_ECE80B0D_86DB_495a_8514_0C0D7C14A2BD}dataElementHistory
h5. Description

View the history on a particular data element to view changes on prior versions that exist in caDSR.
h5. Requirements addressed
																			
* [Artifact Lifecycle Management|#_16_5_1_24a0131_1283090023842_213150_4485]																															
* [CDISC-16 - Ensure versioning, change management and traceability|#_16_5_1_24a0131_1283075778818_720389_4053]																															
* [026.1 - Data Element History|#_16_5_1_24a0131_1283085778659_442981_4338]														

h5. Overview of possible operations



h4. {anchor:_16_5_1_24a0131_1283180724193_489102_4845}lexWikiToolingVersioningManagement
h5. Description

Provide a LexWiki tooling versioning management and upgrade mechanism.
h5. Requirements addressed
																			
* [136 - LexWiki tooling versioning management|#_16_5_1_24a0131_1283085781793_583295_4356]														

h5. Overview of possible operations



h4. {anchor:_16_5_1_24a0131_1283700246486_44421_3128}transition
h5. Description

One or more mechanisms to support the storage, referencing, and access to conversion relationships between versioning schemes, and the mechanisms to carry out such conversions.
h5. Requirements addressed
																			
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]														

h5. Overview of possible operations



h4. {anchor:_16_5_1_24a0131_1283699095521_961509_3106}versioning
h5. Description

Configuration management mechanisms to capture the contents of the each aggregation and apply a unique identifier in a manner consistent with an identified versioning scheme.
h5. Requirements addressed
																			
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]														

h5. Overview of possible operations



{scrollbar}

Content

Space Tools

Versions Compared

Old Version 3

New Version 4

Key