NIH | National Cancer Institute | NCI Wiki  

Contents of this Page

Define Conditional CDEs

Use Case Number

Otherhm2.pm13.1

Brief Description

In data collections forms, it is often important to enforce specific rules that determine which data elements are captured.  These rules are termed as "conditional" CDEs or "skip patterns".  For example, if male is selected for the gender CDE question, then the question about whether the patient is pregnant would be skipped.  More complex conditionals can be defined that require mathematical evaluation (less than, greater than), etc.

Actor(s) for this particular use case

Metadata Specialist, Clinical Researcher

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

Data is collected with conditional steps.

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 selects and defines a set of CDEs for use within a data collection form
  2. The Metadata Specialist associates skip patterns with specific CDEs, which defines the action to be taken (CDEs to be skipped) depending on the answer.
  3. The Metadata Specialist deploys the form for data collection.
  4. The Clinical Researcher captures data using the form
  5. When conditional CDEs are reached within the form, the skip patterns are conditionally executed.

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 skip pattern must be associated with the CDE and optionally reusable.

Define non-editable CDEs

Use Case Number

Otherhm2.pm13.2

Brief Description

In data collections forms, it is often important to enforce that some values are not editable. These data elements could have a default value, be derived from other data elements (such as age from date of birth), or be derived from other systems.

Actor(s) for this particular use case

Metadata Specialist, Clinical Researcher

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

Data is collected with non-editable CDEs not captured from user input directly

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 selects and defines a set of CDEs for use within a data collection form
  2. The Metadata Specialist associates non-editable details for specific CDEs.
  3. The Metadata Specialist set the isEditable indicator to "NO".
  4. The Metadata Specialist deploys the form for data collection.
  5. The Clinical Researcher captures data using the form
  6. When non-editable CDEs are reached within the form, the Clinical Researcher is unable to enter data for that field.

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

None.  No conditions of the CDE will establish this indicator.  All items will be null unless explicitly set to "Yes" or "No".  

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?

None.

Define default values for CDEs

Use Case Number

Otherhm2.pm13.3

Brief Description

In data collections forms, sometimes it is important to define a default value for a CDE.  This improves accuracy and can make some forms quicker to fill out.  When combined with non-editable CDEs, this provides a forms author a way to enter a constant into a form.

Actor(s) for this particular use case

Metadata Specialist, Clinical Researcher

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

Data is collected with default values in CDEs

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 selects and defines a set of CDEs for use within a data collection form
  2. The Metadata Specialist associates default values for specific CDEs.
  3. The Metadata Specialist associates either isEditable to "Yes" or "No" as needed.
  4. The Metadata Specialist deploys the form for data collection.
  5. The Clinical Researcher captures data using the form
  6. When default value CDEs are reached within the form, the value is pre-entered for the Clinical Researcher
  7. The Clinical Researcher can change the value if he desires if the isEditable is set to "Yes", but cannot change the value if the isEditable is set to "No".

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

When the value for a CDE is defined as a set of possible values, the default value must be selected from the value set and is automatically selected for the Clinical Researcher when editing the form.

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?

None.

Define a CDE as derived

Use Case Number

Otherhm2.pm13.4

Brief Description

In data collections forms, it is possible that the value of a CDE is derived from the values of other CDEs.  For example, an Address CDE may be derived from a set of CDEs for Street, ZipCode, City, and State.  A derived CDE is often combined with the non-editable flag so that, when presented in a form, the user does not directly edit the value because it is composed from other values.

Actor(s) for this particular use case

Metadata Specialist, Clinical Researcher

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

Data is collected for a derived CDEs

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 selects and defines a set of CDEs for use within a data collection form
  2. The Metadata Specialist can see which CDEs are derived when building the form.
  3. The Metadata Specialist set isEdtiable to either "Yes" or "No" as needed.
  4. The Metadata Specialist deploys the form for data collection.
  5. The Clinical Researcher captures data using the form
  6. Once the CDEs that are being used to derive a value are filled in, the derived CDE value can be evaluated.

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

 

  1. If the isEditable is set to "Yes", the researcher can fill a value.
  2. If the isEditable is set to "No", the researcher cannot fill in a value.

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?

None.

Define a module of CDEs

Use Case Number

Otherhm2.pm13.5

Brief Description

In data collections forms, sometimes it is important to define a set of CDEs that must be asked completely in a certain order.  The question and answer pattern within the module itself has semantic meaning, and, if broken, is invalidated.  A module it sometimes combined with the non-editable flag to indicate that it cannot be altered.

Actor(s) for this particular use case

Metadata Specialist, Clinical Researcher

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

Data is collected for the modules of a form

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 selects and defines a set of CDEs for use within a data collection form
  2. The Metadata Specialist selects a subset of CDEs to be contained within a module
  3. The Metadata Specialist deploys the form for data collection.
  4. The Clinical Researcher captures data using the form
  5. When a module is reached, all questions must be answered in the pattern described by the module
  6. If the module is not completed as specified, no values are captured for it

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?

None.

  • No labels