{scrollbar:icons=false}
h1. {page-info:title}
{panel:title=Contents of this Page}
{toc:minLevel=2}
{panel}

h2. 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 \\ | # The Metadata Specialist selects and defines a set of CDEs for use within a data collection form
# The Metadata Specialist associates skip patterns with specific CDEs, which defines the action to be taken (CDEs to be skipped) depending on the answer.
# The Metadata Specialist deploys the form for data collection.
# The Clinical Researcher captures data using the form
# 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. \\ | * [Otherhm2 - Conditional CDEs|https://wiki.nci.nih.gov/x/iSxyAQ]
* [Init1pm9 - Automate|https://wiki.nci.nih.gov/x/vgRyAQ]
* [Conditional CDEs|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=44&t=140] |
|| *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. \\ |

h2. 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 \\ | # The Metadata Specialist selects and defines a set of CDEs for use within a data collection form
# The Metadata Specialist associates non-editable details for specific CDEs.
# The Metadata Specialist set the isEditable indicator to "NO".
# The Metadata Specialist deploys the form for data collection.
# The Clinical Researcher captures data using the form
# 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. \\ | * [Otherhm2 - Conditional CDEs|https://wiki.nci.nih.gov/x/iSxyAQ]
* [Init1pm9 - Automate|https://wiki.nci.nih.gov/x/vgRyAQ]
* [Conditional CDEs|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=44&t=140] |
|| *Fit criterion/Acceptance Criterion*  \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | None. \\ |

h2. 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 \\ | # The Metadata Specialist selects and defines a set of CDEs for use within a data collection form
# The Metadata Specialist associates default values for specific CDEs.
# The Metadata Specialist associates either isEditable to "Yes" or "No" as needed.
# The Metadata Specialist deploys the form for data collection.
# The Clinical Researcher captures data using the form
# When default value CDEs are reached within the form, the value is pre-entered for the Clinical Researcher
# 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. \\ | * [Otherhm2 - Conditional CDEs|https://wiki.nci.nih.gov/x/iSxyAQ]
* [Init1pm9 - Automate|https://wiki.nci.nih.gov/x/vgRyAQ]
* [Conditional CDEs|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=44&t=140] |
|| *Fit criterion/Acceptance Criterion*  \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | None. \\ |

h2. 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 \\ | # The Metadata Specialist selects and defines a set of CDEs for use within a data collection form
# The Metadata Specialist can see which CDEs are derived when building the form.
# The Metadata Specialist set isEdtiable to either "Yes" or "No" as needed.
# The Metadata Specialist deploys the form for data collection.
# The Clinical Researcher captures data using the form
# 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 \\ | \\
# If the isEditable is set to "Yes", the researcher can fill a value.
# 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. \\ | * [Otherhm2 - Conditional CDEs|https://wiki.nci.nih.gov/x/iSxyAQ]
* [Init1pm9 - Automate|https://wiki.nci.nih.gov/x/vgRyAQ]
* [Conditional CDEs|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=44&t=140] |
|| *Fit criterion/Acceptance Criterion*  \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | None. \\ |

h2. 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 \\ | # The Metadata Specialist selects and defines a set of CDEs for use within a data collection form
# The Metadata Specialist selects a subset of CDEs to be contained within a module
# The Metadata Specialist deploys the form for data collection.
# The Clinical Researcher captures data using the form
# When a module is reached, all questions must be answered in the pattern described by the module
# 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. \\ | * [Otherhm2 - Conditional CDEs|https://wiki.nci.nih.gov/x/iSxyAQ]
* [Init1pm9 - Automate|https://wiki.nci.nih.gov/x/vgRyAQ]
* [Conditional CDEs|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=44&t=140] |
| *Fit criterion/Acceptance Criterion*  \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | None. \\ |
\\
{scrollbar:icons=false}