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

Contents of this Page

Unified Harmonization Process

Use Case Number

Init1bes9.pm11.1

Brief Description

Common data elements can be entered into the metadata repository through a variety of different tools, including a UML loader, manual curation through the web interface, and forms development.  There must be a common harmonization mechanism enforced by the metadata repository such that all mechanisms by which CDEs are entered can be reused by all types of users.

Actor(s) for this particular use case

Metadata Specialist

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

None.

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

CDEs are harmonized in the system

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. A Metadata Specialist enters a common data element
    1. via automated UML loading
    2. via manual curation
    3. via form creation
  2. The Metadata Specialist is able (forced?) to harmonize the CDE(s) regardless of the mechanism by which it was registered

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 Metadata Specialist should be notified or forced in some manner to harmonize the CDEs.

Unified CDE Reuse

Use Case Number

Init1bes9.pm11.2

Brief Description

Regardless of the mechanism by which a CDE was registered (automated UML, forms creation, or manual curation), CDEs should be available for reuse by any type of tooling.

Actor(s) for this particular use case

Metadata Specialist

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

CDEs have been registered and harmonized via a variety of mechanisms.

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

CDEs are reused.

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. A Metadata Specialist discovers CDEs for reuse
    1. in forms
    2. in a UML model
    3. in an application
  2. The CDEs are available and fully functional within the desired modality

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? 

Regardless of the mechanism by which a CDE has been registered, it must be reusable by any application.

Association of Form Details to CDEs

Use Case Number
The author-assigned number to refer to each specific use case. The format of this number is <SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc.

Init1bes9.pm11.3

Brief Description

When CDEs are registered for reuse specifically in forms, there should be a way to associate form structure, form behavior, etc.

Actor(s) for this particular use case

Forms Author

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

None.

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

CDEs are registered with forms details associated.

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 Forms Author registers CDEs
  2. The Forms Author defines forms details, such as structure, behavior, etc.
  3. The Forms Author registers the forms details in the metadata repository
  4. The CDEs are available for reuse within forms

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

Medium.

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?

None.

Common Form Development Tool

Use Case Number

Init1bes9.pm11.4

Brief Description

A common form development tool would allow users a unified way to select metadata from the repository, add forms information, build a persistence backend, and a simple front-end.

Actor(s) for this particular use case

Forms Author

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

CDEs exist in the metadata repository

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

A data collection tool is created

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 Forms Author selects CDEs for data collection
  2. The Forms Author adds additional forms details, such as form structure, behavior, etc.
  3. The Forms Author constructs a persistence model
  4. The Forms Author constructs a web front-end for data collection
  5. The Forms Author exports a deployable system

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

Low

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 tooling should be common and reusable.

Fetching Forms Data

Use Case Number

Init1bes9.pm11.5

Brief Description

Some tools rely heavily on fetching forms and form data programmatically.  In order to make this process efficient, it is desirable to fetch entire object graphs that includes the entire form, data element information, and, where applicable, the data itself.

Actor(s) for this particular use case

Metadata Specialist

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

A form exist in the metadata repository

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

The form and (if applicable) data is entirely fetched

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 Metadata Specialist identifies the form that he wishes to fetch
  2. The Metadata Specialist fetches the form (and associated data) in its entirety

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

Low

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.

  • Email Requirements: In the course of retrieving the metadata for a CRF from the caDSR, the AGNIS Metadata Tool sends a large number of web service requests to the cadsrapi40Service web service.  This can take a long time, due to the large number of round trips to the server.  One possible way to improve performance would be to implement a caDSR API that, instead of returning only one object at a time, could return a graph of objects in response to a single web service request.  This would move processing to the server side, where it can be done more efficiently, and also improve performance by reducing the number of round trips to the server.
  • Init1bes9 - CDEs from Man. curation, UML models and CRFs
  • CDEs from Man. curation, UML models and CRFs

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

None.

Form Data Mining

Use Case Number

Otherhm1.pm12.1

Brief Description

A common set of tooling should work out-of-the-box for performing mining and analytics on CDE-based forms data.

Actor(s) for this particular use case

Metadata Specialist

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

Data has been collected through a common forms collection mechanism.

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

Data mining analytical results are available

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 Metadata Specialist identifies the forms persistence services to mine
  2. The Metadata Specialist formulates the data mining queries using a common graphical interface
  3. The Metadata Specialist issues the queries to the forms persistence services

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

Low

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 tooling should be common and reusable.


  • No labels