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 2 Next »

Services Functional 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.

Capability Elaborations

This Functional Profile includes, but is not limited to, the following capability elaborations:

Derived From Requirements

  • Gap Analysis::Service::060 - Service metadata validation 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::061 - Service compatibility level Service metadata should capture the compatibility level of the service, including the date of the review.
  • Gap Analysis::Service::062 - Service quality and stability assessment Service metadata should be extended to provide some assessment of service quality and stability
  • Gap Analysis::Service::065 - caDSR data element registration Use Introduce Toolkit generated service metadata and a service loader tool to register use/reuse of data elements in caDSR
  • Gap Analysis::Service::071 - EPR metadata Semantic infrastructure should support metadata around EPRs
  • Gap Analysis::Federation::115 - LexEVS SPARQL Endpoint Provide a SPARQL endpoint for querying. LexEVS
  • Gap Analysis::Service::122 - RDF triple store backend for LexEVS 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::Interface::129 - Programmatic Access to LexEVS API Programmatic Access to LexEVS API
  • Gap Analysis::Service::130.3 - Unique Identifier Resolution Provide Unique Identifier Resolution across Grid
  • Semantic Infrastructure Requirements::Artifact Management::Artifact Lifecycle Management 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.
  • Gap Analysis::EVS::EVS-1 - Concept and Value set Terminology binding 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-6 - Value Set Versioning 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

cadsrModel capability elaboration

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

eprModel capability elaboration

Semantic infrastructure should support metadata around EPRs

lexEvsAPI capability elaboration

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.

lexEvsRdfBackend capability elaboration

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.

lexEvsSparqlEndpoint capability elaboration

Provide a SPARQL endpoint for querying. LexEVS

serviceMetadataCompatabilityLevel capability elaboration

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

serviceMetadataValidation capability elaboration

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

serviceQualityAndStabilityAssessmentModel capability elaboration

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

uniqueIdentifierResolution capability elaboration

Provide Unique Identifier Resolution across Grid

  • No labels