NIH | National Cancer Institute | NCI Wiki  

Versions Compared

Key

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

...

Use Case Number

Init1dbw6.U8

Brief Description

caB2B relies on establishing/identifiying relationships between concepts (entities) and/or properties (attributes) exposed through a service's implementation models (currently registered in caDSR/advertised on caGrid). For instance, we need to be
able to identify (or compute) Gene (entity from Model A) and MyFavoriteGene
(entity from Model B) are representing identical concepts, even when the entities are not named the same. Furthermore that Gene.entrezGeneId property (attribute from model A) and MyGene.geneEntereId (attribute from model B) are representing the same property/attribute for the given concept.

Currently NCIt concept mappings stored in the caDSR for the Object Classes and CDEs are leveraged to identify such relationships.  CDE mappings are the simpilest to map across models because the CDE means that the physical database representation (syntax) is the same in the two models and can be directly aggregated.

The new SI should continue to provide services and processes for us to be able to identify such relationships. In accordance with ECCF, the services/processes should at the minimum leverage the traceability (computable) among different levels of models (CIM->PSM) and compliance
among model representations (PSM<>PSM). If the service's semantic profile asserts that the service is conformant to all or part of a particular CIM>PIM->PSM,   caB2B should be able to easily discover this equivalence.

Actor(s) for this particular use case

Cancer Researcher

Pre-condition
The state of the system before the user interacts with it

A particular concept of interest has been identified via the terminology browser or metadata browser.
Class/entities in models have been associated with common concepts. 

Post condition
The state of the system after the user interacts with it

The results from the cross-model discovery operation are aggregated and presented to the user.

Steps to take
The step-by-step description of how users will interact with the system to achieve a specific business goal or function

  1. The Cancer Researcher selects the concept of interest and the operation (such as  "discover related models")
  2. The SI services are invoked and results are returned
  3. The results are aggregated based upon the matching entities and levels of entities in the models. For example, models or portions of models that are conformant at the CIM level are evident, at the PIM level, and at the PSM level and are self-evident in the results.
  4. The aggregated results are returned to the user

Alternate Flow
Things which would prevent the normal flow of the use case

None.

Priority
The priority of implementing the use case: High, Medium or Low

High.

Associated Links
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case.

Fit criterion/Acceptance Criterion 
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement?

Only Models where matching classes, attributes and associations are returned by the operation.

Query for Data based on permitted valid values

Use Case Number

Init1dbw6.U9

Brief Description

caB2B uses value sets (that bind to concepts) to filter/constrain
certain data elements in formation of queries to datasets. This requires runtime
access (or metadata download prior to runtime) to possible values for
specific data elements. Currently value domains that are associated with data elements stored in metadata repository (MDR/caDSR) are fetched and provided in query builders. The
enumerated values are provided in pull down menus/lists to ensure the queries are formulated with correct allowable values.

The new SI should continue to provide services and processes for us to
be able to identify and compute the value set for querying data elements

Actor(s) for this particular use case

Cancer Researcher

Pre-condition
The state of the system before the user interacts with it

The enumerations (value sets) for attributes/data elements/variables in a particular database are available to help form queries of the database.

Post condition
The state of the system after the user interacts with it

Data matching the selected enumerations (values) is retrieved via an SI operation.

Steps to take
The step-by-step description of how users will interact with the system to achieve a specific business goal or function

  1. The Cancer Researcher selects the entity/class of interest and an operation to retrieve the possible attributes/properties. (such as selecting "MyGene" and asking getAttributes)
  2. The SI service returns the results (such as all the property/attributes associated with MyGene in the models/data service). 
  3. The Cancer Researcher discovers that there is an attribute in the data source that is called Gene.Identifier and that the possible values are "P52" "P40" and "Gene TM", and issues a query (such as  "query myGene.Id where id = P52 or P40")
  4. The SI services are invoked and results are returned
  5. The results are returned to the user

Alternate Flow
Things which would prevent the normal flow of the use case

None.

Priority
The priority of implementing the use case: High, Medium or Low

High.

Associated Links
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case.

Fit criterion/Acceptance Criterion 
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement?

The researcher is able to discover what the possible values are for a data field and select one or more values of interest, results are returned that match only the selected values.