Attachment B: Functionality & Response Questionnaire
Contents
Glossary of Terms for this RFP
FUNCTIONAL QUESTIONS
General/Global across all modules
System Functionality
User Interface/experience
Notifications
Searching
Module-Specific answers required
Workflow and Routing
Reporting
Pre-Award and Award
Proposal Development
Budget
Budget Development
Award Budget Setup
Award
Award Setup
Post-Award Monitoring
IRB
System Administration
Committee/Protocol Administration
Board Member Reviewers
Investigator
Post-Approval Reporting and Monitoring
IACUC
System Administration
Committee/Protocol Administration
Board Member Reviewers
Investigator
Post-Approval Reporting and Monitoring
IBC
System Administration
Committee/Protocol Administration
Board Member Reviewers
Investigator
Post-Approval Reporting and Monitoring
COI
SERVICE QUESTIONS
History, Current Client Base and Demographics
Implementation and Support
Data
Deployment
Support
Training
Future Development
Architecture-Specific Questions
SaaS Architecture
On Premises Architecture
Costs
Additional Cost Elements
Glossary of Terms for this RFP
Throughout the investigation phase of this project, we have encountered many terms that are used interchangeably, leading to confusion and misunderstandings. The most common problematic terms are listed below in groups of two or three where distinctions are useful. Please refer to the definitions below as you answer the questions in this RFP.
eForm – A term to denote a series of questions or groups of questions that are answered by the investigator in order to request action. For example, an investigator who wishes to perform human subjects research will need to complete an IRB eForm; an investigator who wishes to submit a funding request will need to complete a proposal eForm.
Vs.
Item– We are using the term in this RFP as a generic term to represent a collection of data that travels along a workflow path. For example, an item in the IRB module might be a package that includes the IRB eForm as well as any attached documents and review notes and system-generated correspondence. An item in the COI module might be a disclosure or a management plan.
Vs.
Project – an umbrella term used to describe a collection of related research items, for example, one project may include a proposal eForm, an IRB eForm and a COI Management Plan.
Configuration – a change to the system that can be made at no additional cost and can be accomplished at any time by a UT system administrator. Configurations should not be affected by upgrades.
Vs.
Customization – a change to the system that is not accommodated within existing configurations. Changes of this type or magnitude generally incur cost, vendor and/or UT programming resources, time and user testing. Changes of this type also generally make upgrading more challenging as they need to be separately applied or re-applied.
Module – a set of functions designed around one area, such as Proposal Development and Submission, Awards, IACUC, IRB, or COI.
Researchers
Investigator – a person engagedat any level in a research project.
Vs.
PI– the primary investigator who is responsible for the design, conduct and/or reporting of the research.
Vs.
Board Member Reviewers – in most cases, a board member reviewer is also an investigator in his/her own right, but they have additional responsibilities in the compliance modules of examining and appraising other investigators’ research for the purposes of assessing the safety and quality of the research.
Staff
Module Administration/Administrator – a staff member in the research, grants or compliance offices whose responsibility it is to monitor and move items through workflow. Job title may be coordinator, analyst, administrative assistant, secretary, or something else.
Vs.
System Administrator – a staff member in the research office or in the IT office whose responsibility is to monitor the system as whole and to make changes at the system level.
Vs.
Management/Manager – staff who are responsible for ensuring that the administrators can and are performing the work of research administration and to report on and monitor the health of the research enterprise as a whole. Job title may be director, manager, compliance officer, or something else.
Vs.
SRO – Sponsored Research Office, office that oversees grant submission and acceptance of awards.
Notification – a system-generated message that stays within the system.
Vs.
Email – a system-generated message that goes outside the system.
Vs.
Correspondence – a system-generated document (such as an approval letter) that resides within the system but may also be emailed outside the system and is afree-standing file separate from the content of a notification or email.
Portal – a window or view presented to the investigator to assist him in getting to the portion of the system that he needs. Portals may include widgets, links, documentation, news feeds or dashboards.
Vs.
Dashboard – a view of data specific to the investigator. This may include a “task list” or “inbox” as well as mini-reports that help the investigator to understand the statuses of existing projects or items.
Error– An issue with the data that has been entered in the system that will prevent submission. A classic example would be entering a character in a number field or a malformed date.
Vs.
Warning – An issue with the data that has been entered that does not prevent submission, but is suspect. This could be contradictory answers to questions or adding an investigator without the required training.
Workflow - Refers to the entire process of the item within a module and any attendant steps it must go through from inception to final step (approval, closure, etc.)
Vs.
Routing - usually a special step within that workflow where “approval” signatures are gathered from the responsible parties within UT. Routing may be as simple as collecting one signature (the PI on an IRB protocol being submitted by a student) or as complex as a series of Co-PI’s and the chairs of their departments or deans of their colleges for a large proposal.
Permission roles- roles assigned to a specific person which determine what that user is allowed to do in the system.
Vs.
Permission groups – groups of roles or persons which determine what people in that group are allowed to do in the system.
Responses to this RFP that address only a portion or portions of the functionality sought will be considered.
Responses that involve two or more vendors teaming up to present a combined solution will also be considered.
FUNCTIONAL QUESTIONS
General/Global across all modules
System Functionality
Describe the system’sout-of-the-box identity management capabilities.Response:
Describe the system’s single sign-on capabilities. Please include how the system would interact with multiple external identity management systems.Response:
Describe the system’s capabilities for registration of new users. Is self-registration an option?Response:
Describe in general how your system integrates with third-party systems.Response:
Describe specifically how your system integrates with Ellucian Banner.Response:
Describe how your system complies withthe Americans with Disabilities Act (ADA).Response:
Describe how your system meets the requirements for 21 CFR Part 11.Response:
Describe how your system accommodates the requirements for HIPAA on PHI.Response:
Describe what platforms, browsers and devices the system is compatible with. Response:
Include answers to the following:
1)Which browsers are used for testing? Response:
2)Does your system require any plug-ins or applets in order to run?Response:
3)Can the system send notifications via texting?Response:
Describe user permission roles provided out of the box, and the ability to create new roles and assign permissions to them. Describe the levels of granularity in assigning permissions to roles and/or groups. For example, are permissions applied to a field, groups of fields, module or some other grouping?Response:
Describe any external relationships that come out-of-the-box. For example:
1)Describe the system’s integration with CITI Program training.Response:
2)Describe integration with any publication databases.Response:
3)Describe any capabilities to display external RSS feeds.Response:
Describe the information maintained in the user profile and the level of control a user has over that data. Response:
Then please address the following specific areas:
1)Biographical information Response:
2)HR dataResponse:
3)BiosketchesResponse:
4)Expertise and InterestsResponse:
5)TrainingResponse:
6)EVerify documentationResponse:
Describe any personnel training management tools in addition to the connection to CITI.Response:
Specifically address:
1)the system’s ability to manage training provided in-houseResponse:
2)the system’s ability to connect to additional in-house databases for training dataResponse:
User Interface/experience
How does the system support UT branding (e.g. colors, logos, banners)? Is this configurable by UT system administrators without vendor involvement?Response:
Describe how your system supports the broadcasting of information to the UT user community. Response:
For example:
1)Can the system to communicate an upcoming planned outage or deadline to the entire community? Response:
2)Can the broadcasting be limited by user groups or roles? For example, is there a place to announce a new form or process in a specific module?Response:
Describe the initial view, or portal, presented to the user upon logging in. Response:
Then answer the following:
1)Is the portal configurable by a system administrator? Response:
2)Is the portal configurable by the user himself? For example, can the investigator re-arrange the screento their liking? Response:
Example screen shots are encouraged.
Describe if or how the portal controls access to or views of different modules. For example, will the investigator see links/access to modules that they don’t or can’t use? Response:
Example screen shots are encouraged.
Describe how an investigator, reviewer or administrator knows what tasks he must complete. Response:
Include any mechanisms for sorting and prioritization. For example:
1)Describe the “inbox,” “to do list,” or “task list” available to each person. Response:
2)Are these lists separated in modules, or combined in a single list? Response:
3)How does the investigator know which tasks are most pressing? Response:
Notifications
Describe any means to provide notifications to investigators, reviewers or administrators about required actions. Response:
What conditions trigger the notifications, and what means exist for configuring the triggers and the content of the notification?Response:
What conditions turn off notifications? Response:
What email capabilities exist to inform the investigator that they have a task to accomplish in the system? Response:
Can the email include a link to the specific item in question?Response:
If the system sends email, how is it tracked and archived? Does this automatically cross over to Outlook?Response:
Searching
Does the system support a “universal” search, e.g. looking for items across modules using a single search term? Response:
Describe the mechanism for text searching. Example screen shots are encouraged.Response:
Does your system support “auto-fill” searching, where typing characters in a search field immediately displays partial matches in a drop-down list)? Response:
Does your system require wildcard characters when searching or does it default to a partial text search?Response:
Does the system support searching for proposals and/or protocols by responsible administrator (e.g. coordinator or analyst or contract specialist)?Response:
Are you aware of any system limitations or delays with searching a large number of records? Response:
Describe the mechanism for uploading files. For example, is the system “drag and drop” compatible, or multi-file select compatible? Example screen shots are encouraged.Response:
Module-Specific answers required
Describe the flexibility and the limitations of the eForms your product uses.Response:
Then address the following specific questions:
1)Will the system allow multiple eForms for the different types of application or review within each module?Response:
2)Will module or system administrators be able to add or update questions without vendor intervention?Response:
3)Describe any branching logic or question dependency provided in the eForms.Response:
4)Describe the version control of eForms as questions are added or updated through time.Response:
5)What data-types can be collected in questions?Response:
6)Are multi-select lists possible?Response:
7)Can answers to questions include file uploads?Response:
- If so, how are those files collected and displayed (especially with versioning over time)?Response:
8)Can questions search/use fields across modules (e.g. could a question in IRB module use as its answer the list of funding sources from proposals)?Response:
9)Does the system have the ability to control data entry in a custom field by role (e.g. some fields are collected from the investigator, but some are for administrators only)?Response:
10)Are there limitations in “hiding” or removing existing out-of-the-box data collection fields?Response:
Describe the help mechanisms/validations in place to assist investigators in the application or eForm process in each module.
Then, describe what is provided out-of-the-box and what is configurable by UT for the following:Response:
1)mechanisms for help text within each module such as tool tips or “more info” areasResponse:
2)abilities to link to external information in contextResponse:
3)abilities to embed links to files, such as University-approved templates or instruction documentsResponse:
4)any live help functionality, e.g. chat tools and how they are staffedResponse:
5)any visual clues that a researcher has completed all the necessary components to move on to the next workflow stepResponse:
6)the ability to configureerror messagesResponse:
7)any “soft errors” or warnings that do not prevent moving to the next workflow stepResponse:
8)any “hard stop” validation mechanism within the system to prevent submissions that are missing or incomplete from moving on to the next workflow step.Response:
Does the system provide any management or monitoring of workload balance/distribution in each module?Response:
1)How is a particular item assigned to amodule administrator (protocol to a specific IRB coordinator among several, or a proposal to a specific Grants Coordinator)?Response:
- Can particular items in the system be automatically directed to particular administrators based on data collected within the item/eForms?Response:
2)How can management determine the workload of each coordinator? Response:
3)Describe tools to assist workload balancing to avoid deadline pile-up on any single administrator.Response:
4)If anadministrator is absent, describe howthe system assists in re-distributing the workload.Response:
For each module, describe how training data is integrated during the investigator eForm process.Response:
Then address these specifics:
1)Can investigators beginning a proposal or protocol eForm see the training records for the people they are adding? Response:
2)Is there any indication when a person being added does not have the correct training for that item? (IRB protocols require different training depending on the board they are submitting to, IACUC protocol training is dependent on the species involved,proposals may require different training depending on sponsor requirements)?Response:
Describe the mechanism for adding non-UT personnel to each module item.Response:
What kind of data changeauditing is provided in each module?Response:
Are changes trackedat the field level such that it is possible to know whichuser changed or added which data field or element?Response:
Describe any presentation of timelines or actions by date in any module.Response:
For each module, what kind of record locking is included? Response:
Can two people be in the same record working at the same time without overwriting each other’s work?Response:
Describe the capacity to add and index supporting documents in each module.Response:
Describe the ability of the system to retain documents over time to meet federal, state and sponsor regulations. Can retention period be designated by module, or by project, or by document and by whom?Response:
When an investigator wishes to use existing or past research as a “template” for a new eForm, what mechanisms are available to do that for each module?Response:
Then, address the following specifically:
1)Describe exactly what data copied.Response:
2)Are there administrative ways to allow or disallow certain questions or associated documents from being copied? Response:
Every item in the system needs an identifying number or set of characters. For each module, describe the format and flexibility of the numbering mechanism used in the system. Include any ability for the numbering (or prefixes and suffixes) to be influenced by data collected in the item/eForm.Response:
Workflow and Routing
Please refer to the Glossary of Terms for definitions of workflow and routing.
For all modules, describe how an investigator would see his/her items as they move through the various workflow processes. Is there a pictorial representation of the entire workflow process for each module and item?Response:
How will a researcher know where in the workflow process a specific item is, what’s already happened to it and what’s upcoming? Response:
Describe the system’s ability to display multiple items at once in a workflow process. For example, is there a view that allows the researcher to see that they have 3 items in “pre-review” and one in “review” and two in “post review processing” etc.?Response:
Describe how an administrator might be able to view in-progress items on which they must act. Response:
Is there a mechanism for viewing items as “counts” within the workflow process? For example, an IRB coordinator might see that there were 3 new protocol items submitted for pre-review, 4 items re-submitted after changes, and 16 reviews for processing. Response:
Describe the routing for endorsement/signatures mechanism available to each module and its flexibility. Response:
For example:
1)Can routing for endorsement/signatures be based on data collected within the application/eForm?Response:
2)Can routing for endorsement/signatures be modified by administrators after initiation?Response:
3)What capabilities exist for endorsers/signatories to add comments? Response:
4)In the event of a required endorser/signatory being unavailable, what mechanisms are provided to designate an alternate signatory?Response: