Summary
Description of the profile
Determine provenance, jurisdiction, authority and intellectual property.
Provide access control and other security constraints.
This category is an aggregation of all the service profiles within the Administer / Manage group, and the Annotate profile.
Manage lifecycle, governance and versioning of the models, content and forms.
The KR should keep 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.
Provenance encompasses the origin and traceability of data throughout an ecosystem. This is a clear requirement directly from the use case in order to ensure that all steps of patient care and research are clearly linked via the patient record.
The semantic infrastructure will provide data provenance support.
Links services to all the supporting artifacts in the specification
An artifact is a managed resource within the Semantic Infrastructure.
An artifact is associated with the following capabilities:
- descriptions to enable the artifact to be visible, where the description includes a unique identifier for the artifact and a sufficient, and preferably a machine processible, representation of the meaning of terms used to describe the artifact, its functions, and its effects;
- one or more discovery mechanisms that enable searching for artifacts that best meet the search criteria specified by the service participant; where the discovery mechanism will have access to the individual artifact descriptions, possibly through some repository mechanism;
- accessible storage of artifacts and artifact descriptions, so service participants can access, examine, and use the artifacts as defined.
Capabilities
- dataTraceability
- discovery
- entitySharing
- identity
- manageTerminologyArtifactLifecycle
- metadata
- nciProvenanceModel
- privateContent
- provenance
- provenanceAndLifecycleMetadata
- richMetadata
- store
- trackDataElementUsage
- trackDataProvenance
Requirements traceability
Requirement |
Source |
Capability |
|---|---|---|
Create caBIG identifiers to facilitate the traceability of clinical data to biospecimen to molecular data |
Gap Analysis::Manage::014 - Data traceability |
|
Track who else has used a set or a particular data element and how often it’s been used |
Gap Analysis::Manage::018.2 - Track Data Element Usage |
|
Add rich metadata (provenance, lifecycle, use, etc.) to all types of entities, including services, end-points, complex data types, workflows, events to support semantic interoperability |
Gap Analysis::Manage::059 - Rich Metadata |
|
Allow users to create and share private collections of entities and define how they are shared |
Gap Analysis::Manage::086 - Create and share private entities |
|
Need to have private and public content in the MDR; |
Gap Analysis::Manage::098.2 - Private Content |
|
Manage lifecycle of terminology artifacts |
Gap Analysis::Manage::128 - Manage lifecycle of terminology artifacts |
|
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 |
dataTraceability, trackDataElementUsage, richMetadata, entitySharing, privateContent, manageTerminologyArtifactLifecycle, provenanceAndLifecycleMetadata, |
In order to allow data sets to be shared, compared and repurposed across clinical trials, research databases, and organizations the caDSR needs to be able to attach and publish provenance and lifecycle metadata about those data sets. This requirement indicates many things, among them: * a need to minimize barriers to accessing metadata * a need to describe the workflow, provenance, and governance information associated with metadata |
Gap Analysis::caDSR::caDSR-2 - Capture and publish provenance and lifecycle metadata |
|
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::CDISC-16 - Ensure versioning, change management and traceability |
provenanceAndLifecycleMetadata, manageTerminologyArtifactLifecycle, dataTraceability, |
There is a need to have the registry support keeping track of data provenance |
Gap Analysis::HL7 CIC::CIC-13 - Track data provenance and recover from errors |
|
KR needs a governance workflow process built into the UI that conforms to the requirements of NCI provenance |
Gap Analysis::EVS::EVS-4 - Governance WorkFlow Conforming to NCI Provenance |
|
|
Semantic Profile::OASIS SOA::Governance Model |
discovery from inherited abstract profile Artifact, identity from inherited abstract profile Artifact, metadata from inherited abstract profile Artifact, store from inherited abstract profile Artifact, |
Provenance encompasses the origin and traceability of data throughout an ecosystem. This is a clear requirement directly from the use case in order to ensure that all steps of patient care and research are clearly linked via the patient record. The semantic infrastructure will provide data provenance support. Link to use case satisfied from caGRID 2.0 Roadmap: The origin of data is tied to the data creator, allowing the oncologist performing the match against TCGA data and other datasets to include and exclude data sets based on their origin. |
Semantic Infrastructure Requirements::caGRID 2.0 Platform and Terminology Integration::Provenance |
|
|
Semantic Profile::OASIS SOA::Service Description Model |
discovery from inherited abstract profile Artifact, identity from inherited abstract profile Artifact, metadata from inherited abstract profile Artifact, store from inherited abstract profile Artifact, |
dataTraceability
Description
Create caBIG identifiers to facilitate the traceability of clinical data to biospecimen to molecular data.
Requirements addressed
- Artifact Lifecycle Management
- CDISC-16 - Ensure versioning, change management and traceability
- 014 - Data traceability
Overview of possible operations
discovery
Description
One or more discovery mechanisms that enable searching for artifacts that best meet the search criteria specified by the service participant; where the discovery mechanism will have access to the individual artifact descriptions, possibly through some repository mechanism.
Requirements addressed
Overview of possible operations
entitySharing
Description
Allow users to create and share private collections of entities and define how they are shared
Requirements addressed
Overview of possible operations
identity
Description
Descriptions which include a unique identifier for the artifact.
Requirements addressed
Overview of possible operations
manageTerminologyArtifactLifecycle
Description
Manage lifecycle of terminology artifacts
Requirements addressed
- Artifact Lifecycle Management
- 128 - Manage lifecycle of terminology artifacts
- CDISC-16 - Ensure versioning, change management and traceability
Overview of possible operations
metadata
Description
A representation of the meaning of terms used to describe the artifact, its functions, and its effects.
Requirements addressed
Overview of possible operations
nciProvenanceModel
Description
KR needs a governance workflow process built into the UI that conforms to the requirements of NCI provenance
Requirements addressed
Overview of possible operations
privateContent
Description
Need to have private and public content in the MDR;
Requirements addressed
Overview of possible operations
provenance
Description
While the Resource identity provides the means to know which subject and subject description are being considered, Provenance as related to the Description class provides information that reflects on the quality or usability of the subject. Provenance specifically identifies the entity (human, defined role, organization, ...) that assumes responsibility for the resource being described and tracks historic information that establishes a context for understanding what the resource provides and how it has changed over time. Responsibilities may be directly assumed by the Stakeholder who owns a Resource or the Owner may designate Responsible Parties for the various aspects of maintaining the resource and provisioning it for use by others. There may be more than one entity identified under Responsible Parties; for example, one entity may be responsible for code maintenance while another is responsible for provisioning of the executable code. The historical aspects may also have multiple entries, such as when and how data was collected and when and how it was subsequently processed, and as with other elements of description, may provide links to other assets maintained by the Resource owner.
Requirements addressed
Overview of possible operations
provenanceAndLifecycleMetadata
Description
Capture and publish provenance and lifecycle metadata
Requirements addressed
- CDISC-16 - Ensure versioning, change management and traceability
- caDSR-2 - Capture and publish provenance and lifecycle metadata
- Artifact Lifecycle Management
Overview of possible operations
richMetadata
Description
Add rich metadata (provenance, lifecycle, use, etc.) to all types of entities, including services, end-points, complex data types, workflows, events to support semantic interoperability
Requirements addressed
Overview of possible operations
store
Description
Accessible storage of artifacts and artifact descriptions, so service participants can access, examine, and use the artifacts as defined.
Requirements addressed
Overview of possible operations
trackDataElementUsage
Description
Track who else has used a set or a particular data element and how often it’s been used
Requirements addressed
Overview of possible operations
trackDataProvenance
Description
There is a need to have the registry support keeping track of data provenance
