NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Summary

Description of the profile

Users expressed requirements that suggest caBIG services are not sufficiently described to determine if they meets a user’s requirements or are interoperable with other services. These requirements are deemed applicable to future KR services.

Capabilities

Requirements traceability

Requirement

Source

Capability

Make it mandatory that user-friendly service metadata (e.g., service name) is always exposed. Even better, provide automated validation of the service metadata.

Gap Analysis::Service::060 - Service metadata validation

serviceMetadataValidation,

Service metadata should capture the compatibility level of the service, including the date of the review.

Gap Analysis::Service::061 - Service compatibility level

serviceMetadataCompatabilityLevel,

Service metadata should be extended to provide some assessment of service quality and stability

Gap Analysis::Service::062 - Service quality and stability assessment

serviceQualityAndStabilityAssessmentModel,

Use Introduce Toolkit generated service metadata and a service loader tool to register use/reuse of data elements in caDSR

Gap Analysis::Service::065 - caDSR data element registration

cadsrModel,

Semantic infrastructure should support metadata around EPRs

Gap Analysis::Service::071 - EPR metadata

eprModel,

Provide a SPARQL endpoint for querying. LexEVS

Gap Analysis::Federation::115 - LexEVS SPARQL Endpoint

lexEvsSparqlEndpoint,

Provide an RDF triple store backend for LexEVS, so that LexEVS can leverage tools and technologies (i.e, querying, browsing) developed by the Semantic Web community.

Gap Analysis::Service::122 - RDF triple store backend for LexEVS

lexEvsRdfBackend,

Programmatic Access to LexEVS API

Gap Analysis::Interface::129 - Programmatic Access to LexEVS API

lexEvsAPI,

Provide Unique Identifier Resolution across Grid

Gap Analysis::Service::130.3 - Unique Identifier Resolution

uniqueIdentifierResolution,

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

lexEvsAPI,

KR needs terminology from the enterprise vocabulary services at both the concept and value set level to bind to metadata objects in the knowledge repository.

Gap Analysis::EVS::EVS-1 - Concept and Value set Terminology binding

lexEvsAPI,

KR needs the ability to check in and version the newly annotated metadata objects and link back to the terminology value sets stored in EVS. This requires tracking versioning of the value set as well as versioning of the value set binding to the metadata object

Gap Analysis::EVS::EVS-6 - Value Set Versioning

lexEvsAPI,

cadsrModel

Description

Use Introduce Toolkit generated service metadata and a service loader tool to register use/reuse of data elements in caDSR

Requirements addressed
Overview of possible operations

eprModel

Description

Semantic infrastructure should support metadata around EPRs

Requirements addressed
Overview of possible operations

lexEvsAPI

Description

Programmatic Access to LexEVS API

KR needs terminology from the enterprise vocabulary services at both the concept and value set level to bind to metadata objects in the knowledge repository.

Requirements addressed
Overview of possible operations

lexEvsRdfBackend

Description

Provide an RDF triple store backend for LexEVS, so that LexEVS can leverage tools and technologies (i.e, querying, browsing) developed by the Semantic Web community.

Requirements addressed
Overview of possible operations

lexEvsSparqlEndpoint

Description

Provide a SPARQL endpoint for querying. LexEVS

Requirements addressed
Overview of possible operations

serviceMetadataCompatabilityLevel

Description

Service metadata should capture the compatibility level of the service, including the date of the review.

Requirements addressed
Overview of possible operations

serviceMetadataValidation

Description

Make it mandatory that user-friendly service metadata (e.g., service name) is always exposed. Even better, provide automated validation of the service metadata.

Requirements addressed
Overview of possible operations

serviceQualityAndStabilityAssessmentModel

Description

Service metadata should be extended to provide some assessment of service quality and stability

Requirements addressed
Overview of possible operations

uniqueIdentifierResolution

Description

Provide Unique Identifier Resolution across Grid

Requirements addressed
Overview of possible operations
  • No labels