 |
Page History
...
| Children Display |
|---|
| Page info | ||||
|---|---|---|---|---|
|
...
Summary
Description of the profile
Determine provenance, jurisdiction, authority and intellectual property.
...
Links services to all the supporting artifacts in the specification
This Functional Profile includes, but is not limited to, the following capability elaborations:
- richMetadata
- entitySharing
- privateContent
- manageTerminologyArtifactLifecycle
- trackDataProvenance
- dataTraceability
- nciProvenanceModel
- provenanceAndLifecycleMetadata
- trackDataElementUsage
Derived From Requirements
...
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:: |
...
| |||||||
Track who else has used a set or a particular data element and how often it’s been used | Gap Analysis::Manage:: |
...
| |||||||
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:: |
...
| |||||||
Allow users to create and share private collections of entities and define how they are shared | Gap Analysis::Manage:: |
...
| |||||||
Need to have private and public content in the MDR; | Gap Analysis::Manage:: |
...
| |||||||
Manage lifecycle of terminology artifacts | Gap Analysis::Manage::
|
...
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::
| 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::
| |||||||
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::
| provenanceAndLifecycleMetadata, manageTerminologyArtifactLifecycle, dataTraceability, | ||||||
There is a need to have the registry support keeping track of data provenance | Gap Analysis:: |
...
HL7 CIC::
| |||||||
KR needs a governance workflow process built into the UI that conforms to the requirements of NCI provenance |
...
Gap Analysis::EVS::
| ||||||||
| Semantic Profile::OASIS SOA::
| 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::
| ||||||||
| Semantic Profile::OASIS SOA::
| discovery from inherited abstract profile Artifact, identity from inherited abstract profile Artifact, metadata from inherited abstract profile Artifact, store from inherited abstract profile Artifact, |
| Anchor | ||||
|---|---|---|---|---|
|
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
| Anchor | ||||
|---|---|---|---|---|
|
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
...
| Anchor | ||||
|---|---|---|---|---|
|
Description
Allow users to create and share private collections of entities and define how they are shared
Requirements addressed
...
Overview of possible operations
| Anchor | ||||
|---|---|---|---|---|
|
Description
Descriptions which include a unique identifier for the artifact.
Requirements addressed
Overview of possible operations
...
| Anchor | ||||
|---|---|---|---|---|
|
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
| Anchor | ||
|---|---|---|
|
...
|
...
|
...
|
...
|
...
|
...
|
...
There is a need to have the registry support keeping track of data provenance
...
Description
A representation of the meaning of terms used to describe the artifact, its functions, and its effects.
Requirements addressed
Overview of possible operations
...
| Anchor | ||||
|---|---|---|---|---|
|
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
| Anchor | ||||
|---|---|---|---|---|
|
Description
Need to have private and public content in the MDR;
Requirements addressed
Overview of possible operations
| Anchor | ||||
|---|---|---|---|---|
|
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
| Anchor | ||||
|---|---|---|---|---|
|
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
| Anchor | ||||
|---|---|---|---|---|
|
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
| Anchor | ||||
|---|---|---|---|---|
|
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
| Anchor | ||||
|---|---|---|---|---|
|
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
| Anchor | ||||
|---|---|---|---|---|
|
Description
There is a need to have the registry support keeping track of data provenance
Requirements addressed
Overview of possible operations
| Scrollbar |
|---|
