1 Functional Requirements
A 2-week comment period Candidate Scope ends 12/21/07. The following section describes in detail all the functional requirements, which are proposed for the coming release, Target Final Scope 01/11/2008.
Each new enhancement, modification or new feature is described in detail below.
Forms Users: Users with an NIH account may login and refine the description or post a comment at the bottom of the page.
Developers: Please update "Estimated LOE:" with H/M/L
1.1 # 9847 Allow for complex validations (non contiguous ranges like 1900-2007 and 9999, zip, address...)
This feature would allow a user to specify applying a field level validation for a question based on Value Domain metadata attributes such as min/max field length, range checking, min/max Value. If these attributes were not specified in the Value Domain, with proper privileges, the attributes could be persisted for the CDE while curating them for the Form.
Estimated LOE:
1.2 # 1098 Allow user to create a skip pattern based on more than one answer
There are situations in which the skip target (the "To") would be different depending on not just one answer but a derived value based on two or more previous answers.
(Paul to provide some examples so we can assess whether there are a few use cases that could be supported)
Estimated LOE:
1.3 # 9848 Provide support for different Types of validation conditions
A 'hard' validation is an error that prevents the user from continuing versus a 'soft' validation that warns of a problem, but allows the user to continue.
Estimated LOE:
1.4 # 9849Provide support for creating the data validation error messages
This feature would allow the user to specify a form level error message associated with either the hard or soft validation condition.
Estimated LOE:
1.5 # 7890 Allow user to browse Form Details without having an account that has editing privileges.
Currently you need an account with edit privileges in at least one context to access Form Builder and view the details of the Form Layout. The Guest account provides this ability, but users may just want to view the form details and behavior but not be
able to make changes.
Estimated LOE:
1.6 # 9868 Provide ability to detect the changes between versions of content within a Form in the exported metadata.
Currently the export does not include all the public id and version numbers of the part of the form, only the Form and CDE information are included. The exported metadata should indicate what content on the form has changed: Question or CDE upon which the Question is based, Valid Values, Module, Skip Patterns, etc
Estimated LOE:
1.7 # 8615 Ability to download CDEs in the same format as from CDE Browser.
Currently the export is in the format of the Form, which includes the form header, sections, skip patterns, etc. Users who have programs already written to accept the CDE Browser exported format of just the CDE information would like the option within Form Builder of being able to export the CDEs on a Form the same format.
Estimated LOE:
1.8 # 10129 Ensure that all Form and CDE attributes are in the exported/download version of the form.
Currently the Excel Download of the Form does not include all CDE attributes because a Question, while based on a CDE, has different attributes. Devise a way that all the CDE attributes that are provided in the CDE browser can be exported along with the Form. This is so that the receiving application can utilize the full CDE metadata information.
Estimated LOE:
1.9 # 9869Provide ability to Download Form as an XML document containing the Form and CDE metadata (non HL7)
Commercial customers need a concise XML representation of Forms and their associated CDEs.
Estimated LOE:
1.10. # 9867 Update the user interfaces to allow the attributes needed in the Forms Catalog search to be added to existing forms.
1.10.1 # 9850 Metadata to support query on "Usage"
Information such as what other projects or organizations have used the form, whether there are related forms or questionnaires, other caDSR Context usage, etc.
1.10.2 # 9851 Metadata for Form Data Collection Method (phone, mail, email etc.)
1.10.3 # 9852 Metadata for Form and CDE Target Population Group.
1.10.4 # 9853 Metadata for Form and CDE Target Age Group
1.10.5 # 9854 Metadata for Form and CDE Target Reading Level
Estimated LOE for 10:
1.11 # 1180 Create CDE while in FormBuilder Session
Use caDSR metadata structures to provide simplified search capabilities to 'find' possible building blocks, starting with object class, working up to DECs associated with OC, then existing CDEs and VDs associated with the same Conceptual Domain.
Estimated LOE:
1.12 # 7744 Navigation needed for FormBuilder login page
When you enter the FormBuilder login page, there are no navigation buttons. If you have entered the site incorrectly, you will want to return to the CDE browser, but that option is not present. Provide the ability to navigate away from the Form Builder login page.
Estimated LOE:
1.13 # 9863 Provide a Default Widget appropriate for Value Domain type
Provides a default HTML widget for each valid caDSR Datatype for non-enumerated and enumerated value domains. Eg. VD = non- enumerated, Datatype = character, string, java.lang string Maximum length = 255, Minimum length = 0 would be translated into a text box of 255 characters which is optional because the minimum length attribute is 0, as opposed to minimum length = 1.
e.g. (From Survey Monkey)
Multiple Choice (Only One Answer)
Multiple Choice (Multiple Answers)
Matrix of Choices (Only One Answer Per Row
Matrix of Choices (Multiple Answers Per Row)
Matrix of Drop-down Menus
Rating Scale
Single Textbox
Multiple Textboxes
Comment/Essay Box
Numerical Textboxes
Demographic Information (US)
Demographic Information (International)
Date and/or Time
Image
Descriptive Text
Estimated LOE:
1.14 # 9864 Provide methods for curation of the question presentation characteristics during Form authoring
Provide methods for inclusion of question presentation characteristics such as Radio button, check box, visual analog, scale, etc.
Estimated LOE:
1.15 # 9861 Allow CDE widget to be overridden for a CDE on a specific Form
Enhance the caDSR metamodel and UI to allow a widget to be defined for a Question on a Form that is different than the default or curated CDE. Restrict the selection to those that are appropriate for the Value Domain datatype. Use cases need to be defined in order to ensure that this feature can be implemented without changing the nature and intent of the CDE.
Estimated LOE:
1.16 # 9859 Provide ability to interpret an Array Datatype to establish how many values can be selected from a list of values
Users need to be able to allow the metadata to determine how many values can be selected from a list of values. Such responses should be stored as an array. caDSR Value Domain datatypes do not currently directly support this capability (only be reference to an external datatype). Enhance the caDSR datatype structure so that the dimensions of the array can be specific and stored in caDSR as metadata. This will allow the creation of data elements that align with question/responses such as "Select 3 of 5"
See SurveyMonkey - "Type Questions" for possible approaches for automatically selecting the appropriate widget by default based on the Value Domain attributes.
Estimated LOE:
2 Non Functional Requirements
2.1 # 7889 Provide standalone access to Form Builder - a new url
Users need to be able to access Form Builder directly, without having to go to CDE Browser first.
Estimated LOE:
2.2 # 9862 Clarify mandatory attributes for UI with NG Forms during design
Revamp user interfaces to make it clear which caDSR form attributes are mandatory versus optional when designing the form.
Estimated LOE:
2.3 Enhance caDSR Metamodel and Services to support the functional requirements above
Estimated LOE: | 
